Wedge

Added support for <move> on any skeleton, but also for <rename> and <remove>... Dunno what else I should support...
Also, I decided to have these commands in skeleton.xml instead of skin.xml, but I'm not sure what's best.
Wedge loads all skeleton.xml files (parents and children), from root to deepest level, and concatenates them. It doesn't care about 'replace' type items, mostly out of laziness. skin.xml is loaded but also deleted everytime it finds a new child skin.xml... I don't really know which is the best 'behavior'... Perhaps I should even drop support for replace-type skins... But I'm not confident that Weaving is simple enough to accomodate for everything. Meh...Oh, you mean that... No, I just meant showing a list of links to the posts, each pointing to them 'in context'.I never saw it as limited... But then again, you're the specialist.. :^^;:Or maybe have two types of child skeletons, like in permissions... a copy type, and an extend type. copy = independant, extend = uses the same stuff as its parent(s).
I can already feel the headache coming up... Ahh... Ahhh... Yes it's here.I won't insist, all right... :^^;:

Mine has only been interesting by the fact that Milady is travelling with a friend and thus I had all the time I needed to take matters in hand and finish the mini-skeleton system... Which would have probably stalled otherwise... :whistle:

Technically speaking, an if() test is always going to be so fast, that any alternative would be a waste of time. I was wary of doing mini-skeletons, precisely because of the growing number of tests and function calls, but in the end, it was really nothing to be scared of. The entire rendering of topic mini-skeletons added something like, a millisecond or two to the overall execution time... So, really, splitting the current Msg mini-skeleton into ten times more functions wouldn't kill performance either, after all the most time spent when rendering a page is on the client side, not server side. Always has been... Always will be.

I can't see many alternatives either, anyway.

- Removing skeleton entries at Sources time: implies calling wetem::remove or weSkeleton->remove, it's not particularly much faster... And not as flexible, either.
- Adding the tests directly into the skeleton tree: I guess we could do it in several possible ways...

<if member>
  <this_skeleton />
</if>

or

<member@this_skeleton />

or

<SKIN_MOBILE@this_skeleton />

or

<mobile@this_skeleton />

or

<SKIN_SIDEBAR==left@this_skeleton />

or

<this_skeleton:params:SKIN_MOBILE />
<this_skeleton::SKIN_mobile />
<this_skeleton:params@SKIN_MOBILE />

or

<this_skeleton:SKIN_MOBILE:params />
<this_skeleton::params />
<this_skeleton@SKIN_MOBILE:params />

None of these really strike me as 'nice-looking', except possibly the last one (we don't use params THAT much... Only in linktrees, I think, for now.)

I'm absolutely willing to implement one of these, of course, if it gives themers and plugin authors even more flexibility. And we all hate doing tests at the beginning of each function, of course... I just don't know which way to go.
Of course, '@' is a temp separator I came up with to say, "this template block is intended for (directed @) members", etc. It probably isn't XML-compatible, but as everyone probably knows, the skeleton isn't parsed by a XML library, it's only written that way to help with readability. (Heck, I could very well switch to a JSON-like structure, and then actually parse it with json_decode()... Hmm, idea to explore...??!!)

I started this topic, apparently :PWouldn't that simply make things even slower? Parsing the skeleton and then testing would be slower than directly having an if (), although it'll be little more readable since everything would be in an XML-esque space. But either way I like the splitting of template bits into smaller pieces, that certainly gives a lot of flexibility. I have one question though, how would one grab the context of the template bits? I mean they're called in loops, how will the plugin know the current variable and process accordingly?

- Well, I split it off from another topic, and thought your post was the sanest to start it with... ;)

- I really don't think any solution has a notable performance advantage against the others. It's really down to what you prefer. Anything that takes less than 10 milliseconds to execute is not worth optimizing against. And the skeleton system parsing and executing, by itself, is fast enough. (The template blocks themselves can take time to execute, of course -- that's why I did my basic benchmarks against a copy of Wedge with the older skeleton system, and a copy of it with the newer mini-skeletons.)

- What do you mean by context bit..? I don't see a lot of variables available to test against. Mobile and Sidebar are two skin variables that can be overridden by a sub-skin, and thus the skeleton can be modified without touching the skeleton code in the sub-skin (although, as it happens, Wedge also supports some instructions such as <move>, which make it possible to fine-tune the skeleton even more.) Also, member and guest are two 'classic' pseudo-variables that should be of use here and there. Other than that, hmm... Maybe a browser variable. That should probably be accepted, too, although I think browser hacks should be generally done at CSS level, rather than HTML level, but if the template block uses a flexbox or display:table model and doesn't provide for an easy way to rewrite the block (e.g. <we:my_block>), it could always be overridden with a browser test, I guess... (Damn IE!!)

By context bits I mean like the message author part, the block is called under the Display template's main loop. Now I wanna show each member's topic by post ratio multiplied by their DOB, so I inject a template at the end of <msg_author> skeleton, how would that work? Would I have access to the current post's information which is being displayed?

I'm afraid, there's no magic in this... ;)

Just look at the Msg template file: every little function has a $msg global in it. You'll need to use that.
Of course, there's always a possibility we could do away with a global and either use a function parameter or something else entirely, but... There's no really much point in that, is it..? If you need $msg, you're probably in a more complex function that also needs some other global. Otherwise, you're in a 'presentation' layer that just adds a div or something, so you don't need any globals.

Themers can also pass a variable to any block with the block params system (see bottom linktree in main skeleton, really.)

Ah okay, that sort of clears things up. I'll wait till one actually commits this to Display to play with it.

Putting it into context:


Everything else relates to actual content in $msg so it wouldn't necessarily be done at the skeleton level, and once the is_mobile test is outside of the main functions, the 'post was not made by a guest' text can be removed too because all the other texts (they have badges, they have icons etc.) will all return false anyway because those values just won't be set for guest posts.

What could always be done is instead of creating a global $msg, it could always be part of $context, e.g. $context['current_msg'] or somesuch.

- Is this how you want it to be, exactly..?

- I prefer $msg, in this case. I have no doubt putting it into $context makes more sense, but I wanted something that was fast enough to type, and easy enough to remember.
I'm trying to figure out how to do it... For instance, at parse time, however we do it, multiple identical tests will be stored in the skeleton at the same position... (Layers can only have one name.) Which I guess can be circumvented by adding a random number at the end, which we'll ignore if at render time, the layer is seen as being an 'if' test.

Hmmm...

I don't really know what I want specifically, just some method of being able to exclude blocks from the skins based on being mobile or not. Don't really mind how.

In the meantime, I think I'm going to commit the changes I have for this.

Sub-skin:

<option>
  <mobile>1</mobile>
</option>

<remove block="..." />

So, technically, any mobile skin can delete anything they want, and I'd rather have the extra CPU time (spent on removing blocks) pushed to the sub-skin, rather than its parent...

It's a different matter for member vs guest, of course.

I don't really mind how it's done as long as it can be done - if the mobile mode can remove the given blocks from the msg skeleton, we can remove the tests in the msg template for 'not mobile'. (Which has the happy side effect of removing the 'if is member' test because if they're not a member, they won't have the other stuff to display anyway)