I was writing an addon just now and came across an odd situation.
I am using the integrate_user_info hook. I'd need to load a template in a certain case, but at that point of the code, the $settings is not yet initialized, so use loadTemplate fails badly.
I was thinking at what could be best, and I can see two options:
1) an "easy" way out would be to create a sort of "buffer", a variable that collects any early call and waits to actually load the template until it is possible,
2) the alternative would be more "heavy", loadTemplate should not load any file at all, it would just collect all the templates and wait until just before Elk starts rendering the page to actually load all the files in just one go.
I have to say I like option 2 more... O:-) :P
Opinions?
I think I had run into a similar issue myself in the past; though I can't remember the exact case. The second option does indeed sound better. It should provide a clean solution while giving all the flexibility needed for customizations.
meh... option 2 is not so easy to achieve (or at least I didn't see how to) without breaking a few things... and at that point of the development I'm not confident enough... lol
I did a quick&dirty 1:
https://github.com/emanuele45/Dialogo/commit/88cef7019496b46286cae688e4b1fdd5681aaeb2
that doesn't change anything in the way loadTemplate is used.
With the current setup, the latest you can delay loading the templates would be loadTheme because of the template_init sub template. I'm not sure how hard changing that could be. Except that, you probably can delay it until template_header call in obExit.
That looks pretty good and clean to me. I actually like that.
I think I tried obExit, but then it was becoming difficult to deal with init functions inside templates (like template_BoardIndex_init) because that were calling loadTemplate again and it was not forwarding to the proper code and the proper code was a bit of a mess, etc. :-[
@Spuds I just found another small bugles: using the auto-splitting tags (ctrl+enter) [SiNaN]'s quotes are re-opened like this:
[quote author=[SiNaN]
Not a big problem, just a mention. :P
:D
I didn't know about the init sub templates in the other templates; I thought there was only the one in index template. That's a new addition I assume - one that makes things more tricky indeed.
I bet the number of bugs you come across will be cut down by half once I stop coming here. :D
In fact... no, nothing new, it existed in SMF as well (2.0), I just started using it. :P
No, no, you can't stop coming! I need bugs!!! LOL
Thats not something easy to fix in the js (the way its currently done), in fact I don't think we could fix it the way its done, it would require a bit of a rewrite.
One potential solution is in parse_bbc where the author= information is added, the author name could be sanitized at that point, replace some of those characters with entity codes. I'm not sure why its not done that way now?
Don't ever say that even in jest and don't ever underestimate our ability to create bugs :P
Yep, I imagined...
Possible, we can experiment and see what breaks and what not. :P
Probably it's done this way just to display the expected username to the users that otherwise would have to deal with odd entities to write a quote.
Thinking about this some more ... its quotefast that would need to be updated, and then undone when posted. At least for the quick reply area, so no easy way out :P