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

Paul M Jones wrote:

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

Aha! I think this is where my philosophical disconnect is; perhaps I have misunderstood the Jausions plan and the unification goal.

[been down most of the day due to a PC malfunction, crashed in the middle of composing a previous reply... grrrr] I have to agree with Paul on that. There's a lot of talk around these template engines... That's good. But the focus gets lost a bit. When I designed the API to template engine I thought: What do I need to be able to write an application that generates output and not care about which template engine is used. I would need: 1. (What I call) a template engine, 2. A template, 3. Eventually gather some data to use with the template, 4. Have the template engine render the template with the data. Note: that the output could be anything from text-based, or PDF, images and so on... hence the need for getMimeType(). What I really tried to look into is the "how to use it", and not "how to implement it". Although I tried to implement the interface for several template engines, I said: "My implementation may not be the best" ;-) The API is meant to be accepted by a lot of template engines if possible, ideallistically all of them... ok, that's a bit pretentious, but wouldn't be nice? Should PEAR mandate a new template base class? Not IMHO. If I understood well, the PEAR philosophy is only to prevent near identical *implementations* of packages, not packages themselves. Otherwise, there wouldn't be DB, MDB and so forth... In this view, a template base package may not satisfy different approach to templating. Someone made a comment about the assignment of data by value and by reference saying that the would-be template base class should store them in different private members because "extract()" doesn't work well with references. This implies that the template engine would actually use extract(), which may not be the case. Should current template engines implement the API: Yes, it would be nice. That's the whole idea. That doesn't limit to PEAR template engines, and HTML template engines. The API itself is still open for discussion, of course, but the focus should be kept on its use from the application point of view and not implementation. Isn't it proper OOP design we're talking about here? When I tested the API idea by implementing the interface for various template engines, it was obvious that they worked very differently, for example some required me to create a second class to encapsulate the block building process (actually that was not a bad thing after all.) So the openTemplate() method doesn't care. Although some template engines provide caching, I decided to not include that in the API. I did play a bit to see how a isCached() method would work but it became quite evident that it shouldn't be in the API. For starters, some engines, don't have a built-in caching mechanism so that would have require to somewhat "mandate" one, such as PEAR::Cache_Lite. For an API of this sort, I felt it was not reasonable. Also, caching usually requires an ID for different output for the same template... that was too much to accomodate a simple API. So, as far as template engines under PEAR are concerned, I would first suggest a clean up to keep PEAR uncluttered by near-identical implementations. First to regroup should be Xipe, IT and PHPLIB. I also saw some discussion about filters. I won't extend on that but filters shouldn't be part of the API. It doesn't mean that they can't be used, just that as far as the API is concerned, they should be applied transparently. What could be done is instead of passing a simple file name to the openTemplate(), an object could be passed that would take care of applying whatever filters are needed. This implies then that if normally an openTemplate() method expects a file name, then the method has to be smarter if an object is passed instead. Then that template engine should define its own API to work with such template object. I don't think the PEAR community should or could have any say in that (besides ensuring high quality packages) because template and template engines are tightly related and work hand-in-hand in a specific implementation strategy... For the MIME type, idealistically it should be handled by the template itself, since template engines could generate different formats of output (even for text-based formats: text/plain, text/html, application/vnd.wml...) However, in the definition of the API we really only interact with the template engine. Indeed, the "template" passed could be a simple file name, therefore we would be hardpressed to get the MIME type out of it. To work around that, the end user could extend the template engine class to return the proper MIME type based on their own criteria. Remember that the API is to be used by an application to which is fed the template engine and the template. At this point, though, I would like to have some common agreement over the definition of the API itself, so I could get other template engines maintainers involved in the process... While most people are not under PHP5, it would be nice if the PEAR site could somehow accomodate the interface definitions themselves, for now for reference and in the future for actual "implements" declaration. I think this post is long enough for now ;-p BTW: could we restart a thread at a lower level. This one is kinda deep with multiple somewhat unrelated topics going on at the same time. -Philippe