Manager Template Engine (MTE)

Quote from: aNoble at Nov 09, 2005, 07:53 AM

This all sounds great to me! I love the placeholders idea.

Do you think we should implement some sort of caching in the manager? I think it would be very helpful for the language placeholders, especially.

We could but I think that would have to be done for every template/theme used. Remember that users can use diferent templates.

Some how I don’t think these "tags" will slow donw the manager that much. so I would like to get your feedback on this. Or should we just use <?php ?> tags instead.

Nah... let’s eat our own dog food!

Yea, I say let’s give it a try. If it’s slow then it shouldn’t be too difficult to add caching in later.

Quote from: aNoble at Nov 09, 2005, 08:46 AM

Yea, I say let’s give it a try. If it’s slow then it shouldn’t be too difficult to add caching in later.

Ok,

Jeff, Jason, Victor? Any other suggestions, ideas?

It’s too early for Jason... sleepy head... lol

I’m farily confident there will be no objections with Jeff or Jason, though.

Well...I guess my concern is the same for everyone else...performance!! On the performance end of things, well....I guess we won’t really know till we start coding it and testing it.

One thing I think we need to keep in mind is that the layout for the manager should really be open ended...meaning that the author of a template can not only change the look and feel but also the functionality of how it works.

For instance, if we parse the main menu items as list tags then a MTE author could create their own script and coding to create the functionality for that menu. I personally like the idea of a tabbed layout but not everyone would like this. Leaving out any javascript or such for the menu and instead placing it in the template code is much better and allows template authors more flexibility.

When it comes to placeholders, I think they should be customizable as well in the manager. The default placeholders (the main menu and such) obviously shouldn’t be removed and certain default items might be candidates for the ability to disable them should the user not wish for them to be used in any template. From here, a user can always create additional items via the use of snippets and whatnot...which is, of course, what we’re already talking about. At least this way, templates for the manager can be zipped and shared by others on the main site without fuss about whether certain placeholders should be used in a template. If a placeholder is disabled, then the parser simply won’t display it or the div container for it. Simple!

I’d be willing to be a boatload that even in a raw, unoptimized form using a raw, unoptiized script.aculo.us we’ll pick up at least double the speed of the current manager. At least in Safari and FF... not enough experience in IE right now.

Quote from: xwisdom at Nov 09, 2005, 07:47 AM

The next thing is that we could tag (or categorize) manager plugins within some built-in tags so has to group those built-in plugins.

Sorry I’m getting into this conversation late, but I was thinking that if we allow hierarchical relationships between Templates (which, if following the Ling-ol-ogy discussion includes chunks, snippets, and plugins), that we could use this as a sort of categorization mechanism, in the same way thay grouping documents under specific folders is. Just a thought. You would then see groups of ’Templates’ under ’Manager’ and then maybe ’Authentication’ and then maybe another group for ’Custom Forms’ or ’Blogging’ -- these taxonomies of various types of templates (templates, chunks, snippets, and/or plugins) could be used in any number of ways now that I think about more.

We could also have different manager pages that show different views of the same data. So one might be a heirarchical taxonomy, and one might be a tag-based approach. Users choose what works best for them!

On the subject of manager templates, I’d like to propose that we move all manager related themes, scriptaculous, media and whatnot to the assets directory. As we continue unifying and upgrading the system, the upgrade process will become much simpler if we do it that way I think.

Core system functionality would remain in the manager folder... anything that is presented to a user (manager, front-end, or otherwise) could go in the assets directory.