Re: My ideas on a modular template Design

Joshua Eichorn wrote:

Overall Template Design API Wrapper (for BC in seperate packages)

To some degree this may be feasible, however, I've looked at this a little, and you could end up with 40-50 useless wrapper methods. - It's probably worth considering very thin HTML_Template_SmartyAPI extends HTML_Template_{yet to be picked} and map all of the methods to a standard common set.. (I assume I understand what you where after there..)

Standard API (would be best to include a smarty/savant api, and a registration pull api)

yeah - standard API - but with as little actually implented in core.. - if I dont use assign api - I dont want the extra crap in the base class, it can be loaded on the fly = see Flexy:assign()

Template Filter -> (run compilers as triggered actions here)

Thats on flexy already - It now has 3 backends : Regex (which is similar to Xipes), Standard - the HTML Tree/ Tokenizer backend, and Raw = the savant backend

Template Plugins -> (runtime components, would be great if the same overall design could be used for runtime regex replace)

Savant's (and smarty's) plugins are really just functions available to the engine.. - not sure what you are after here..

Output Buffering (optional)

Done

Pure php Template

Done

Read from Buffer and return (optional)

I need to add this - it should be a few lines of code though...

Output Filters    \
        |- should be seperate packages but work easily with templates

or do you parse the output of the template back into the engine using a different backend??

Output Cache    /

Template Compiler -> An action ran by a template filter for automatic on change operation. All compilers should all be designed to work standalone where compiling is an external step/

Done

Filter and Output Buffering, and plugins are optional That way you can have a minimal overhead setup were your template outputs content directly instead of returning from a method. It would be great if a design like this could support templates like:

IT, = from what I remember is a problematic due to it's weird blockAssign stuff. Savant, = pretty much done

Smarty

From my recollection one of the difficult bits here is licencing.. - you can include Smarty en-mass in a engine - however you cant take parts and put it in another package without the same licence..

,Xipe,

The problem I've found merging with Xipe is that I dont understand the Base class which tries to manage multiple instances of the engine. otherwise the backends should be pretty simple to add in.

or WACT

AFAIK this should work as a compiler for Flexy - the logic is pretty similar - however it does add getChild(), which is similar to getElements() in Flexy.. - but is complex to wrap generically. - -------------- The vision is good, however, in reality getting anyone to actually do anything is problematic.. - Savant got lucky that I'm in the mood for adding the stuff today.. - but I suspect that this occurence is generally the exception, rather than the rule.. Contributors who say they rather have a new package than add code to an existing one, should really have at least tried hacking their features into some existing code.. - come up with the problems - shown some code, perhaps, and got brushed off by the maintainer, before they can justify presenting a new solution....... Regards Alan