Theme manager design: Comments needed

[Jon Bomgardner]

List,

First, I've been pretty busy as of late so I haven't had time to do much but I hope to get back on track when I get the current site completed....

Now for the real reason for this post.

I've been reviewing the requirements we laid out for the new Theme engine (ThemeManager) and have a concern. I really don't think this is going to be possible without breaking some of the API. Because we will need to retrieve assets (CSS and HTML) asynchronously from the server anything that can currently be chained off of the constructor will probably need to be changed or removed. In order to do this properly, we will need to interrupt the rendering pipeline that's currently in place to fetch those assets. That means that when the constructor returns any widget will be in an unfinished state.

To illustrate, here's the current "pipeline" (showing methods and events):

new Widget() -> initialize -> prePluginInit event -> pluginInit() -> postPluginInit event -> preInit event -> init() -> preRender event -> render() -> postRender event -> postInit event -> initializeDone event -> return to caller

To implement the new ThemeManager we're looking at something more like this:

new Widget() -> initialize -> prePluginInit event -> pluginInit() -> postPluginInit event -> preInit event -> init() -> ThemeManager.getAssets() -> fire XHR(s) to server -> return to init -> postInit event -> return to caller
(and some time later) XHR returns to ThemeManager.processAssets() -> widget.render() -> postRender event -> initializeDone event (now widget is ready for use)

Personally, I don't see any other way to handle it and maintain the ability to swap themes on the fly.

I guess, after all that, my question to the group is whether this is acceptable or not? Keep in mind that we'll probably need to release it as a major version since the API would change.

Comments are encouraged of course!

Jon

[Paul Spencer]

Hi Jon,

sorry for the delay in response.  I'm not sure I understand the full ramifications of the rendering being completed asynchronously.  That being said, I think its okay.  What do you think of separating render from the initialize  so the initializeDone event would fire synchronously with construction?  As render can happen asynchronously, we'll need a flag in the widget to know that a render is in progress and possibly delayed waiting for assets.

Cheers

Paul

Jon

--
You received this message because you are subscribed to the Google Groups "JxLib" group.
To view this discussion on the web visit https://groups.google.com/d/msg/jxlib/-/PDhqju6wiTMJ.
To post to this group, send email to jx...@googlegroups.com.
To unsubscribe from this group, send email to jxlib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jxlib?hl=en.

[Jon Bomgardner]

That's pretty much the conclusion I came to as well. As for the ramifications... anything that we would chain off the constructor that needs a rendered widget (such as .add(), .addTo(), etc) would need to be done instead on the conclusion of the rendering. I'm thinking we fire an event when the rendering is done and you would then be free to do what you needed with the widget.

I have actually started coding this (found a way to manage loading stylesheets in a specific order without using XHR to grab them) but I'm not sure when I'll have something for people to look at. I'll put it in a separate branch (perhaps a jxlib-4 branch as this will not be entirely API compatible with the current 3.x branch).

Jon 

Paul

To unsubscribe from this group, send email to jxlib+unsubscribe@googlegroups.com.

[Paul Spencer]

could add() and addTo() automatically register for the correct event if the widget is pending initialization of assets?  That would minimize the impact of the change I think.

To view this discussion on the web visit https://groups.google.com/d/msg/jxlib/-/aU2Fn_QcwMkJ.

To post to this group, send email to jx...@googlegroups.com.

To unsubscribe from this group, send email to jxlib+un...@googlegroups.com.

[Jon Bomgardner]

I guess they could... we'd probably have to do the same for any function that needed a fully rendered widget.  It doesn't quite feel right but I'll give it a try....

Jon

[Jon Bomgardner]

There is now a "proof of concept" branch in the repo: https://github.com/JxLib/JxLib/tree/theming

Here's how it works:

1) Checkout the branch
2) run ./build.sh --target require
3) open the test2.html page in the require directory under examples.

This is all VERY rough and there is a LOT left to do. I just wanted to get a proof of concept up for people to look at and comment on.

Let me know if you have any questions of comments. I don't have time to write an explanation of how it all works but if I have time later I will.

Thanks,

Jon

On Wednesday, April 18, 2012 4:01:26 AM UTC-7, pagameba wrote: