Re: renderers and refactoring

I'm cc'ing into pear-dev as I think there may be other users who are reading that, and may like to comment (or add noise ;) Sam Liddicott wrote:

One thing I noticed when adding the class definition output code was that I had to make the same sort of changes in many classes. When I add the variable definitions I'll be doing the same again, so I realise we need to do some refactoring here so we can get much of this behaviour in one place. I suppose toString has become too complicated. Perhaps this is what you meant by adding a renderer object? 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. 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)

The rough pattern needed in toString is: 1) redirect output to new class/method if required writing out stub-caller in old class/method if required 2) spot default variables in attributes and write these to class definition 3) output open-tag definition and modified attributes to current class/method 4) recurse to render inner tags 5) output close-tag definition and attributes to current class/method (4) is usually a seperate method. (1)(2)(3)(5) is usually in the toString method which is the method name used for recursing (1)(2) really need to be inherited methods and should be the same for all classes (2) and (3) touch depending on how declared attributes are processed, should (2): a) replace the attribute value with the equivalent php code? I don't like this b) Or should that happen at parse time?(it can't easily)

c) Or should (3) render the attribute differently? 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.)

d) Maybe (3) should work on temp. copy of attributes which (2) possibly modifed from the original set (I prefer this) Maybe (1)(2) should be called prepareOutput ?

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.. Regards Alan

I'll rework along these lines and see where I get. Sam

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