Re: Re: renderers and refactoring

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