« Saving Bytes Every Page - Or, How I Learned To Stop Worrying…
Mini-skeletons
Maybe it's the rum talking... (language editing for plugins) »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template edits
« Reply #15, on January 18th, 2013, 07:46 PM »
Quote
- I think that message lists are an excellent candidate for a 'special case' where we inject a mini-skeleton into the game. This doesn't have to be complicated...
I'd prefer it to be a bit *more* complicated, not less. Not for performance as such (though that's important) but because I'd love plugins to be able to be flexible. For example being able to juggle the order of items around in the poster area and inject new items in between things as desired.

But yes, the principle of being a mini skeleton is important.
Quote
- As for hooks, Wedge already has _before, _after and _override blocks available for anyone wanting to add some template code to an existing block. I don't see anything that can be done through hooks but not through block overrides...?
Override blocks replace the entire block, often that is not necessarily useful, though it can be for some cases. The thing about having such blocks is that they're more for the theme to perform overrides rather than plugins doing it - plugins are going to do it via the skeleton anyway, but it is nice to have the choice.
Quote
- I'd love to be able to say "we can also print a block to a temporary output buffer, then send it to a hook for post-processing, then send that buffer to the proper output buffer". It even makes a lot of sense, come to think of it... But I'm afraid that performance might be hurt by this process, especially in the Display pages (if we end up implementing the mini-skeleton.)
I'd argue that's overkill to be honest. Anyone that really wants to do that will inject into the buffer changes at the end.
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,080
Re: Template edits
« Reply #16, on February 1st, 2013, 04:35 PM »
Quote from Arantor on January 18th, 2013, 07:46 PM
I'd prefer it to be a bit *more* complicated, not less. Not for performance as such (though that's important) but because I'd love plugins to be able to be flexible. For example being able to juggle the order of items around in the poster area and inject new items in between things as desired.
Hmm...
I had an alternative solution in mind, which doesn't really fit your description.
Heck, I'll still mention it...

It's two-fold.
1/ Turning posts into macros. In the template we could have this:
<we:postwrapper>
  <we:poster>our poster data...</we:poster>
  <we:post><we:abovepost>our post header</we:abovepost><we:postbody>our body</we:postbody><we:belowpost>our buttons</we:belowpost><we:signature>our signature</we:signature></we:post>
</we:postwrapper>

Fill the macros with the usual -- and offer, for instance, an alternative that would use table tags to force buttons and signature at the bottom of a post if the body is just a couple of lines and the avatar is huge. One of the things that has bothered me ever since SMF 2.0 Beta 1 came out... ;)

2/ Implement a hook into macro replacement -- i.e. when I'm showing we:postwrapper, I'll automatically call_hook('macro_postwrapper'), where a plugin is then free to add their own code.

Point (2) is something I dabbled with when I was looking at skeleton code -- I mentioned it in my earlier posts (which I have difficulty remembering correctly, I guess I'll have to re-read this topic), I'd really like to add automatic hooks into template functions, so that plugins can add stuff without having to actually add a template override function (which might be already taken anyway...)

Anyway... That was what I was considering, because it's relatively easy to implement, and would allow plugins to add stuff to every post that would use macros.

Then again, this technique doesn't allow plugins to reorder elements within a mini-skeleton. But it also doesn't require us to provide miniature functions for each and every area of every post. I dunno...
Quote
Override blocks replace the entire block, often that is not necessarily useful, though it can be for some cases.
Say a template function only consists of function template_something() { echo '<div>'; }... You can replace that with a <table> or a <span>, whatever you want. Of course, more functions = more freedom and also more CPU used. You can't eat your cake and have it[1]
Quote
The thing about having such blocks is that they're more for the theme to perform overrides rather than plugins doing it - plugins are going to do it via the skeleton anyway, but it is nice to have the choice.
Yep, but that's precisely why it'd be a good thing to associate a hook with every single template function and their derivatives... (et le cul de la fermière[2].)
Quote
I'd argue that's overkill to be honest. Anyone that really wants to do that will inject into the buffer changes at the end.
That's a better alternative, indeed...
 1. I prefer the bawdy French version, "On ne peut pas avoir le beurre, l'argent du beurre et le cul de la fermière". It's worth digging out that old French dictionary eheh.
 2. :ph34r:

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template edits
« Reply #17, on February 1st, 2013, 04:41 PM »
I'm not generally opposed to this in principle. There are two things that I want to specifically touch upon, though.

1. Performance is going to be impacted, though not *massively* with extra hooks per template/macro/whatever.

2. It's still way too simplistic and doesn't achieve any of the things I really wanted out of a mini skeleton.

It lets me change the markup for the things around the content, but it doesn't easily let me add new items with any control. Supposing I wanted to replace the likes feature with something else. How do I do that?

Suppose I wanted to add more icons to the poster information, in a separate area under everything else. How do I do that?

Suppose I want to move the avatar above the group badges, how do I do that?

These are all things that the mini skeleton, as I envisaged it, would solve (trivially) but it seems that macros wouldn't, at least as outlined.

Bear in mind also that macros are one-off replacements per page, not per post which means more complexity to be attached.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Template edits
« Reply #18, on February 1st, 2013, 05:18 PM »
Quote from Arantor on February 1st, 2013, 04:41 PM
1. Performance is going to be impacted, though not *massively* with extra hooks per template/macro/whatever.
It's always going to be impacted. It's either this... Or SMF mods. Hurray for choice...
Quote
2. It's still way too simplistic and doesn't achieve any of the things I really wanted out of a mini skeleton.
I'm not so sure.
Quote
It lets me change the markup for the things around the content, but it doesn't easily let me add new items with any control. Supposing I wanted to replace the likes feature with something else. How do I do that?
<we:postlike>our like code</we:postlike>...? It's just a matter of determining how many macros we want to put into the loop.
Quote
Suppose I wanted to add more icons to the poster information, in a separate area under everything else. How do I do that?
Call the hook for </we:poster>... (Oh yes that means having two hooks per macro, hmm...)
Imagine </we:poster> says '</div>'. Just call the hook, get the macro contents in it, add <mycode> at the beginning, and voilà.
Quote
Suppose I want to move the avatar above the group badges, how do I do that?
That one's more of a problem.
Quote
Bear in mind also that macros are one-off replacements per page, not per post which means more complexity to be attached.
Oh, I also have a solution for that... Just implementing variables inside hooks, like I'm doing for the skeleton (see the bottom linktree one.) These variables would be carried along with the hook. Of course, that does mean doing something strange in our HTML, such as echo '</we:poster:', $id_msg, '>...
PS: macros are already quite powerful as it is -- look at the <if:param> if anything. They *can* be extended. It's mostly a matter of determining what you want to do with them in the end, and what you don't want them to be able to do, ever.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template edits
« Reply #19, on February 1st, 2013, 05:27 PM »
So, we want to add in 14 function calls per post we make?
Quote
<we:postlike>our like code</we:postlike>...? It's just a matter of determining how many macros we want to put into the loop.
Now imagine I want to totally trash that and replace it with something else? How do I do that from the macro, exactly? Normal template skeleton is easy: I just invoke wetem to replace that element.

I'd want to put in a hook for every item in there.
Quote
That one's more of a problem.
This is what I mean about having the flexibility of a template skeleton in there, because I (and others like me) will want to rearrange it. I'm trying, essentially to save us work in the long run by making this flexible and easy to change later on because I know people will want to change it.
Quote
PS: macros are already quite powerful as it is -- look at the <if:param> if anything. They *can* be extended. It's mostly a matter of determining what you want to do with them in the end, and what you don't want them to be able to do, ever.
Which brings me to my other problem. I don't entirely like setting rules on what people can and can't do with the platform. Having hooks necessarily puts limitations in and I want to minimise that where possible.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Template edits
« Reply #20, on February 1st, 2013, 07:41 PM »
Quote from Arantor on February 1st, 2013, 05:27 PM
So, we want to add in 14 function calls per post we make?
That's the thing... I'm perfectly content with not allowing anything :P

Oh, well.
Macros: no function call, but we'll add one hook (and thus, at least one function call, perhaps two if at least one hook is indeed used), per tag (including closer tags, that's x2). Maybe only call a hook if the tag has a variable in it...? (as in, "this is not your momma's macro"?)
Mini-skeleton: at least one function call per skeleton item. That's potentially less than for macros, unless you want to turn every single area into a function.
Quote
Now imagine I want to totally trash that and replace it with something else? How do I do that from the macro, exactly? Normal template skeleton is easy: I just invoke wetem to replace that element.
Oh, it's doable... I'm just not sure how right now... But the macros are all visible inside $context... They're only handled in ob_sessrewrite after all.
Quote
This is what I mean about having the flexibility of a template skeleton in there, because I (and others like me) will want to rearrange it. I'm trying, essentially to save us work in the long run by making this flexible and easy to change later on because I know people will want to change it.
Well, I feel you really want a mini-skeleton, so I'll code it.
Do you want it to be available in skin.xml? Or only through PHP calls..?
Quote
Which brings me to my other problem. I don't entirely like setting rules on what people can and can't do with the platform. Having hooks necessarily puts limitations in and I want to minimise that where possible.
But do we add automagic hooks to the skeleton system?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template edits
« Reply #21, on February 1st, 2013, 10:05 PM »
Mini skeleton is certainly my preference because it really does mean it becomes customisable and that also means less in the way of support issues later on.

Location? Why not a separate file, post.xml because it's not every page (unlike skins which necessarily are)? Best of both worlds that way, I feel.

If you have a skeleton system, that's addressable by wetem or similar, it doesn't need automagic hooks, because there's already a hook available for display purposes. Extensions get hooked there, job done.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Template edits
« Reply #22, on February 1st, 2013, 10:48 PM »
Only one hook?
So plugins use that hook to modify the skeleton and inject their templating right?

I'll also need to determine how many functions we split posts into.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template edits
« Reply #23, on February 1st, 2013, 11:03 PM »
I see no reason why we need any more than one hook ;) It's called late on, just before control transfers out of Display(), so plugins can do whatever they need to at that point.

Functions... off the top of my head, the post area is built out of:

username (including menu)
title
badges
avatar
post count
custom fields
thought
message icon
title (including new icon)
reply count / time
content
like
main actions (including menu, quick modify)
signature

Interestingly, that's 14 items per post as I originally noted, which naturally translate into a few more functions than that.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Template edits
« Reply #24, on February 2nd, 2013, 12:43 AM »
14*15 function calls is a lot.
And it doesn't help much if you want to rewrite just the message icon for instance. Well technically it'll be okay I guess.

How about one skeleton file per source file..? Like, skeleton-Display.xml? Or do we want to be able to have multiple mini skeletons per page?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template edits
« Reply #25, on February 2nd, 2013, 12:46 AM »
Well... I can envisage one scenario where we would want multiple per page: blog layout (one for the blog post, one for replies)

If you want to just rewrite the icon, actually you'd just change it in the post hook itself, not fart around replacing the template it for it, so we could fuse that into the title or something.

Definitely needs thought.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Template edits
« Reply #26, on February 2nd, 2013, 08:39 PM »
Quote from Arantor on February 2nd, 2013, 12:46 AM
Well... I can envisage one scenario where we would want multiple per page: blog layout (one for the blog post, one for replies)
Hmm yeah, that's true... My proposal wasn't very thoroughly considered anyway.

So we'll have to work with keywords...
i.e. main skeleton = 'main'? Or 'root'?
Any other mini-skeleton = code gets to choose the name... We could have 'msg' for generic posts, 'blog' for blog posts, 'blog-msg' for blog comments (with a fallback to msg..?), 'gallery' for a gallery item, etc...
Of course, it also depends on whether we're ready to multiply the number of stand-alone functions in each template... ;) We already did a good share of that in the past, though.

So, skin.xml could have only the main options.
skeleton.xml or root.xml could have the root skeleton
skeleton-msg.xml or msg.xml could have the msg skeleton, etc... (Please submit any filename structure standards you'd see as more 'logical' to users.)
Having them in different files allows a skin to redefine only the way posts are shown. Even more power to the people.

Worst of all, I think it's actually going to be fun implementing this change... :)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template edits
« Reply #27, on February 2nd, 2013, 08:48 PM »
Keywords works fine :)

All the suggested names work fine for me (though I'd choose main over root)

skeleton.xml should contain the main one, then skeleton-****.xml for the others.

Fun is a relative definition, I personally do not think I would find it fun, but that's sort of how I felt about the ban system and it was more fun than expected when getting down to it.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Template edits
« Reply #28, on February 2nd, 2013, 09:12 PM »
Quote from Arantor on February 2nd, 2013, 08:48 PM
Keywords works fine :)
If we set filenames to be the entire keyword, we need to rename 'skin.xml' to something more descriptive, like 'options.xml', 'skin-options.xml', 'settings.xml' or even... 'skin-info.xml'. I think?
Quote from Arantor on February 2nd, 2013, 08:48 PM
All the suggested names work fine for me (though I'd choose main over root)
root has the advantage of implying it encapsulates everything (as in 'document root'), while main could be seen as either 'only shows the <div id="main"> section' or 'default skeleton' (which doesn't mean anything...)
Quote from Arantor on February 2nd, 2013, 08:48 PM
skeleton.xml should contain the main one, then skeleton-****.xml for the others.
Works for me. If it's skeleton.xml, then either root or main, it doesn't matter.
Any suggestion for the default post skeleton keyword..? Something that would work for you?
Quote from Arantor on February 2nd, 2013, 08:48 PM
Fun is a relative definition, I personally do not think I would find it fun, but that's sort of how I felt about the ban system and it was more fun than expected when getting down to it.
Thankfully we enjoy our programming differently... And that's for the best: because we focus on what we enjoy the most, we tend to work on two different areas that complement each other, i.e. the front-end and back-end code. I absolutely love that you're 'unofficially' in charge of the admin area (and have done wondrous things to it!), and that I can do my best on trying to make it look good. :)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template edits
« Reply #29, on February 2nd, 2013, 09:16 PM »
Quote
If we set filenames to be the entire keyword, we need to rename 'skin.xml' to something more descriptive, like 'options.xml', 'skin-options.xml', 'settings.xml' or even... 'skin-info.xml'. I think?
Hmm, yeah.
Quote
Works for me. If it's skeleton.xml, then either root or main, it doesn't matter.
Any suggestion for the default post skeleton keyword..? Something that would work for you?
msg as a suffix works just fine for me for the main post structure, with blog for the main blog post and blog-msg for blog replies, as suggested.
Quote
Thankfully we enjoy our programming differently... And that's for the best: because we focus on what we enjoy the most, we tend to work on two different areas that complement each other, i.e. the front-end and back-end code. I absolutely love that you're 'unofficially' in charge of the admin area (and have done wondrous things to it!), and that I can do my best on trying to make it look good.
Thank you :) Mostly it's just about making a UI that doesn't feel put together by developers. There are a lot of things that are put in for the convenience of developers and not users.

And for the look of Wedge, you do it very well :) I would even go as far as saying that your flair for making it look good has rubbed off on me, I never used to worry about making things look good.
« Saving Bytes Every Page - Or, How I Learned To Stop Worrying…
Maybe it's the rum talking... (language editing for plugins) »