Wedge

I'm hoping to have this on SVN by tonight...

Most of the stuff is working now. I'm having more issues though, so I'll just mention them here.

- seems like having a page sent in XML will crash everything. I've only seen this quickly, it seemed to me but it seems like XML will bypass many things in loadTheme() or something... (And it makes sense, since this codepath will generate its entire 'HTML' from scratch.)
Pete, any memories about this?

- I'm working on a "loadLayer()" function, similar to loadSubTemplate()... I'd like for it to be logical in its execution and settings. When exactly do we want to add a layer, and what for? Generally it's because we want to add something around the code being executed. The main issue I'm having here is that if it means adding a layer to the 'main' layer, any subsequent layers added will become parents of the earlier added layers. It's not a big problem to me but I don't think SMF does it in that direction... (Does it?)
Also, I'm having fun (ah ah... not exactly) trying to figure out how to quickly rename an array key. It's easy enough when your array doesn't need to preserve order... But when you start having to use array_splice when this one doesn't work with associative arrays and doesn't even preserve key names, meh... I guess I'll have to do my own routine that rebuilds an array from scratch. Ah ah, fun, as I said...

And these are my two current issues :P

Okay, renaming keys was easy enough, surprisingly... And fast.

However now I'm wondering what's best. By default, layers are added to the 'main' layer (you can choose your target layer, otherwise it's not cool.)
Should they be added *inside* the layer, or *outside* it? i.e. adding a <layer2> to <main> in <layer1><main><output /></main></layer1> should result in what...?

<layer1>
  <main>
    <layer2></layer2>
    <output />
  </main>
</layer1>

<layer1>
  <main>
    <layer2>
      <output />
    </layer2>
  </main>
</layer1>

<layer1>
  <layer2>
    <main>
      <output />
    </main>
  </layer2>
</layer1>

Of course I can include an option to do any of the three, but I'm sure there's going to be at least one option that never gets used... And we're bound to find people complaining they can't add an empty layer at the *end* of an existing layer... :lol:
Oh well, maybe it's not very important... I mean, adding a layer to the end manually can be done very easily: $context['layers']['main']['my_layer'] = array();
And at the beginning, my first guess would be to do something like: $context['layers']['main'] = array('my_layer' => array()) + $context['layers']['main'];
(And yes, I suppose I can add wrappers for these, too...)

Pete.  Does it use custom CSS? Is the enclosing div called edge or edgehide?

Wickets?
Eh! Let's rename our plugin system to Wedgets :P

Okay, I've done it -- split wedge_cache_css into two functions. The first one is called in loadTheme() and will build the correct list of CSS folders for use in skins (i.e. it will discard any parent folders if it meets a replace-type skin), and will retrieve the options for the current skin. The second one, wedge_cache_css, will go through the folder list built by the former function, and will build the actual CSS file. Performance-wise, it should be exactly the same as before, except that it's cleaner, and that it allows me to override the skeleton right after loading it from the theme. (Hmm, come to think of it... I should probably load the theme's skeleton after the skin's skeleton, to save on processing time... :lol:)
I'd have hoped this would make it easier to merge add_css_file with wedge_cache_css (their code is VERY similar), but it probably won't be possible, because each one has optimizations that the other couldn't use... I still have hope, though :P

Anyway... 'Done'.
Warm is running the modified skeleton, it has the sidebar on the left, but the rest of the content is crammed onto two vertical columns if the main content doesn't take much space (actually, it looks funny.) I guess I'll have to encase all of the content (and header, and footer) into their own div. Well, the structure isn't too great... I should probably add more layers, so that pretty much every block is encased within a special div that I can then manipulate as I wish.
That, or I actually allow adding functions within a file in the skin... Something like 'Custom.template.php', which would be loaded by Wedge at loadTheme time, and would contain overrides, i.e. "template_body_above_override". If such an override exists, Wedge won't run the original function. Of course, then, it's getting closer in spirit to a full-fledged new theme, and I don't know if I'm ready to make that big a jump...

Still got plenty left to do. Hopefully I'll be finished by tomorrow night... I'd really rather not spend too much time on this. I guess I can fix Warm later -- definitely not a priority (heck, I can simply remove the <skeleton> entry in skin.xml just to fix it for now...)

This isn't done for now but I don't see where it's going to be a problem.
The skeleton array is generated right from loadTheme(), so basically everything you add to it later (via loadSubTemplate) will be added to the array by Wedge. It'll be transparent...
I can also add a removeSubTemplate() function.
I'll also add something like loadLayer(), although I don't exactly know how it'll work... (i.e. where do we position it?)

BTW, I just found out that there's a slight miscalculation in my project.
The skin.xml override is loaded through wedge_cache_css, which itself is loaded through theme_base_css, which itself is called "at the last possible minute"... Although this works quite well for all of the overrides it has (html blocks, etc.), rebuilding the skeleton at that time will delete all of the existing subtemplates.

Hmm...

Don't really know how to fix that -- except by loading the CSS files twice: once early on for the skeleton override, and once at the last minute for block overrides. Yikes.... :-/
Any idea? I'll take a cigarette break.

I think we can at least safely say that a documentation project for Wedge is underway. It's pretty basic for now but it'll serve as a basis for more. The project is currently being held by Norodo from the forum :)

I'd just tend to have this philosophy: don't waste CPU cycles fixing crap made by badly coded mods or themes.

Btw I also tend to forget to update your documentation when I remove stuff hehe. For instance it referred to include_after_template which doesn't even exist anymore so I removed it ;)

I guess that, somehow, the tempting system could use a diet. Like so many other things you already did!

Btw - use default images AND templates? That's skin territory to me ;)

Great. I'll try to implement that tonight or tomorrow. :)

Mod compatibility with what? SMF? Well, it won't be the first rewrite they'll have to go through... ;)

rev 984
(2 files, 5kb)

* Small extra jQuery conversion. (ManageServer.php)

! Syntax error. (Aeva-Embed.php)

(It's not much, but I modified many files for the templating stuff and I'm trying to keep the 'other' files out of my way...)