flexy enhancement

"Alan Knowles" <alan@akbkhome.com> wrote in message news:3F0CC2BB.2030205@akbkhome.com... > Sam Liddicott wrote: > > I'm requesting comment on a new templating enhancement I thought of and am > > working on, which I wish to contribute to XIPE. > > Interesting idea.. - you know that you could add this in about 10 lines > of code to Flexy? - just modify the toHtml part of > HTML_Template_Flexy_Token_Tag to check for the method attribute.. and > store the methods in a static global... then output later.. do you mean toString ? So where I would have passed the internal parsed tag to a class generator and output a call to that class method in the outer context I now pass what would have been returned as $ret to my class generator (now global) and as $ret I return some php code to make the call. It may take a bit of consultation with you to get this to work nicely. My class generator did track php/html state so as to only output <?php tags where neccessary and not where more code of the same type was being appended, which I suppose was more important when writing out a neat class defiintion as opposed to expanding out php. in token.php you say: // this whole children thing needs rethinking // - I think the body of the page should be wrapped: .. // ?php if (!$this->bodyOnly) { .. <HTML> .... <BODY....> ?php } ? This was part of the reason behind parsing into a class, to make it easy to get rid of unwanted bits through subclassing and method overriding where needed, without littering the page with conditionals in case they were needed. What if the generated class was a subclass of the controller class? What if you also had a chance to subclass that and call outputObject on an instance of that? What if you then didn't need to beause I'm suggesting parsing into a class by default instead of to regular page with embedded php, users need never know if they don't want to... Sam