Re: Re: renderers and refactoring

Joshua Eichorn wrote:

While my earlier suggestion got ignored i would like to bring it up again. If your breaking bc on for the Flexy template wouldn't it make sense to move to an api that could support all the different template engines in PEAR.

Actually, there is no bc break - it's mostly for internal extendability.. (although I've done it far to many times in the past) :)

I know this is more work now, but if we don't start somewhere were never going to get convergence since everyone will break bc at different times and use the fact that others won't change to never move to a standard api.

What I guess you are getting at is a API for assigning variables to element in a template.. Flexy and Xipe both use either 'your class vars', or 'globals' for filling in variables on templates. Smarty/IT/.... etc. use assignVar() / setBlock() etc. to store in a location the data which is then overlayed into the template. While I know a number of people like the assignVar idea, and hence a number of engines support it, I personally ran into a number of major problems with the design, (primarily documentation of available variables on the template., along with the rather long winded code) the core Flexy engine, which is based of Xipes code, really will only do a few things when finished: b) Instantate with options c) set which template or rawtext is to be compiled. d) check if compiling is required (and fire up the compiler if needed) e) overlay an object onto the variables in the template (or really just make them available) f) have some mechanism to assign/overlay dynamic form elements (or any HTML structure) onto the template.. while it is perfectly possible to make a class that just does assignVar.. etc. it is not very valuable other than matching an existing API... - obviously as a wrapper for old code... if you where to port from one engine to another.. (it would however add a huge runtime overhead) That said, the base Class, could be used as a generic engine for compiling templates... In which case Xipes compiling code could be loadable option, however, Wolfram added a Caching Wrapper to Xipe, that I never really understood it enough to work out how it could be implemented around this. While it would be nice to have a single API, due to the fundimental design logic, you would probably end up with a highly confusing and unnecessary API to try and encapsulate all of the engines. Hope that helps to explain it a bit.. Regards Alan

If each template moves to a new unified api when it breaks bc then we can slowly get to a single api and out of the Mess that is 5 seperate api's for templates. Soon were going to need a PEAR::Template abstraction layer and then people who want portability will have to live with another layer of overhead jsut like with databases. -joshua eichorn Alan Knowles wrote:

Ok the base work of this is now done and in CVS I've not hooked it into the live code yet, but most of the basic logic and layout is there: New: HTML_Template_Flexy_Compiler : Factory and Interface for compilers HTML_Template_Flexy_Compiler_Standard : the existing general Token toString methods + the token build code. HTML_Template_Flexy_Compiler_Standard_Tag : The standard namespace html tag interpreter HTML_Template_Flexy_Compiler_Standard_???? : in theory support for tags <????:mytag ....> HTML_Template_Flexy_Compiler_Class should probably extend Standard HTML_Template_Flexy_Compiler_Simple should probably just extend Compiler. it might work by just replacing the ->_parse() call in flexy with $compiler = new HTML_Template_Flexy_Compiler($this->options); $compiler->compile(); although I still need to modify the code to compile text as well as files. Regards Alan Sam Liddicott wrote:

Alan Knowles wrote:

This is a copy of the mail I sent to darell brogdon, (he's looking at doing a simpleified compiler based around the Flexy base class (credits which mostly go to Wolframs Xipe stuff :) The plan is to refactor Flexy - hopefull next week, to look more like Flexy: - base - checks filestamps/writes files/outputs objects etc. Flexy_Compiler - Current Compiling code & Factory class implement other renderers. Flexy_Tokens - as current, but without toString (this will move to Compiler) If you break the compiling code out of the current class into another class: eg. Flexy_Lite = HTML_Template_Flexy HTML_Template_Flexy_Compiler <-- Compiler Inteface and factory. HTML_Template_Flexy_Compiler_Lite <-- your regex code.

Heh, I was looking at making my old code a lite version. It's strpos based, not regex but very complete; Darell, can we compare notes?

Flexy: HTML_Template_Flexy_Compiler_Full <-- the current compiler engine (a mix of whats in Tokens and Flexy compiler() calls. HTML_Template_Flexy_Compiler_Class <-- sams Code to generate classes - as an extension of Compiler_Full ** this may even offer the posibility for someone to look again at the QuickForm parser/generator issues as another Compiler. HTML_Template_Flexy_Token* <-- previous stuff.. (without the toString stuff.) As you can see, the key aim is to make the token classes more a datastore, with some simple abilities around assignment, and child traversal. and maybe the variable context (although I've not heavily considered this)

Yes, this does make sense.

the <tag id="xxx" flexy:dynamic> which behaves similarly to form elements should assist in this, either that or <tag value="{somevalue}"> which has one downside (mozilla editor doesnt allow it in bgcolor="" tags.)

yeah. The flexy:dynamic bit seems very unspecific, and as you say value="{somevalue}" for attributes is not liked by mozilla and probably not by many designers who want to see the design. My angle is to allow the designer to mark-up the design and still get a fully specified overrideable class, which is why I like: <body flexy:var="bgcolor" bgcolor="white"> to cause a class var definition on $bgcolor="white" and to replace bgcolor="white" with bgcolor="$this->bgcolor" In the architecture you showed is there scope for autotag specifications like: array("body"=>array("var"=>"bgcolor")) so the parse would pretend these extra attributes had been included as flexy: attributes in the template?

As far as I can see, the outputHTML(), outputPHP() calls you have on the current generator should be implemented in the base compiler, and overriden in the class targeted compiler... - but I'm still hoping next week to get a grip on the issues..

Feel free to dish out responsibility on this to fulfil your design, I have time right now. Sam

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com