Wedge

@above> Uh, I hope this is working by now... :P Haven't looked into the code for a while... And I still have to finish moving the 'change skin' setting to the menu.

Okay, I'm looking into parse_bbc() and I'm micro-optimizing it... It's surprising the number of things that were left hanging, such as "strlen($possible['tag'])" being used a dozen times inside a *loop*. Or "1 + strlen(..) + 1". I understand it's done for clarity, but inside a loop, over time, it still wastes time adding 1 and 1 when it could just be using 2...

Now, I also found a surprising amount of substr($something, $somepos, 1) instead of just $something[$somepos]. It's stunning, really. Now, if substr is overloaded to behave like mb_substr, I can understand the use of the first, but it's never done by SMF so obviously it could simply use the bracket version...

I seem to remember potential problems in future versions of PHP with the bracket version. Do you remember anything about that, Pete?

IIRC, mb_ overloading isn't going to be controlled by SMF, but by php.ini. Mind you, I haven't seen a server that has it set up because of the performance overhead it would naturally cause.Only if you use the old format, e.g. $var{0} which is deprecated in 5.3.

Just as I thought, thanks. I just couldn't find docs about that. :)

yeah i remember fixing the above in smf as we used it in a few places.

I was doing some benchmarks on serialize() and json_encode(), and found that json_encode() was about 50% faster... Nice. I was already preparing to use it instead of serialize() in cache_put_data(), but then I benchmarked unserialize() and json_decode(), and this time json_decode is about 40% slower... Duh!

I suppose this puts an end to my little idea, eh? I mean, I suppose it's more vital to have a fast cache decoder than a fast cache encoder. What do you think? (Maybe you have different results?)

I have had different results in the past. It really depends on the content type as to whether JSON decoding will be faster.

My test data was 2-3 levels deep of arrays, where the final level would be an array of numbers. It's definitely faster decoding (indexed) arrays of numbers than anything that involves strings, I can definitely tell you that.

Fast decoder is more important than fast encoder, certainly.

I guess I've never appreciated the difference between your skeleton and template layers.

Now, I see your comment that your skeleton can be multi-branched.
I've recently been arguing that this is a necessity for doing a Portal/CMS type of thing -- you need to go down, come up, close out a "box" start a new "box", and go down layers again....

It's a necessity not just for a portal or CMS but for plenty of other things, WedgeDesk already makes use of the earlier partial implementation, after emulating parts of itself before.

Very interesting. Does the earlier SimpleDesk do this, as well?

Sure, it emulates things with template layers, but WedgeDesk can do bits of it more cleanly, where it can inject blocks into the sidebar, and will do more once the skeleton structure is in place.

Layers have always been frustrating... And one-dimensional.
I can't believe SMF got away with it for so many years -- unlimited nested layers, but only one sub-template in the entire page...! It's one of the first things we changed in Wedge -- adding support for multiple sub-templates. Although by now, even that sounds a bit limited, now that the skeleton fixes so many things.
Heck -- I no longer have to rely on a hack to support sidebars! NO HACKS! What do you say :lol:
And skins can remove the sidebar altogether without breaking anything. Haven't tested, but it should be doable... (They can also simply move it to the bottom of the screen and re-style the sidebar area to allow for a horizontal layout, of course. I'd recommend that, because getting rid of the sidebar is okay, but its content...? Not so much.)

BTW, I'm currently pondering whether I should rename some of the things in the template system.

Current: Sub-templates. Suggested: Blocks. Rename loadSubTemplate() to loadBlock().
Current: Blocks. Suggested: Macros, or Snippets. Ultimately, a 'macro'[1] better represents what it does: suppress the need for boring repetition of a more-or-less large part of code, allowing for the dynamic replacement of certain values within it.

Well, at least we call these 'macros' in French. Dunno if it's the same in English but it seems to be the case...

1.	Phonetically, it also translates to "pimp" in French. What an interesting language :lol:

I can, actually, because it's so massively underutilised. I flippantly[1] remarked somewhere about the number of people who use template layers. It is, after all, a pretty select club.

The group ultimately consists of people who had to know about them to get the job done: themers who do anything of substance, portal authors, and the limited hardcore (people like me, Nao, Live, who can justifiably claim to know SMF at a sufficiently deep level).

Because it's such an elite club, it's practically black magic, that people will take the easier route of, like using file edits instead.

Fun fact: there is a mod out there that adds a footer menu. Nice idea, reasonably well done, and done with a template edit, leading to all kinds of hassle.

I suggested more than once that it could (and should) be done with template layers, because that would instantly remove almost all support queries about installation. But no, template edits are seemingly fine... or at least, the suggestion wasn't even dignified with a reply.[2]It depends what happens if a sub template requests through the likes of loadSubTemplate to be added to a given layer. If the content is discarded because its destination doesn't exist, there is arguably a problem.

One would assume themers would likely keep it or provide a space that can be called 'sidebar', so that content which expects to go into it can be diverted there.Yes, macros would be the term to use. (Emacs = editor macros :P)

I don't know the history of the term that gives you the derivation of pimp, but macro does have linguistic basis as a prefix for 'widening of range', of sorts, hence macro-management is where you manage the very broadest things (as opposed to micro-management where you manage the tiniest details)

1.

And, to be frank, somewhat rudely about one person in particular.

2.

I'm not bitter that they ignored the suggestion when it was made in sincerity to benefit them. I'm bitter that the author was at the time an SMF Customizer. I always felt that people in that position should be encouraging people to write better code, not just signing off on existing code. Sure, it's underutilised but in that position, you should either know the code relatively well - or learn about things like that which are documented and can be used to truly great effect with a little imagination.