Re: Play nice! Re: Savant/Flexy/Foo template engines

Paul M Jones wrote:

I have started an attempt on the Jausions interface. So far as I can tell, it is free of Savant-isms like plugins and filters, and free of Flexy-isms as well.

    http://wiki.ciaweb.net/yawiki/index.php?area=Savant&page=TemplateSource

I have added what I think are minor modifications to the Jausions interface, to wit:

* Data assigned to the template is split into two properties, one for variables ($_vars) and one for references ($_refs). This is because they must be extracted differently: extract() only honors references back to the object property, not all the way back to the business logic. To the developer, it should "look like" there is only one storage space for both vars and refs. More on this later, when we see the setData, setDataByRef, clearData, and toString methods.

It took me a while to realize the best implementation of these, they are 'data' of different types. (the direct assignment of which should really be done by outputData or outputWithData.) - The docs in flexy explicitly explain why this method of operation is bad in principle, however, it is something that is provided if you dont agree with those principles.... The assignment code should reside in a datamanager (see the loading code in the example)

* There is a property for the MIME type, $_mime. Not sure if it's really needed, it gets set in openTemplate().

nope - cant see any justifaction for this..

* There is a property for the output generated by toString(), $_output, so that it may be stored properly within toString() without possibly overwriting a reference. Better reference-checking may obviate this.

the toString/output is warped? - why use output buffering at all for output() = in terms of calling it via toString, toString, should really be a output buffered wrapper around output()...

* There is a property for a PEAR_ErrorStack object, $err, so that errors can be reported and checked on the Template object itself. Error reporting in this first attempt is of necessity almost nonexistent, although I note where errors should be generated.

CODE NOTES: * The openTemplate() method seems the logical place to extend pre-filter, compile, and post-filter operations (Flexy), as well as multiple path locations (Savant).

copy and past the code from my example - it's all done (although needs alot of tidying up..) As long as the method sets

$this->_tpl (the source reference) to an include()-able stream or file, extended methods should be able to handle any kind of source, whether object, stream, text, or file.

the files array in the example I showed allows you to store a variety of file information, which may be usefull for different backends..

* The setData() method accepts three types of variable setting (are there any other kinds than these?): # assign-by-object, where the object properties are assigned to the template # assign-by-array, where the key-value pairs are assigned to the template # assign-by-name, where a single value is assigned by name to the template * setDataByRef() only assigns by name, not sure it makes sense to support the by-object and by-array types of assignment, but I could be wrong

As said before, the code body of this assign type API should be external

* clearData() extends the Jausions interface somewhat by allowing you to clear all values, one value by name, or a series of values listed in an array. Note that it clears both refs and vars; we want the interface to "look like" one storage unit to developers. * toString() extracts vars and refs into the local namespace differently. This bears some explanation. Let's say there is only one property ($_data) that would store all assigned data, whether by value or by reference. If we then extract($this->_data), the references extracted only go back to $_data, not back to the script that set the reference in the first place; thus, if the assigned reference changes in the calling script after it is assigned, it will not be honored within the template. As such, we must have different extraction methods for vars and refs; thus, the two separate properties, and the extra code to make it "look like" (to the developer) that there is a single storage location within the template.

Flexy was specificly designed to avoid this nightmare, (eg. the overhead of extract..) - while it is necessary for the Assign API / Savant current operation, Savant templates could be more effecient having the option to use <? echo $t->somevar; ?> rather than the extract / global vars..

* An extended toString() seems the logical place for output filters to be applied.

I'm still not convinced that output filters are anything more that preg_replaces on the output to toString.. -

* toFile() is copied directly from the Jausions code, not sure it fits well here.

I think it's pretty clear that that is a pretty redundant bit of code.

I can see very easily how Savant and Flexy would both extend from this minimalist base class and still maintain their "native" APIs in the extended versions. E.g., in Savant (this is not everything) --

Trying to provide a minimalistic base class is not really the goal, the aim is to provide a core that can provide all the features of all the engines, while keeping it to a minimum... by starting with privates everywhere, it makes it difficult to deliver this pattern $compiler = Template_Compiler::factory($this); // in the compiler.. function factory(&$template) { .... $template->files['compiled_template'] = $somefile; if (!$needs_Compiling) { return true; } // return the fat compiler $class = 'Template_Compiler_'. $template->options['compiler']; return new $class($template); } -- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com