Re: My ideas on a modular template Design

Alan Knowles wrote:

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..) Yea i guess this is a problem but it might be a possiblity to have these as seperate pear packages.

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() Yea thats what i as thinking

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... right quite easy

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?? Well i guess it could be both, someone might to run an html -> pdf filter here or l33t text or something

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.

Right im guessing you would pretty much have to write a compiler to do this, but its not so much that it does support IT, thats a lot of work for few users but that it could

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.. Yea, of course same as above

,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....... Well I guess after this email i'll have to do a review of Flexy it really looks like you've got a sound architexture that will work can easily provide any type of template someone wants. Of course it might be good to look at how say the Savant emulation could be a seperate package and have a seperate maintainer so that things scale a little better people wise.

I guess this is a pretty standard PEAR problem and its not technical, its how do we make it easier for people to add the extensions to related packages without making them push everything through the original maintainer. -josh

Regards Alan