Wedge

'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.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:)Implemented :)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 ;)Thanks!We'll just need to split the existing skeleton into more functions, to make it possible to do these.
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.You mean "new weSkeleton('msg')"? Have a look at the source, that's what I did eventually ;)
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.My code uses the <skeleton id>, so it wouldn't be able to see the context unless we use a modified skeleton with a different ID.
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:

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... :PWell, 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.Here's a suggestion... Why don't you post a poll or at least create a new topic to discuss this? I'm sure it's a feature that many people would want -- and also, possibly, would dislike. I personally would rather have it.
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.Which is why it may be a 'bit much'.
Alright, we could also simply disable the Quick Edit button in the msg skeleton... :lol:Plus, I've resumed work on it... Did a few (lot of?) changes in the code path followed to create the main skeleton. For instance, wetem::hide() is called automatically by Wedge if the main skeleton can't be found -- which is either intentional (Ajax data), or accidental (not uploading skeleton.xml to the skins folder). At the very least, you'll be getting the default layer, instead of the "corrupted skin" fatal error. One could argue that the corrupted error is better for debugging, but I'm just not sure about it. For instance, if someone reloads your page WHILE you're upload a new copy of skeleton.xml, they might end up with that error, instead of at the very least getting the content they wanted.

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... ;)Whadayamean..?

(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.)

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.Sure, but theming is precisely one of the arguments that could come in when thinking of whether it's best or not.
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.)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...It's the kind of thing that you can hack into...
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...

No problem. What about my other ideas?

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 :)

Oh I misread your post. Do you want to move the render stage to sources then?

What do you mean, don't like mine? :niark:

rev 1904 -- doing this update separately so it doesn't increase the KB count artificially.
(+1-1 file, 238kb)

* Updated jQuery UI local version to 1.10, just like the remote versions. I don't know, though, if it's really a good thing to provide a 222KB minified file for local use... (scripts/jquery-ui-*.min.js)

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...

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.