Re: HTML_Template Interface recommendation

Hi, My point was that currently the template packages available on PEAR (and Smarty) are not easily interchangeable. If you want to use an instance of a template engine in an application, then you are bound to it. In my view, this is not acceptable, almost just as bad as mixing PHP and HTML codes. One solution could be to create a HTML_Template package that would provide an interface to all existing engines... A sort of abstraction layer, but this would be limitating since we would restrict the features to the ones of the interfacing package. The idea I was bringing forward was to ask the template engines to comply to a minimal common interface to allow interaction by third party packages. For development/testing the actual PHP5 "implements" keyword could be used... But that's detail. Keep in mind that each package has its strengths (and weaknesses) so we don't want to deal with that, we just want to add to it. Otherwise, yes recommending a set of method of names would be good, altough of limited interest because most names are obvious and should be checked when the package is submitted (ok, there's the problem of on-going development that could leave method names unchecked.) Again, we don't want to create a "be-all to all" interface definition but specific per-topic interfaces: For example sake (so no need to comment here ;-) * Server-type packages would need to provide:

         o init()
         o start()
         o pause()
         o restart()
         o listen()
         o stop()

* Content-generating packages would need to provide:

         o openTemplate()
         o useData()
         o generate()
         o close()
         o toFile()
         o toString()
         o output()

* Permission-type packages would need to provide:

         o isAllowed()
         o grant()
         o revoke()

The internal working of the package is of no relevance here since interfaces are really defined from the feature point-of-view. So to go back to the template engines, it shouldn't matter if they're using PHP, a meta language or whatever to handle placeholders as long as we consider them as content-generating packages. To help define the interface, one should really concentrate on the basic added value of the package and not its setup (setOptions and so on...) or advanced features which are not relevant. If a specific course of action is required, it should be embedded in the interface methods. For instance, if a template engine requires that you first check the cache manually, then this should be done automatically inside the interface method. I view this a bit like a "dumb" interface: "Me (the application): - Need content now. - Got template? Checked (someone gave it to me) - Got template engine? Checked (someone gave it to me) - Got data? Checked (collected) - Ask template engine to put data in tempalte and return result... Template engine: - Here you go (FYI: I got it from the cache) Me: - Thank you (FYI: I don't care)" Now, the application really doesn't care if the template engine returns an XML, HTML or PNG document... All I knew was how to speak to the template engine through the interface... The setup and tuning of the engine should left to the user. The packages could also be completely unrelated. For the "permission-type" packages, we could have a mix of file, authentication and database. So the "put-it-in-the-more-generic-package" approach doesn't really work. Does that make sense to you? If yes, then I think PEAR needs to approve some "standard" interface for certain types of packages.... My primary target was template engines (I think you guessed that ;-) -Philippe