Template skeleton!

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #120, on November 23rd, 2011, 10:54 PM »
Okay, a few things....

- The post above: is it still valid? I suspect so, but I never quite understood what was wrong with the code... Maybe you could dig into it again? Thank you.

- I'm not too happy with the welay object. I renamed it to wetemItem because, well, it can also hold a block, and I decided to drop the jQuery naming conventions, so I re-renamed 'append' to 'add', and 'prepend' to 'first'. Also, I renamed 'wrap' to 'outer'.

- I decided that considering there are NOT a lot of places in Wedge where we could use method chaining anyway, weitemItem will only be there 'for the show', but not actually used if we can do otherwise.

- I renamed wetem::load() to wetem::op() (operations), made it private, and added a ::load() that does the 'replace' thing. Also added ::add() and other public static stations. Given that 95% of the use of wetem is to load a full block into the default layer, I think there's no need to bother in the first place.

- I'm considering inverting the order of parameters.

wetem::add('sidebar', 'block1') would add this block to the sidebar.
wetem::load(array('block1', 'block2')) would load (not add) these blocks to the default layer.

This would allow to keep the simple syntax of the majority of calls (wetem::load('block')), while making all functions behave in a logical way -- I think it really makes more sense to have the target name first, and then whatever we want to add to it. And even more when it comes to wetem::rename('current_layer', 'new_name').

However, this MAY sound complicated or illogical to many people.
Of course, people could 'simply' do wetem::get('sidebar')->add('block1') for similar results, and with the added benefit of specifying the target layer first. I'm just... Not sure which is best right now.

Any opinions on all of this...?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #121, on November 23rd, 2011, 10:59 PM »
Quote
- The post above: is it still valid? I suspect so, but I never quite understood what was wrong with the code... Maybe you could dig into it again? Thank you.
That was the point. The code should have worked but it didn't work as expected, in that the layer that (as far as I was concerned) should have been created, just wasn't being created.
Quote
- I decided that considering there are NOT a lot of places in Wedge where we could use method chaining anyway, weitemItem will only be there 'for the show', but not actually used if we can do otherwise.
This was something that bugged me. I saw it was cool but I couldn't quite envisage where it would be beneficial over anything else we were really doing at the time.
Quote
- I renamed wetem::load() to wetem::op() (operations), made it private, and added a ::load() that does the 'replace' thing. Also added ::add() and other public static stations. Given that 95% of the use of wetem is to load a full block into the default layer, I think there's no need to bother in the first place.
95% of *Wedge's* use might be that. But that means, yay, I get to fix every plugin I've written thus far that adds a block, because they all use load to add to the layers, though it would logically be better to use an add method.
Quote
- I'm considering inverting the order of parameters.

wetem::add('sidebar', 'block1') would add this block to the sidebar.
wetem::load(array('block1', 'block2')) would load (not add) these blocks to the default layer.
Makes sense.
Quote
However, this MAY sound complicated or illogical to many people.
As long as it's documented and there are examples, it seems to make sense...
Quote
Of course, people could 'simply' do wetem::get('sidebar')->add('block1') for similar results, and with the added benefit of specifying the target layer first. I'm just... Not sure which is best right now.
I don't think the chaining really adds anything here.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #122, on November 23rd, 2011, 11:09 PM »
Quote from Arantor on November 23rd, 2011, 10:59 PM
That was the point. The code should have worked but it didn't work as expected, in that the layer that (as far as I was concerned) should have been created, just wasn't being created.
Does it work if you don't execute the ::load() before it? Do you remember...?
Quote
This was something that bugged me. I saw it was cool but I couldn't quite envisage where it would be beneficial over anything else we were really doing at the time.
The main point was me learning more about singletons and non-static methods, I guess... :lol:
Quote
95% of *Wedge's* use might be that. But that means, yay, I get to fix every plugin I've written thus far that adds a block, because they all use load to add to the layers, though it would logically be better to use an add method.
Hmm... 'Oops'?
I could ensure ::load stays public, but I have a feeling that you would want to 'give the right example' and rewrite your code to use :add anyway. It's relatively fast to update, though...
Quote
Makes sense.
Well, it's easy to understand when one of the params is an array, but if it's not, it could lead to misunderstandings... Was it wetem::add('side', 'sidebar') or wetem::add('sidebar', 'side') already?
Quote
Quote
Of course, people could 'simply' do wetem::get('sidebar')->add('block1') for similar results, and with the added benefit of specifying the target layer first. I'm just... Not sure which is best right now.
I don't think the chaining really adds anything here.
My documentation for wetemItem has this:

wetem::get('sidebar_dummy')->parent()->rename('sidebar2')->inner('inside_sidebar');

:lol:
Well, I guess it's mostly interesting for the parent() function at this point. And readability.
Re: Template skeleton!
« Reply #123, on November 23rd, 2011, 11:32 PM »
This one's damn funny...

wetem::load('profile_top', array('top', 'default'));

Any n00b might think, 'load the top and default blocks into the profile_top layer'... When it's actually the other way around ;)

Anyway, that one reminds me that I can't even use is_array() to determine the position of $blocks in the param list... :P
Posted: November 23rd, 2011, 11:25 PM

I've converted all templates manually in about 10 minutes. So it should be doable... Just do a regex search on ::load[^)]+$ and ::load.*,
It should be enough to catch all 'special cases'...

Bed time, and Subs-Template.php is not finished yet, so I'll commit tomorrow.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #125, on November 24th, 2011, 02:10 PM »
Quote
Does it work if you don't execute the ::load() before it? Do you remember...?
Didn't try it, because the whole point was to add a layer dynamically after the rest of the stuff had been created. To me, having a caveat that says 'you can only create new layers before resetting the default layer contents' is a bit banal.
Quote
Hmm... 'Oops'?
I could ensure ::load stays public, but I have a feeling that you would want to 'give the right example' and rewrite your code to use :add anyway. It's relatively fast to update, though...
That's partly why I'm enthusiastic about building plugins, so that there are 'best practice' examples to work with. Besides, it does seem more logical to have add as a separate method because it does define what it's doing.

(I don't really mind updating my plugins. It's the curse of writing plugins this early, really.)
Quote
Well, it's easy to understand when one of the params is an array, but if it's not, it could lead to misunderstandings... Was it wetem::add('side', 'sidebar') or wetem::add('sidebar', 'side') already?
Yeah...
Quote
My documentation for wetemItem has this:

wetem::get('sidebar_dummy')->parent()->rename('sidebar2')->inner('inside_sidebar');
That's the sort of case that chaining really allows for - which is an improvement over the equivalent unchained methodology.  Just that for most uses in the core, and most plugin uses, chaining doesn't bring anything huge.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #126, on November 24th, 2011, 03:22 PM »
Quote from Arantor on November 24th, 2011, 02:10 PM
Didn't try it, because the whole point was to add a layer dynamically after the rest of the stuff had been created. To me, having a caveat that says 'you can only create new layers before resetting the default layer contents' is a bit banal.
Yeah, sure...
I'll take some time to look into this. Maybe it's "fixed" in the new code already, I don't know... (I mean, I found and fixed a bug with 'load(before)'.)
Quote
That's partly why I'm enthusiastic about building plugins, so that there are 'best practice' examples to work with. Besides, it does seem more logical to have add as a separate method because it does define what it's doing.
Yep... I think we discussed it in the early days of wetem, but I forgot to think further about it...
Quote
(I don't really mind updating my plugins. It's the curse of writing plugins this early, really.)
And besides, it's not going to be as annoying as my own work on the rewrite itself... Believe me, I had to double-check the entire friggin' code at least 10 times today... :^^;:
Too bad I deleted my test suite for wetem. I had to write a new one from scratch, and because it's annoying, I barely tested half the use cases I had before... Meh, it should work. And if it doesn't... It's an alpha anyway :P
Quote
Quote
Well, it's easy to understand when one of the params is an array, but if it's not, it could lead to misunderstandings... Was it wetem::add('side', 'sidebar') or wetem::add('sidebar', 'side') already?
Yeah...
I was thinking, the only reason we need an array for layer lists is to provide for fallbacks... Why not do an explode(',', $target) in ::load()? That way, we can provide 'sidebar,top,default' or even 'sidebar,top,' (empty last string) for the target...

Also, was thinking at this point we may wanna split wetem into its own class file... It's 22KB. Splitting it into another file, however, adds about 5ms of processing time on my local server, even if it's just that -- the process of taking one file and splitting it in two, and including both files from within Subs.php. There aren't a lot of connections between Subs-Template and Class-Template (or whatever we'd call it), just a few here and there, so it might be justified.

:edit: Hey! We both have 7777 posts each... LUCKY! :P
Re: Template skeleton!
« Reply #127, on November 25th, 2011, 01:16 AM »
Bump, again....... :whistle:

Been holding myself from committing the changes mentioned in the last paragraphs because I'm not sure we want that.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #128, on November 25th, 2011, 01:59 AM »
Quote
Yeah, sure...
I'll take some time to look into this. Maybe it's "fixed" in the new code already, I don't know... (I mean, I found and fixed a bug with 'load(before)'.)
I haven't had chance to try it but it's certainly something that needs investigation. You know, you could always try writing a plugin :whistle:
Quote
Yep... I think we discussed it in the early days of wetem, but I forgot to think further about it...
No worries; I fully expected to be the one who would discover such fun things when writing plugins. It's a good way of debugging things, incidentally.
Quote
And besides, it's not going to be as annoying as my own work on the rewrite itself... Believe me, I had to double-check the entire friggin' code at least 10 times today...
*nods* This is also why I'm slack about updating my plugins until things settle down. I still, as it happens, have one plugin that uses loadBlock() from before wetem even existed.
Quote
I was thinking, the only reason we need an array for layer lists is to provide for fallbacks... Why not do an explode(',', $target) in ::load()? That way, we can provide 'sidebar,top,default' or even 'sidebar,top,' (empty last string) for the target...
That's workable. The thing is, whenever doing anything like this, two sets of circumstances need to be borne in mind: firstly, how Wedge itself uses these, and secondly how plugins and themes will use it (but mostly plugins).

Wedge's use is almost entirely just dropping complete lists of templates into layers, but plugins may well want to insert individual things into layers, may want fallbacks, may want to do other things. To be honest, if I'm looking to insert into the sidebar and falling back to the default layer, I really won't want to do it like that, because the styling will be all wrong. I'll want to have separate templates for that job.

Consider any of the sidebar blocks that we have currently. Would they look right, style-wise, if simply dropped into the default layer? A few might get away with it but generally it'll look bad.
Quote
Also, was thinking at this point we may wanna split wetem into its own class file... It's 22KB. Splitting it into another file, however, adds about 5ms of processing time on my local server, even if it's just that -- the process of taking one file and splitting it in two, and including both files from within Subs.php. There aren't a lot of connections between Subs-Template and Class-Template (or whatever we'd call it), just a few here and there, so it might be justified.
Yeah, it's something to bear in mind. However, while there is little connection, it's going to be called together and used together ultimately, so there's little point in splitting it.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #129, on November 25th, 2011, 12:36 PM »
Quote from Arantor on November 25th, 2011, 01:59 AM
I haven't had chance to try it but it's certainly something that needs investigation. You know, you could always try writing a plugin :whistle:
I don't know, I would first like to hone my skills on OOP... I have a feeling that I need to fully grasp the meaning of cooperation between different elements of a program, before I even consider doing a plugin. Aeva Media was kind of a hard task to manage -- not because of the technicalities of a SMF add-on (Dragooon managed most of it really), but because it required thinking in two ways: the SMF way of doing things, and my way of doing things. With Wedge, the problem is no longer there because I'm doing things my way (and they're close enough to your way that we don't often get dragged into endless discussions about whether something should be done this or that way), but I need to have a feel of how to *allow* others to plug into my mind and my way of doing things -- and I think it's necessary for me to broaden my technique for that.

On a very, very slightly related topic, but it's something I wanted to discuss anyway and I couldn't bother to open a new topic... I finally watched Atlas Shrugged this morning. The movie. I had an interest in Ayn Rand's works because I'm very much interested in null-A logic, which has arguably (and thankfully) nothing to do with objectivism, but she was into null-A as well, so I thought maybe she had something interesting to say. I was not utterly convinced by The Fountainhead, as I found the main character to be mostly selfish and actually too far removed from the contributions to society that he's supposed to be making -- I'm not sure that ambition plays a huge role in your life after you're past your 20/30's. I know it's not in my book right now. But I still liked the idea of a philosophy of doing your own thing and not letting others get in the way. However, with Atlas Shrugged, I think I've finally understood what it's all about... It's an American thing.
From what I understand, Republicans and Democrats are not exactly the same as Right and Left wings in Europe. It's mostly a federal thing, so Republicans have 'laissez-faire', and Democrats represent the government as a means to control wealth in the US, in a way that could lead them to be accused of communism, or as they like to say, socialism. Atlas Shrugged, at least the movie, shows this in a way that reminded me of the current economy crisis in Europe: the wealthier European states, like France and Germany, don't want to 'chip in' for Greece. So, in that respect, we actually have a European leadership that chose the 'Democrat' way of doing things, while the people wants 'laissez-faire'. There's a similar trend in Belgium where the Flemish half of the country doesn't want to pay for the failing economy of the French speaking part -- even though a century ago, the French speaking Belgians were doing the exact same thing for their weak Flemish neighbors.
All in all -- I have a feeling that this is what it's about: when you ask someone to help someone else who's been less lucky, are you being charitable or selfish? It's interesting that in the movie, the 'good guys' are the ones who, as they clearly say themselves, 'are only interested in making money'. I'm not falling for that. The Reardon guy is clearly a geek who only has interest in success and discovery, not in getting paid for that. Now it'd be interesting to see how much that applies to financial institutions... They don't really create things, they only bet on other people's success or failure. That's not innovation to me. I'm not exactly sure why I should be supporting them...

Well, just wanna say that I'm not falling for either side of the issue, but at least I have a better understanding of the divide between Americans (and, let's say it, Europeans now.)

And on my current matters: what are we demonstrating by doing what we're doing? We're not doing it for money, we're not doing it for glory... We're doing it because we feel it has to be done. Because we want to innovate in our field. How would we react if we ended up making Wedge a huge success, and someone demanded of us that we be 'fair' to the competition or something? I don't know, because I think I'm being fair right now -- I'm certainly not trying to make money off anyone, or take market shares, or anything like that.

I think that's it... I think that innovation is not systematically something that should be monetized for the sake of being monetized. What one wants is to keep living doing something that makes them happy. This requires money, so often the two gets mixed together, but it doesn't have to. I think that's probably one of the big flaws in objectivism as I'm seeing it. Unless, of course, I totally misunderstood the concept... :^^;:
Quote
*nods* This is also why I'm slack about updating my plugins until things settle down. I still, as it happens, have one plugin that uses loadBlock() from before wetem even existed.
Could be worse... Could be loadSubTemplate() :P
Quote
That's workable. The thing is, whenever doing anything like this, two sets of circumstances need to be borne in mind: firstly, how Wedge itself uses these, and secondly how plugins and themes will use it (but mostly plugins).
Wedge doesn't use it that much. I think there are only a couple of places where multiple target layers are provided (probably when it comes to the menus, which are added to the 'top' layer?). Still, it makes sense to allow plugin authors to make sure their data is shown. I'll give you a quick example: let's say I want to show data in the sidebar at all times. However, Wedge doesn't guarantee me that I'll be able to access the sidebar at all times (another plugin may want to delete it to make room for something else), so I may want to give up on most data I'm showing, but if there's something particularly critical to show, I could just as well create my own layer inside the footer or something, NOT fill it with anything, and only provide it as a fallback for my critical data. Wedge won't budge if it doesn't find any code associated to layers you create. (Just check out Warm's recent indenazi changes -- I added a fake <indent> layer to cancel any indentation changes made by its parent layer. I think it's pretty neat.)

That's one thing among others...
Of course, we could also do it differently, like, instead of providing 'sidebar,fallback', the plugin author could use '!sidebar' or something, where the '!' would be seen by Wedge as a sign that the layer needs to be created if it's not there. It would force me to record all traces of previously deleted layers, though, but it's doable.
Quote
Wedge's use is almost entirely just dropping complete lists of templates into layers, but plugins may well want to insert individual things into layers, may want fallbacks, may want to do other things. To be honest, if I'm looking to insert into the sidebar and falling back to the default layer, I really won't want to do it like that, because the styling will be all wrong.
I'm not sure about that. You could very well prepare for this particular case by adding some CSS to adapt the styling for your data inside the fallback layer.
Quote
Consider any of the sidebar blocks that we have currently. Would they look right, style-wise, if simply dropped into the default layer? A few might get away with it but generally it'll look bad.
I still have plans to make the sidebar look good horizontally... :P I need to turn the blocks into inline-blocks for that.
Quote
Yeah, it's something to bear in mind. However, while there is little connection, it's going to be called together and used together ultimately, so there's little point in splitting it.
The main point is having all important objects into their own file, for easing editing. Some class files are only called from within one point in the source code (such as Class-CSS or Class-SFTP), so we might argue that they should be stored in the same file... (Well, they're not ALWAYS loaded though, so it's best to keep them apart, sorry for the poor analogy.)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #130, on November 25th, 2011, 01:08 PM »
:/ I don't have much to say on anything other than the following. I think it doesn't help that both of us (my partner and me) are both under the weather today, feeling rubbish and ill.
Quote
And on my current matters: what are we demonstrating by doing what we're doing? We're not doing it for money, we're not doing it for glory... We're doing it because we feel it has to be done. Because we want to innovate in our field. How would we react if we ended up making Wedge a huge success, and someone demanded of us that we be 'fair' to the competition or something? I don't know, because I think I'm being fair right now -- I'm certainly not trying to make money off anyone, or take market shares, or anything like that.
We are demonstrating that the way things are is not ideal and that there is an alternative. Only recently I saw someone asking on sm.org for 'a way of working out what order mods needed to be installed in so they work properly'. Apart from the vast number of permutations that are generated out of this, it's also entirely the wrong way to go. Instead of playing triage on file edit related matters, people should be looking at ways to change the problem entirely.
Quote
I think that's it... I think that innovation is not systematically something that should be monetized for the sake of being monetized. What one wants is to keep living doing something that makes them happy. This requires money, so often the two gets mixed together, but it doesn't have to. I think that's probably one of the big flaws in objectivism as I'm seeing it. Unless, of course, I totally misunderstood the concept...
You haven't misunderstood anything. If you're curious about how others view what is fundamentally the same concept, look up Maslow's Hierarchy of Needs. It describes virtually the same thing, but from an economist's point of view.

Once people have enough money to make sure their basic needs are met, they're generally pretty good but once their higher, not-necessarily-financial needs are met, they're even happier. I know I turned down a promotion at my former career once because while it would have made me more money, it would have meant longer hours and more stress.
Quote
I still have plans to make the sidebar look good horizontally..,
Not quite the same thing. Making the sidebar look good horizontally isn't the same challenge. I'm talking about having the sidebar stuff be moved wholesale out of the sidebar and into the default layer. The main header is likely to be wrong (as it should probably be elevated from a we:title to we:cat, or we:title2 to we:title depending on circumstance), for example.
Quote
I'm not sure about that. You could very well prepare for this particular case by adding some CSS to adapt the styling for your data inside the fallback layer.
But that's the thing - see above. If a plugin wants to use the sidebar but the sidebar's not available, just changing the CSS isn't enough, the markup is likely to be different too. If a plugin wants to create its own layer, fine, but even then it's still probably going to be using its own different markup.

What has to happen is either the fallback needs to allow an author to specify an alternative function to call as well the fallback layer.

Or, and this is why I asked for a return value in the method that adds a block in, the plugin can attempt to add to the sidebar, and if that fails, it can do something else.

That's assuming, of course, that the sidebar is removed by something with highest priority and everything else is done with lower priority but that's not something we can readily do much about... short of plugins having some flag to indicate that they manipulate, require, or disable the sidebar but that's another can of worms I don't want to get into.
Quote
The main point is having all important objects into their own file, for easing editing. Some class files are only called from within one point in the source code (such as Class-CSS or Class-SFTP), so we might argue that they should be stored in the same file...
Class-SFTP and Class-FTP could be called from different points in the code, but Class-CSS can't (it's invoked early on, no?)

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #131, on November 25th, 2011, 10:12 PM »
Quote from Arantor on November 25th, 2011, 01:08 PM
:/ I don't have much to say on anything other than the following. I think it doesn't help that both of us (my partner and me) are both under the weather today, feeling rubbish and ill.
Ah, my girlfriend too... :^^;:
Quote
We are demonstrating that the way things are is not ideal and that there is an alternative.
Well, we didn't need to 'demonstrate' that things were not ideal. But people don't generally expect free software to live up to commercial software. It takes crazy people like us, or Unknown back in the day, to do just that ;)
Quote
You haven't misunderstood anything. If you're curious about how others view what is fundamentally the same concept, look up Maslow's Hierarchy of Needs. It describes virtually the same thing, but from an economist's point of view.
I'll take note of that.
Quote
Once people have enough money to make sure their basic needs are met, they're generally pretty good but once their higher, not-necessarily-financial needs are met, they're even happier. I know I turned down a promotion at my former career once because while it would have made me more money, it would have meant longer hours and more stress.
I turned down so many things because of that, I understand perfectly... Well, actually I wouldn't be working on Wedge today if I hadn't suddenly started turning down *everything* back in September 2006. It felt like a dull life always working for other people to make money off my stuff... Even if I did make a decent share, too. Anyway...
Quote
Not quite the same thing. Making the sidebar look good horizontally isn't the same challenge. I'm talking about having the sidebar stuff be moved wholesale out of the sidebar and into the default layer.
And again, I'm positive that showing a sidebar block inside the default layer can work if done properly.
Quote
Or, and this is why I asked for a return value in the method that adds a block in, the plugin can attempt to add to the sidebar, and if that fails, it can do something else.
Well, it makes sense... wetem actually had this, but I realized when looking through my code that I'd 'stopped' doing it at some point, so the wetem::op() stuff was actually returning a value to no use, because it's a private method and the public methods that called it didn't return its value in turn.

Okay, so I removed my new code for comma-separated strings, if only because the whole thing was only used ONCE, after checking thoroughly (it's in Profile.php). The code was this, at the beginning of find():

Code: [Select]
// Turn 'sidebar,top,' into array('sidebar', 'top', '')
if (!is_array($targets))
$targets = explode(',', $targets);

Nothing big, really... But in the end, I felt a bit uncomfortable doing an unneeded explode() on every single wetem method call.
Quote
Class-SFTP and Class-FTP could be called from different points in the code, but Class-CSS can't (it's invoked early on, no?)
It's only invoked when Wedge actually needs to cache a CSS file. Otherwise it's not run at all, that is, 99% of the time...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #132, on November 25th, 2011, 10:34 PM »
Quote
Well, we didn't need to 'demonstrate' that things were not ideal. But people don't generally expect free software to live up to commercial software. It takes crazy people like us, or Unknown back in the day, to do just that
Even if people do make free software that's better than the paid competition, it's still not going to be acknowledged on the same level simply because it's not paid.
Quote
I turned down so many things because of that, I understand perfectly... Well, actually I wouldn't be working on Wedge today if I hadn't suddenly started turning down *everything* back in September 2006. It felt like a dull life always working for other people to make money off my stuff... Even if I did make a decent share, too. Anyway...
*nods* You enjoy doing things for you, and like me the money is a side issue.
Quote
And again, I'm positive that showing a sidebar block inside the default layer can work if done properly.
If it's a top level layer in the sidebar (e.g. the info center as a whole) it can work just fine as a child of the default layer. The we:title is thematically consistent with we:cat, and it won't look particularly wrong.

But that's top level categories only and they might be expecting a ~220px wide column and do complicated things with floats and wrapping and so on that won't work on a bigger scale.

In that case, the compromise is to allow for both; if the developer knows in advance that it's going to work OK falling back to default, let them specify it, but if not, have the return value to accommodate it (which means they can dynamically do their own thing if they choose)
Quote
It's only invoked when Wedge actually needs to cache a CSS file. Otherwise it's not run at all, that is, 99% of the time...
Hmm. You know, we could solve some of this problem intelligently by setting up an autoloader function.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #133, on November 26th, 2011, 12:19 AM »
An auto-loader..?

Anyway, that's not gonna solve the 'semantics' of a Class-Template file at any rate ;)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #134, on November 26th, 2011, 01:00 AM »
An autoloader is a routine that automatically loads classes that currently don't exist and does so automatically. You give it a routine by which it can load a given class based on the class you call for and it'll automatically load it for you if it doesn't currently exist.

Having something like that can help encourage code to be broken up based on whether it's needed or not.