-
Probably an old topic, but if I want my plugin to edit a template how would I go about it? Say, I want to make a plugin to indicate whether the poster of the post is the OP of the topic or not, I'd need to modify a specific area of Display.template but I'm not sure how to do that without modifying the template itself. Any ideas or is that not possible yet?
:edit: Modified topic subject -- Nao.
-
I'm sure there are multiple ways to do this... There should be a hook with the message content somewhere, so you might be able to simply add something to the body that says it's the OP...
If you want to add something somewhere else, I guess we'll have to add hooks for per-post templating. But that would be a good thing, of course. Not sure how to deal with themes that wouldn't follow them, though... (Their loss?)
Or maybe something could be done at template rendering time... I remember I wanted to add a mini-template just for posts, so that you could add a template_after or template_before etc that would apply to EACH post... I don't think it's possible for now.
-
Per post templating is one of the things we've not touched for the obvious reason of keeping it lean and not sure how to do it without it being a total mess.
-
Oh... I don't know. I'm sure it's not that complicated. I wrote most of the needed code I reckon.
For instance, the skeleton system has no problem running a sub-template several times, like the linktree code. It just needs two different arguments -- <linktree> and <linktree:bottom> in our case. There's nothing preventing us from having a <message:0> entry where the message numbers are indicated in the skeleton.
Of course, this would all have to be done through wetem::calls rather than skin.xml editing because it's a skeleton that needs injecting inside the main area of a single template. But it's all done I think...
Haven't had time to look into it, though. I'm hungry.
What do you think? (About this. Not that I'm hungry. You silly.)
-
Well, it's complicated to do nicely.
Essentially running a subtemplate several times is the way to go, provided that the sub template can be run with injecting $message into it in some fashion.
Remember, the template itself (yes, ugly I know) gets the $message and all the information for it from prepareDisplayContext. This would also solve a bunch of other stuff if we can do it, because it would allow easy extension of the poster info in a nice way, or replacing likes with something else in a post.
-
It isn't just the post template I'm curious about, just any template in general.
Can something like hook tags be added to the templates which are replaced by HTML added by hooks during the buffer rewriting, where you also process the <we:cat> etc. Add a bit more pre-defined templates (similar to <we:cat> etc) and theming cannot be a complete mess.
EDIT: The above idea is potentially stupid for contextes where data processed in the template is required....
Second EDIT: This above idea is actually pretty stupid in almost all the cases, this is almost same as adding a call_hook to templates and that can actually pass data.
-
<we:cat> is down to the skin itself, as is <we:title> and <we:title2>. The skin defines what they are meaning that the skin can provide whatever markup it likes for them.
It would be possible to add more, sure - but what? Replacing the we:cat/title/title2 were the big ones.
As far as other templates it really depends on what - the main structure of plugins has been to allow plugins to add new subtemplates - they can replace entire subtemplates in the skeleton too.
Everything else we'll take on a case by case basis.
-
<we:cat> is down to the skin itself, as is <we:title> and <we:title2>. The skin defines what they are meaning that the skin can provide whatever markup it likes for them.
It would be possible to add more, sure - but what? Replacing the we:cat/title/title2 were the big ones.
As far as other templates it really depends on what - the main structure of plugins has been to allow plugins to add new subtemplates - they can replace entire subtemplates in the skeleton too.
Everything else we'll take on a case by case basis.
-
And there's the rub: free template editing is very liberating but it's also very fragile - and this applies to even systems like XenForo that have a templating system with its own meta markup.
I'd rather just flat out deny that and figure out reasonable compromises in the meantime.
-
True that.
While we're on topic, can I ask a core feature request to indicate whether the poster is the OP? :P...
-
You can request it :P
On a more serious note, what did you have in mind? I've thought about adding CSS classes to the post container for things like topic starter, whether the person is an admin and so on.
I'm open to suggestions for other layout issues (and to me, this does seem more like a plugin candidate than a core feature)
-
You can request it :P
On a more serious note, what did you have in mind? I've thought about adding CSS classes to the post container for things like topic starter, whether the person is an admin and so on.
I'm open to suggestions for other layout issues (and to me, this does seem more like a plugin candidate than a core feature)
-
Well... here's the thing, if it were done with a class, you could use ".root.starter .mime a" as a selector for the name and add something with the before pseudo thingamajig.
If there were some ability to set up the post template as a skeleton it would be even easier to do with conventional layer injection.
Posted: January 18th, 2013, 07:25 PM
Oh and yes, there is the facility to inject into prepareDisplayContext already.
-
Oh classes should be added for contexts, they can provide good theming opportunities if nothing else.
-
Wow, too many posts...
I'm not going to answer anything, I'll just reiterate a few things and ideas, mostly for my own benefit because I'm a bit confused right now...
- 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... Something like <post:id><post_wrapper:id><post_author:id><post_body:id></...></...> where id has the list of posts... Then we inject that into the skeleton. Probably through wetem calls as I said, so it doesn't need to rebuild the skeleton, or as an actual skeleton if we offer users the ability to redefine the post skeleton in skin.xml or something. Then at rendering time, Wedge just calls the blocks as expected. I don't really see any show-stopper here. Is there...?
- 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...? However, it might be a possibility to add a call_hook on a dynamic hook based on the template name. That might give plugin authors the ability to use whatever they like best, i.e. either a block or a hook to insert.
- 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 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...
But yes, the principle of being a mini skeleton is important.- 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...?
- 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 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.
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...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.
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.
-
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.
-
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?
Imagine </we:poster> says '</div>'. Just call the hook, get the macro contents in it, add <mycode> at the beginning, and voilà.Suppose I want to move the avatar above the group badges, how do I do that?
Bear in mind also that macros are one-off replacements per page, not per post which means more complexity to be attached.
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.
-
So, we want to add in 14 function calls per post we make?
<we:postlike>our like code</we:postlike>...? It's just a matter of determining how many macros we want to put into the loop.
I'd want to put in a hook for every item in there.That one's more of a problem.
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.
-
So, we want to add in 14 function calls per post we make?
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.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.
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.
Do you want it to be available in skin.xml? Or only through PHP calls..?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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
Well... I can envisage one scenario where we would want multiple per page: blog layout (one for the blog post, one for replies)
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... :)
-
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.
-
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?
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.
Any suggestion for the default post skeleton keyword..? Something that would work for you?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.
-
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?
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?
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.
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.
-
Woohoo, I just realized that by saving skeletons in their own files, I can actually get rid of the index template's skeleton now, and just include it in skin/skeleton.xml, and just consider that if a skeleton isn't found in a skin folder, it should use the parent folder's... :)
(Well, I *think* this is how it could and should be done. I haven't looked at the specifics yet. There may be another reason why I did it that way... But I don't think there was.)
(Then again, the index template's skin shows that it can be injected programmatically through wetem::build(). Maybe that's good enough a reason to keep it that way... But I'd probably rather have a 'sample plugin' that does the rewriting and build() calling by itself.)If we have everything in skeleton-*.xml, then skin.xml can stay skin.xml. Or be renamed to skin-info.xml (which I like less), to be consistent with plugin-info.xml. What do you prefer?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.
Thank you :) Mostly it's just about making a UI that doesn't feel put together by developers.
Oh, and with my select box code, wizards just feel so cool to use. :lol: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.
Finally, Warm is a bit of a bugger to me... I'm always tempted to drop most of its color set and go for something really "web 2.0" or whatever, with very bright and saturated colors... Oh, if you could see my local Warm... I'd never commit it, it's too.... It's just plain too much ;)
-
If we have everything in skeleton-*.xml, then skin.xml can stay skin.xml. Or be renamed to skin-info.xml (which I like less), to be consistent with plugin-info.xml. What do you prefer?
Could be message, too... There's no actual reason to go for a 'short' name.
Yup. Going the Wizard route is something that the early SMF devs tried to do (e.g. installer), but they stopped midway I guess. You're continuing their legacy.
Oh, and with my select box code, wizards just feel so cool to use. :lol:
Also...
WIZARD NEEDS FOOD BADLY.Ah ah. But quite honestly, I'm still unhappy with so many things.
-
Okay, re: plugin-info.xml, to me it'd make more sense to have 'plugin.xml', but it's your 'area', so your preference matters more ;)
Regarding skeletons, I've been considering multiple ways of doing it these last few days, most of them 'unclean'.
So, the two that remain right now are these:
- the 'realistic' solution: wetem remains a singleton, but wetem::$skeleton becomes an array of skeletons. Same for wetem::$layers, etc. Has the advantage of being easy to transition. Can do wetem::render() to render the main skeleton, and wetem::render('message') to render a specific mini-skeleton. Drawback: not that it's necessary inelegant, but having a singleton to manipulate multiple objects can sound strange...
- the 'object-obsessed' solution: wetem becomes an actual object system, we'd then do $msg = new wetem('skeleton-message.xml'), or something like that. Then $msg->build(), then $msg->render(). Main advantage: it looks way better in the code... Main drawback: okay, I can't possibly imagine asking plugin authors to insert a global for $rootSkeleton (or something) and then call $rootSkeleton->add('sidebar', 'my_block') to add a block to the sidebar... This seems uglier to me than wetem::render('message').
I'm trying to figure out whether it's possible to have the best of both world, i.e. if wetem::render is called, then we automatically redirect to the $rootSkeleton object, and if $something->render() is called, render said object. I don't know whether that's possible right now... I could imagine storing the main skeleton inside its own static (or global?! meg...) variable, then relying on it if function render() doesn't find a qualified $this value. But, we'd have to do the same for add(), and so on...
So... Any opinions? I'm afraid I'm not in the best position to comment on object creation :P
Posted: February 6th, 2013, 03:48 PM
Adding to the question.
Both solutions are complicated IMHO...
- Staying static sort of feels like I'm from a procedural world (which is true), and that I'm trying hard to remain traditional while giving the appearance of working with an object.
- Going half static, half dynamic probably means I'm going to have to duplicate a lot of functions... One for mini-skeletons, one for the main skeleton. (Which I'm tempted to rename internally to 'backbone', dunno why :lol:) And that could be even more confusing. Just look at wetemItem: I'd have to rewrite it to address both the 'backbone' and any other skeleton. Because right now it's just acting like it's one big static skeleton. I'll give a try to mixing static and non-static functions and see how they behave when called dynamically and statically.
- Going fully dynamic would be the way to go, but as I mentioned earlier, I would absolutely hate having to force plugin authors to declare a global for backbone/root/main manipulation. I've given them power with so many methods -- I don't want this to be at the cost of simplicity in their main code. And don't get me started with $_GLOBALS['backbone']->build()... Alright? :lol:
---
Okay, it was too hard on me, I decided to immediately try for a simple version of the dynamic/static test I mentioned. Here's the code I tried... Note that all the class and method names are French synonyms of the word 'thing' :P
class truc
{
static function machin ()
{
echo 'Hello ', isset($this);
}
function bidule ()
{
echo 'World! ', isset($this);
}
}
error_reporting(E_ALL | E_STRICT);
truc::machin(); // Hello
truc::bidule(); // World!
$chose = new truc();
$chose::machin(); // Hello
$chose::bidule(); // World!
$chose->machin(); // Hello
$chose->bidule(); // World! 1
I'm surprised that I'm not getting any crashes, or even any warning from PHP at this point..?!
This was done with PHP 5.3.4, downgrading to 5.2.9 gave me a 'parse error' crash on both $chose:: lines, meaning only PHP 5.3+ supports using a static call from within a dynamic object. Or something... More 'interestingly', $chose::$any_static_variable doesn't work in PHP 5.2.9 either, even though the php.net docs seem to indicate otherwise.
So, it seems there's something that... could be done, I guess... Regarding using 'wetem::add()' for the main skeleton and '$other->add()' for other skeletons without duplicating the 'add' function -- something like if (!isset($this)) $skel = self::$skeleton; else $skel = $this->skeleton...??
It still makes life complicated and forces me to rewrite all functions to use a pointer to the desired array ($skeleton, $layers...), rather than directly access self::$layers or whatever.
I'm still not much used to all of this... It's really not my initial area of expertise. I think it's important that I get it right on the first try, which is why I haven't developed anything so far.
Waiting for opinions and ideas, then...!
Posted: February 6th, 2013, 05:49 PM
I may have found a solution...
http://www.php.net/manual/en/language.oop5.overloading.php#object.call
Basically, set all functions to be private. Calling wetem::add will invoke __callStatic, in which I'll first check through the list of authorized function names, then if allowed, redirect to that function while passing self::$instance as the instance, while $object->add will invoke __callStatic which does the same, but passes $this as the param.
I'm not sure it'll work... But it seems... possible?!
Posted: February 6th, 2013, 06:27 PM
F*ck! __callStatic (not __call) is PHP 5.3+ only... -_-
Posted: February 6th, 2013, 07:46 PM
Okay, there may be a possibility that it "just works"...
error_reporting(E_ALL | E_STRICT);
print_r(wetem::$skeleton);
$a = new wetem();
$a->skeleton = array('DELETED');
print_r($a->skeleton);
print_r(wetem::$skeleton);
(Of course, I removed the 'private' keyword for $skeleton.)
The first print_r gives me the main skeleton.
The second print_r gives me 'DELETED'.
The last print_r gives me the main skeleton.
So, it would seem that wetem:: acts just like a regular instance of wetem, and keeps the data associated to it.
Which is pretty good. And means I wasted more hours trying to fix a problem that didn't exist in the first place... :^^;:
Now, the only issue is that E_STRICT supposedly should/would return a warning when calling one of these, because it doesn't like to mix static and dynamic stuff.. But it doesn't give me anything.
Oh, bugger... Forget what I said.
Inside the $a instance, $this->skeleton gives me DELETED, while wetem::$skeleton gives me the main skeleton. I should have guessed...
So it's back to the isset($this) test on each function... Or giving up and using arrays for every instance. :(
Anyone..? I hate talking to myself all day... :whistle:
-
Don't use magic functions, they're pathetically slow. Can't you simply declare static functions in a base class, declare a new singleton class for main skeleton extending the base which has calls to the parent class but also passes the first parameter and keeps everything sane? That or make a new class for only one skeleton (you need more than one?) which is singleton and has instance object to return the only instance that it has?
-
Don't use magic functions, they're pathetically slow.
They're only called if the method isn't found.
I've been thinking it over last night, and figured out I didn't really need to have __callStatic...
I can simply implement __call, and then pass all the information about the current object to the static wetem object.
For instance, $message->build() would magically call __call(), which would then pass the data to wetem::build($message->id_object) or something. For instance, I could store the contents of the static object into a temp var, replace the static object's vars with the dynamic object's, call the static function, then replace the static object vars with the temp vars.
Of course it's going to be much slower... But we're talking about relatively small arrays. My only concern is with calling these things repeatedly... It'd be better, I guess, to have a dynamic object in the first place and __callStatic to bind the backbone to a dynamic object, because wetem we know isn't being accessed a lot. But we don't have that leisure, as __callStatic is PHP 5.3 only. Unless Pete wants to reconsider our minimum PHP version. But that particular use case probably wouldn't be enough to justify it...
Then again, we could also simply use arrays of arrays. wetem::$skeleton['backbone'], wetem::$layers['backbone'], things like that...Can't you simply declare static functions in a base class, declare a new singleton class for main skeleton extending the base which has calls to the parent class but also passes the first parameter and keeps everything sane?
Well, now I guess we could hmm... Well we don't have that many public methods in the object in the first place, that's true.
(I also liked having the 'final' keyword on wetem... It's the only time I ever used it, and because I use it in Class-CSS, it sounded cool to also have it in a proper PHP class :lol:)That or make a new class for only one skeleton (you need more than one?) which is singleton and has instance object to return the only instance that it has?
I'd really like more of your input on this, as well as Pete's -- and anyone who's into OOP really. (Yeah, OOP, not the other word I used last time, remember Shitiz :lol:)
-
But.. THAT slow?
They're only called if the method isn't found.
But that's pretty much like one of my first suggestions, duplicating everything...?
Well, now I guess we could hmm... Well we don't have that many public methods in the object in the first place, that's true.
But it would thus require to do wetem::getInstance() every time we want to access the main skeleton. To me, it's exactly the same as doing a global $backbone thingy... Isn't it?
$backbone = null; // Have fun suckers!
Or here's another fun idea, make a base template class (dynamic, ofcourse) which is not a singleton. Then make a singleton class which is the main skeleton (extend it and make the constructor private and add getInstance), use it for the backbone skeleton and add a function in base class that can import full skeletons from an instance of the class to that class. This way a mod can do something like create it's own skeleton, and import it to the main skeleton.
-
Or here's another fun idea, make a base template class (dynamic, ofcourse) which is not a singleton. Then make a singleton class which is the main skeleton (extend it and make the constructor private and add getInstance), use it for the backbone skeleton and add a function in base class that can import full skeletons from an instance of the class to that class. This way a mod can do something like create it's own skeleton, and import it to the main skeleton.
-
Yep, except I don't understand that suggestion... ;)
Using functions is something I considered yesterday too, doing things like wetem_add() that would redirect to wetem::getInstance()->add(), but it's even more overhead... Imagine that: a function call, then a static call, then a dynamic call...
I could rename getInstance() to something more 'direct', like wetem::backbone(), but it's still too long. wetem::main()->add() simply feels odd to me. I don't really know where this is going...
All I can say is, I did a last attempt at making a static class that extends on the dynamic one, and call $this everywhere. No functions at all inside the static class. Not surprised here: it all works... until the dynamic methods get called and try to access $this. It's a bit annoying, but it's as it is...
-
So... I wrote this.
I dislike the list of functions, but I made them one-liners, so it basically looks a lot like wetemItem.
final class wetem extends weSkeleton
{
private static $instance = null; // container for self
// What kind of class are you, anyway? One of a kind!
private function __clone()
{
return false;
}
// Bootstrap's bootstraps
static function getInstance()
{
// Squeletto ergo sum
if (self::$instance == null)
self::$instance = new weSkeleton();
return self::$instance;
}
function has($item) { return wetem::getInstance()->has($item); }
function has_block($block) { return wetem::getInstance()->has_block($block); }
function has_layer($layer) { return wetem::getInstance()->has_layer($layer); }
function build(&$arr) { wetem::getInstance()->build($arr); }
function render() { wetem::getInstance()->render(); }
function get($targets = '') { return wetem::getInstance()->get($targets); }
function before($target, $contents = '') { return wetem::getInstance()->before($target, $contents); }
function after($target, $contents = '') { return wetem::getInstance()->after($target, $contents); }
function remove($target) { wetem::getInstance()->remove($target); }
function move($item, $target, $where) { return wetem::getInstance()->move($item, $target, $where); }
function parent($child) { return wetem::getInstance()->parent($child); }
function load($target, $contents = '') { return wetem::getInstance()->load($target, $contents); }
function add($target, $contents = '') { return wetem::getInstance()->add($target, $contents); }
function first($target, $contents = '') { return wetem::getInstance()->first($target, $contents); }
function replace($target, $contents = '') { return wetem::getInstance()->replace($target, $contents); }
function rename($target, $new_name) { return wetem::getInstance()->rename($target, $new_name); }
function outer($target, $new_layer = '') { return wetem::getInstance()->outer($target, $new_layer); }
function inner($target, $new_layer = '') { return wetem::getInstance()->inner($target, $new_layer); }
function hide($layer = '') { return wetem::getInstance()->hide($layer); }
function layer($layer, $target = '', $where = 'replace') { return wetem::getInstance()->layer($layer, $target, $where); }
}
Fact is... It seems to be working. The original wetem class is now weSkeleton, and is entirely dynamic.
What do you think..? Is it worth calling functions that will simply redirect to... These anyway?
Well, I think I could event get away with wetem::getInstance() calls by simply using self::$instance. I'm going to do that, as getInstance() is always called at startup anyway.
-
'kay, I've done everything I said, and also rewrote a bit of wetemItem (renamed to weSkeletonItem) to handle both wetem and weSkeleton objects.
And I'm happy to report... That it's all working just fine :)
With the added benefit that a dynamic class is (very slightly!) faster than a static one, this should help alleviate some of the load on our future message skeleton (considering it'll be rendered 15 times per pages... It's always best to put the priority on this rather than on the main skeleton, which is only rendered once.)
So... Do you think I should keep my code as modified, or I should ditch wetem:: altogether and use either a global $skeleton or a series of functions...?
Or even something I just thought of... Well, a bit silly but...
wetem()->load()
function wetem()
{
static $instance;
if (!$instance)
$instance = new weSkeleton();
return $instance;
}
Lol... This is actually ALL I would need in the entire codebase... No need for the wetem object anymore, no need for function duplication. Hmm. And to think I didn't think of that silly little 4-line function until NOW..!
wetem()->load() or wetem::load()? Which one looks best to you? Which would you rather see used in Wedge..?
-
wetem()->load() or wetem::load()? Which one looks best to you? Which would you rather see used in Wedge..?
-
/mehas several copies of this tab open now at differing levels of the topic :/
wetem()->load() is unusual. It's fine, of course, but it feels unusual to write. wetem::load() would be better.
/mecan't mentally deal with thinking through all the other consequences right now.
-
/mehas several copies of this tab open now at differing levels of the topic :/
wetem()->load() is unusual. It's fine, of course, but it feels unusual to write. wetem::load() would be better.
/mecan't mentally deal with thinking through all the other consequences right now.
-
Performance is a big consequence to me as well as ease of use.
I don't really mind ease of use being changed provided it's not made insanely hard to use. The current setup is not that hard to use, which is fine with me.
-
I don't think there's a significant difference between a function call and a static method call.
-
Never benchmarked it to be honest.
-
From what I could read, function call > dynamic method > static method, which are the slowest, but it's all in the vicinity of, like, a 5% difference...
Posted: February 7th, 2013, 09:53 PM
We could also, "why not", use this: wetem::$main->load(), where wetem is really limited to just holding a 'public static $main' variable and a singleton to initialize it... Hmm well... :^^;: It's a bit long, though, but it'd be the fastest method, by a small margin.
-
It's only really an issue if you have lots and lots and lots of these going on, or in a loop.
I'd rather have readable than absolutely maximise performance.
-
I made the commit, so you should be able to get a feel of it for yourself -- there's nothing new compared to what I posted above, though..! Just a few name changes and all.
-
Mini-skeletons... Done!! :eheh:
The good news is that it doesn't look like it takes a lot of CPU cycles out of the new system. I'm doing reloads on a page and seeing 0.10s-0.13s in 'old' mode, and 0.11s-0.13s in 'new' mode. Could probably get 0.10s too, but I don't really mind... Even if it cost an additional 0.01s per page load, seriously... Who cares?!
I kind of dislike having to reproduce globals for every little mini-block, but that's really the only price to pay at this point...
I have a very basic skeleton for messages, I guess considering the good performance, we could look into expanding it more, to add more flexibility to it.
All in all... A good use of this last hour eheh.
Posted: February 8th, 2013, 09:29 AM
I'm bored! :P Waiting for an e-mail that never comes...
Implemented a prefix system, i.e. if you have a series of template_msg_block functions, you don't have to define 'msg_block' in your skeleton, only 'block', but I don't know if it's very useful or self-explained... Maybe it could add more confusion if anything, I don't know. What do you think..?
Was considering also adding a 'temp disabling' of blocks/layers, i.e. on the next render() call (and only this one), Wedge will automatically skip anything that's in a special array of temporarily disabled blocks and layers. This makes it possible to remove a few tests out of the functions themselves, and move them to the database loop where we get $ignored and other things. Bad or good idea?
And finally, the current system is simple, I'm calling ->render() on every loop as mentioned above, but some people might see it as "moving the source code out of Sources and into Templates". What's best? Calling ->render from where you INTEND to place it, or for instance setting up a 'trigger point' to launch all of the rendering in one go (i.e. no loops in the Display template), after initializing all mini-skeletons in a go from the Sources file? Pro: it's semantically better. Con: we lose the benefit of saving memory... Still, I don't it as a big issue either. Maybe it was important in 2003...? But the number of posts per page hasn't increased in 10 years...
-
The problem as I see it would be the case of 'all' posts. For long threads you could conceivably bugger it up by forcing the PHP process to run out of memory by having too many posts. I'm thinking Aeva-sized threads here.
I've never been a huge fan of 'all' anyway and it certainly wouldn't kill me to remove it and it would solve this problem until someone sets an abnormally high count per page.
-
No problem. What about my other ideas?
Posted: February 8th, 2013, 02:14 PM
Another suggestion. Moving the message template to a new file. Makes it easier to call it from pm or recent posts or whatever. I think I'll do that :)
Posted: February 8th, 2013, 02:15 PM
Oh I misread your post. Do you want to move the render stage to sources then?
-
I haven't formed an opinion on what's best yet, haven't had my morning caffeine dose. :/
If it's semantically better in the sources, do it. It's not like it is now limiting what theme authors can do with it...
Message template in a new file is fine, though be careful: PM is slightly different. The buttons are different (there's no quick edit, no mini menu and if there were, the options would be different), PMs do not have an icon, they do have a 'sent to:' bar.
-
I haven't formed an opinion on what's best yet, haven't had my morning caffeine dose. :/
Back in the early 00's, I usually went to bed at 5am and woke up at 11, it wasn't really good for me. True, I work better at night, but come to think of it, I simply work better when I'm off from bed or bed time is closing in. It's not really a matter of being a night owl... To me at least.If it's semantically better in the sources, do it. It's not like it is now limiting what theme authors can do with it...
If I allow for temp disables for instance, I'm sure themers would be glad to have the ability to do it on their side, regardless of the source file's decision. (Of course, they can also remove the skeleton bit they want out, but temp disabling is precisely about letting go of one item in one particular occurrence, e.g. a first post in the page, or whatever.)Message template in a new file is fine, though be careful: PM is slightly different. The buttons are different (there's no quick edit, no mini menu and if there were, the options would be different),
PMs do not have an icon, they do have a 'sent to:' bar.
Possible solutions: include every possible function in Msg.template.php (or whatever), and add/remove skeleton items at Template time. In the skeleton, provide something like <skeleton id="msg" context="topic"> and then the skeleton... And <skeleton id="msg" context="pm"> for PMs. Then provide two different skeletons using the same source. Or have <skeleton id="msg" file="Msg"> for topics, or <skeleton id="msg" file="Msg,PersonalMessage" for PMs, where the skeleton would take both templates and take their functions from both templates. Hmm... No, it would make more sense to do it all by code... In the PM template, run $skeleton = new weSkeleton($message_skeleton) then manually do a $skeleton->replace('body', 'pm_body'), for instance... You'd just need to have a function template_msg_pm_body() in your PM template to accomodate for this.
As of now, Wedge is already smart enough to do that...
It still needs some discussing. Also, the prefix thing... I'm not all too sure about that. It'd probably be confusing and would be best to have a skeleton filled with <msg_...> blocks, even if it makes it a bit bigger. It'll still have the same number of lines...
-
So, you're back to your days under the moon eh..? Preference or just plain chance?
Back in the early 00's, I usually went to bed at 5am and woke up at 11, it wasn't really good for me. True, I work better at night, but come to think of it, I simply work better when I'm off from bed or bed time is closing in. It's not really a matter of being a night owl... To me at least.
Actually, I came across a theory about why we work better at night - http://swizec.com/blog/why-programmers-work-at-night/swizec/3198If I allow for temp disables for instance, I'm sure themers would be glad to have the ability to do it on their side, regardless of the source file's decision. (Of course, they can also remove the skeleton bit they want out, but temp disabling is precisely about letting go of one item in one particular occurrence, e.g. a first post in the page, or whatever.)
Well, why no quick edit..? I certainly can't think of any reason why there shouldn't be. Email notifications, maybe? The problem is a bit of the same with normal posts...
OK... what benefit would it serve to be able to edit a PM? Would it serve a benefit? It's not like it's mass-audience and if there's any ambiguity or confusion, it can be followed up with private messages.
Normal posts don't entirely have this problem. Yes, there's the notifications aspect, but the reality is that most people will see the post on the forum itself, whereupon it has the benefit of typo-fixing, updates and so on. The content is the 'final resting place' of that content, so to speak. It is, conceptually, for all time in that place. Thus it gets revisions in place so that the place is not moved and bookmarks etc. all still work.No, it would make more sense to do it all by code... In the PM template, run $skeleton = new weSkeleton($message_skeleton) then manually do a $skeleton->replace('body', 'pm_body'), for instance... You'd just need to have a function template_msg_pm_body() in your PM template to accomodate for this.
Also, the prefix thing...
-
I've had sleep, I'm back to bed at 5am, up at just past lunchtime. This is my normal routine, really.
Actually, I came across a theory about why we work better at night - http://swizec.com/blog/why-programmers-work-at-night/swizec/3198
I'm trying to conceptualise where a temp disable would actually be used. I think the idea's great but I don't yet see an actual 'example case' for it.
For instance, in the template, you get <footer> tags around the footer area if $context['ignoring'] is set. Instead of adding two tests in _before and _after, I figured I could simply disable these functions earlier in the code flow. Then it struck me that I couldn't disable _before and _after function calls, only the entirety of the block (_before, _after and the actual block itself), and adding a setting to disable only the _before and _after would make it look fucked up.
But just after that, I had to create a $context['show_action_bar'] variable to determine whether the action bar should be shown... And it's tested in all three places: before, during and after. In that particular case, having a temp disable could help me disabling the action bar very quickly.
I agree, though, that there's nothing that couldn't be addressed by what I'm doing right now -- $context variable tests in the individual functions.
But it's also an easy addition, I think... (?)
Just set $context['temp_disables'] or something (do you have a better name to suggest...?), and in the render_recursive function, if isset($context['temp_disables'][$id]) then return directly, do not pass Go. Then at the end of the render process, just unset the context var.There's absolutely no way to edit a PM once it is sent. I have never once questioned this logic, perhaps I should.
Heck, we could even have a feature to delay sending of PM notifications by a minute or so, just like Gmail does to give you time to cancel a sent message ("You're fired!" -- Oops, wrong To: field... Where's that Cancel button?!)
If it detects you're editing the message when it's supposed to send it, it can delay it by an additional minute, etc...
Okay, it's probably a BIT much for not much in return...! But sometimes, it could be helpful. I think.OK... what benefit would it serve to be able to edit a PM? Would it serve a benefit? It's not like it's mass-audience and if there's any ambiguity or confusion, it can be followed up with private messages.
Alright, we could also simply disable the Quick Edit button in the msg skeleton... :lol:This seems to make sense but I think it's the sort of thing that will only truly make sense when it is done and can be poked and prodded.
Anyway, all of this can be reverted later...
I've also gotten rid of the prefix.
Will commit my WIP soon. At least, it's working... ;)This affects both types of message, incidentally. I'd put it as part of however the subject is set up.
Posted: February 8th, 2013, 03:41 PM
(I've implemented 'temp disables' and renamed it to just... 'skip', which makes more sense. The function is accompanied with a description that explains it's just for the next pass.)
-
I don't really remember you doing that other than for the last few weeks, except occasionally...
Started reading... Will have to forward to Milady, maybe it'll help her understand why I'm always systematically pulling a Cinderella... :P
Well, this came up when I wrote the mini-skeleton for Msg, really.
For instance, in the template, you get <footer> tags around the footer area if $context['ignoring'] is set. Instead of adding two tests in _before and _after, I figured I could simply disable these functions earlier in the code flow. Then it struck me that I couldn't disable _before and _after function calls, only the entirety of the block (_before, _after and the actual block itself), and adding a setting to disable only the _before and _after would make it look fucked up.
But just after that, I had to create a $context['show_action_bar'] variable to determine whether the action bar should be shown... And it's tested in all three places: before, during and after. In that particular case, having a temp disable could help me disabling the action bar very quickly.
I agree, though, that there's nothing that couldn't be addressed by what I'm doing right now -- $context variable tests in the individual functions.
But it's also an easy addition, I think... (?)
Just set $context['temp_disables'] or something (do you have a better name to suggest...?), and in the render_recursive function, if isset($context['temp_disables'][$id]) then return directly, do not pass Go. Then at the end of the render process, just unset the context var.
There's absolutely no way to edit a PM once it is sent. I have never once questioned this logic, perhaps I should.
Heck, we could even have a feature to delay sending of PM notifications by a minute or so, just like Gmail does to give you time to cancel a sent message ("You're fired!" -- Oops, wrong To: field... Where's that Cancel button?!)
If it detects you're editing the message when it's supposed to send it, it can delay it by an additional minute, etc...
Okay, it's probably a BIT much for not much in return...! But sometimes, it could be helpful. I think.
OK... what benefit would it serve to be able to edit a PM? Would it serve a benefit? It's not like it's mass-audience and if there's any ambiguity or confusion, it can be followed up with private messages.
Alright, we could also simply disable the Quick Edit button in the msg skeleton... :lol:
This seems to make sense but I think it's the sort of thing that will only truly make sense when it is done and can be poked and prodded.
Anyway, all of this can be reverted later...
I've also gotten rid of the prefix.
Will commit my WIP soon. At least, it's working... ;)
This affects both types of message, incidentally. I'd put it as part of however the subject is set up.
(I've implemented 'temp disables' and renamed it to just... 'skip', which makes more sense. The function is accompanied with a description that explains it's just for the next pass.)
-
'kay, since it'll take a while to answer this, I'll just commit my current work so you can look into it in the meantime!
Done.I've been doing it for months. Look at the time stamps of commits. Even as far back as last May, commits from me for 3am or later were becoming increasingly common. If you look at my stats, there is no hour of the day that doesn't have at least 17 posts attached, and 5am ish has quite a few...
I guess it just didn't jump to me that it was that regular.
Heck I didn't realize I myself posted a few messages at ALL hours of the day! But apparently, except for 3 posts, 4am is the hour where I'm sure to be asleep!
(Feature suggestion™: make these links clickable to actually see the posts I made at 4am... Wondering if they're intelligible at all :lol:)Implemented :)I'd sort of prefer something not in $context but that sounds like where it should be.
Oh, can you believe that for the first time in my nearly 38 years of existence, I actually built an OBJECT from the ground up, that is not a SINGLETON, and that is actually more USEFUL than any equivalent procedural/functional code, and easier to read?
I'm astonished. I've always been anti-objects, but weSkeleton at least proved that large, complex code can benefit from being objectified... Well, not the case for Wess though, but I did my best too ;)OK, I'll kick off a discussion on it. There are a lot of other things to consider about the aspects attached, and I'll bring them all up.
That makes sense to me :)
I really did a basic one, as you'll see. <msg_author> is just a single block of code, I just didn't feel like splitting it into as many functions as needed. Feel free to do it by yourself, otherwise I'll just do it later on.Have whatever that indicates the prefix as part of the subject template bone and that way it can be sorted out by the template.
Originally I used 'msg' as a prefix, but I figured it was best used as a proper ID, for rendering quirks, i.e. main skeleton vs mini-skeletons. There were at least two places that needed to test against the main skeleton.Let the source indicate it is a reply through whatever means it has to but then the template can display it, whether it wants to use an icon or anything else.
Hmm, maybe we could do something like... (prototype ahead!)
<copy-skeleton from="msg" to="pm">
<rename from="msg_author" to="pm_author">
</copy-skeleton>
Or something like that... Thus, no need to copy the actual skeleton, meaning that inherited skins can simply modify the parent skeleton and the rest will follow.Most used word of the day. :angel:
-
All right Sherlock :P
I guess it just didn't jump to me that it was that regular.
Heck I didn't realize I myself posted a few messages at ALL hours of the day! But apparently, except for 3 posts, 4am is the hour where I'm sure to be asleep!
(Feature suggestion™: make these links clickable to actually see the posts I made at 4am... Wondering if they're intelligible at all :lol:)
Don't worry, as soon as I implemented it, I renamed it to an internal array... It made way more sense as it was a per-skeleton thing anyway.
Oh, can you believe that for the first time in my nearly 38 years of existence, I actually built an OBJECT from the ground up, that is not a SINGLETON, and that is actually more USEFUL than any equivalent procedural/functional code, and easier to read?
I'm astonished. I've always been anti-objects, but weSkeleton at least proved that large, complex code can benefit from being objectified... Well, not the case for Wess though, but I did my best too ;)
That makes sense to me :)
I really did a basic one, as you'll see. <msg_author> is just a single block of code, I just didn't feel like splitting it into as many functions as needed. Feel free to do it by yourself, otherwise I'll just do it later on.
Have whatever that indicates the prefix as part of the subject template bone and that way it can be sorted out by the template.
Originally I used 'msg' as a prefix, but I figured it was best used as a proper ID, for rendering quirks, i.e. main skeleton vs mini-skeletons. There were at least two places that needed to test against the main skeleton.
Let the source indicate it is a reply through whatever means it has to but then the template can display it, whether it wants to use an icon or anything else.
Hmm, maybe we could do something like... (prototype ahead!)
<copy-skeleton from="msg" to="pm">
<rename from="msg_author" to="pm_author">
</copy-skeleton>
Or something like that... Thus, no need to copy the actual skeleton, meaning that inherited skins can simply modify the parent skeleton and the rest will follow.
Most used word of the day. :angel:
-
Could even just show the links to individual posts, without bothering to show the posts... Hmm?
I'm still wrangling with design work for the new warning system right now.
I think I should just do <skeleton id="pm" extends="msg" /> and be done with it..?!
Then have skeleton commands like <move> elsewhere. I don't know. But this is also the kind of situation where I wonder, "should a move to the parent skeleton affect the child skeleton as well...?", and then BAAAAAH.Not even close. The f-bomb has been dropped many more times today. Lots of stupidity out here in real life.
-
Could even just show the links to individual posts, without bothering to show the posts... Hmm?
I'm still wrangling with design work for the new warning system right now.
Yeah, but it's not so great when it comes to consistency.
I think I should just do <skeleton id="pm" extends="msg" /> and be done with it..?!
Then have skeleton commands like <move> elsewhere. I don't know. But this is also the kind of situation where I wonder, "should a move to the parent skeleton affect the child skeleton as well...?", and then BAAAAAH.
Not even close. The f-bomb has been dropped many more times today. Lots of stupidity out here in real life.
-
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...The concept of displaying an individual post on its own is nothing new - vB did it (I assume it still does but the train wreck since vB 4, I have no idea what it does and does not do any more)
No. Bans are for getting rid of people. Warnings are for less serious matters, behavioural correction. The current warning system is a bit limited.
Well, such behaviour is fine if it is documented, especially if there is a given actual use in the core.
I can already feel the headache coming up... Ahh... Ahhh... Yes it's here.Today has been... interesting.
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:
-
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...
The concept of displaying an individual post on its own is nothing new - vB did it (I assume it still does but the train wreck since vB 4, I have no idea what it does and does not do any more)
No. Bans are for getting rid of people. Warnings are for less serious matters, behavioural correction. The current warning system is a bit limited.
I've long since wanted to break the warnings down into smaller units, and throw in extra ones - like removing avatars, signatures for people who can't be trusted, or the infamous Disemvoweler. (The grunt of that is already implemented, it just needs the rest of stuff implemented for it)
That, combined with predefined warnings that come with predefined behaviours (or at least, allow the admin to set these things up), e.g. see a user with an inappropriate avatar, send them a preset warning that automatically removes their avatar for a day. Just for example.
These are things the current warning system can't do.Well, such behaviour is fine if it is documented, especially if there is a given actual use in the core.
I can already feel the headache coming up... Ahh... Ahhh... Yes it's here.
Today has been... interesting.
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:
-
OK, so I was ruminating on this today. One of the things I wanted in the mini-skeleton is the ability essentially to be able to juggle poster info around and inject new areas, and having it as one huge <msg_author> block kind of bugged me.
So I juggled it around and I came up with this:
<msg_author>
<msg_author_title />
<msg_author_avatar />
<msg_author_group />
<msg_author_badge />
<msg_author_blurb />
<msg_author_postcount />
<msg_author_icons />
<msg_author_cf />
<msg_author_warning />
</msg_author>
I split it all out, and while it's ugly, it does work as expected. I haven't bothered prettying it up because I'm not sure about committing it yet, mostly because I haven't been able to meaningfully benchmark the performance aspects.
More importantly, it does mean a lot of extra tests are being done unnecessarily at this point because of course, $msg['member']['is_guest'] and $context['is_mobile'] need to be tested a lot more. Still there's ways around that - I see no reason why Display couldn't do the test then alter the relevant skeleton instance to just cut those functions from being called, entirely.
There's also stuff like $gts being redeclared every function call and stuff (rather than checked and force-set properly earlier on) but that's all fixable stuff.
What it does mean, though, is people can move things around easily - and plugins can easily add things wherever they want, rather than just tagging it on to the end of msg_author.
So, what do you reckon? Clean up and commit or rethink?
-
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 :P
- Adding the tests directly into the skeleton tree: I guess we could do it in several possible ways...
-
- 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:
<msg_author>
<msg_author_title />
<msg_author_avatar />
<msg_author_group />
<if !SKIN_MOBILE>
<msg_author_badge />
<msg_author_blurb />
<msg_author_postcount />
<msg_author_icons />
<msg_author_cf />
<msg_author_warning />
</if>
</msg_author>
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.
Posted: March 8th, 2013, 02:35 PM
- Is this how you want it to be, exactly..?
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)
-
So...
- First implementation of your request is in revision 1988.
- I only dealt with we::is tests, which don't encompass skin options.
- It should be trivial to add support for basic skin options in wedge_skin_condition() (also, feel free to rename the function.)
- But I didn't do it (yet!) because my focus was on harmonizing user/browser tests to also include other specifics that are in skin filenames, i.e. member (instead of just 'guest'), mXXX (member #XXX), bXXX and cXXX (specific boards and categories). And I'm trying to determine if skin options belong here..??! I'd tend to say 'yes, they do', but while it's easy to test against '!SKIN_MOBILE', it's more time-consuming to do more elaborate things like 'SKIN_SIDEBAR == left' in a we::is test... I'd be tempted to say, maybe SKIN_SIDEBAR should be renamed to SKIN_SIDEBAR_LEFT/SKIN_SIDEBAR_RIGHT/SKIN_SIDEBAR_NONE, at least it'd become a simple boolean test... What do you think?
- I've tested exclusively with a single test in skin.xml, where I'm loading a font for myself. It worked. It may break in other situations, and in skeletons.
It's 22:36 and although a bit early to go to bed, I've had a very, VERY long week, I'm tired, and I decided to commit this and let you play with it (and have a chance to comment on my design decisions, or even fix anything), instead of postponing my commit to tomorrow.
So... Have fun ;)
-
at least it'd become a simple boolean test... What do you think?
Haven't had chance to try it yet but I'm excited with the direction things are going :)
-
I agree, booties are cool.
What do you mean, though? That you agree I should use booleans for the sidebar constant..?
-
I'm thinking it would probably be better, all in all, yes.
-
Implemented, and working. :)
Oh, and you can do silly things like this:
<if !SKIN_MOBILE && member, guest, ie7 && SKIN_SIDEBAR_RIGHT>
<my_monster_block />
</if>
I know... Very useful :lol:
I'm considering whether to allow for lowercase skin_* tests in skeletons and other we::is() places, though. It does feel more natural to me... I don't know..? Opinions please?
-
What does that mean? :P
-
Seems powerful, that block would be displayed to: members with mobile skin AND guests AND who has the right sidebar on. Right?
-
Nope, it would be displayed to: members if it's NOT a mobile skin, OR guests (in all situations), OR people running IE7 if the skin has set the sidebar to be on the right.
Maybe it's time to get rid of "," as an OR separator, and instead force the use of || everywhere, like in PHP or JavaScript... Since Wess is programmer-oriented and there's already support for brackets, bangs and ampersands, it would make more sense.
Posted: March 12th, 2013, 09:46 AM
The main problem with the <if> implementation, if anything, is that it's never going to be enough...
I've been working on rewriting the skin since last night, and found that:
- there are situations where part of a block is skipped in SKIN_MOBILE (msg_author_group) and forces me to have two identical functions, a mobile one and a desktop one, with the only difference being an extra code block for desktop,
- some blocks are unskippable... Namely, the _before and _after tricks. In msg_author_after, SKIN_MOBILE is also tested, and I can't "skip" this test from within the skeleton. It would force me to write a different wrapper from msg_author just for skins...
But that would result in: <if !skin_mobile><msg_author><blocks for desktop></msg_author></if><if skin_mobile><msg_author_mobile><blocks for mobile></msg_author_mobile></if>... So much for flexibility if we have to maintain two very similar versions of <msg_author>'s before and after pseudo-blocks. :-/
Meh...
I'm still converting the stuff. You'll all decide after that, I guess...
Posted: March 12th, 2013, 10:12 AM
Support for <else> added (and tested). It's so much easier when you don't have to care for indenting (as it's all pseudo-XML), I feel like a cheat! :lol: