Re: renderers and refactoring

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