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

From: Date: Thu, 10 Jun 2004 23:29:36 +0000
Subject: Re: Play nice! Re: Savant/Flexy/Foo template engines
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-30449@lists.php.net to get a copy of this message
Paul M Jones wrote:
On Jun 10, 2004, at 3:50 PM, Joshua Eichorn wrote:
I've been crazy busy at work for the last couple days so i haven't had a time to review the code but i would point out that an interface and extension isn't the only solution.
Fair enough; when you get a chance, take a look at both sets -- they seem to follow distinctly different paths, even though we're using the same reference document (the Jausions interface model). What would other solutions be, besides interface and extension? Maybe I'm too much inside the box, I thought those were two principal ideas in OOP-like code. There is more to good design then Simple OOP.
The reset is generally called design patterns read(http://phppatterns.com/index.php/article/archive/1/) for examples in php. In fact PEAR is full of cases where a design pattern was used instead of direct inheiritance, the DB ones being a good example. In the template case using runtime agregation techniques might be a much better solution then direct inheiritance that way what you needed can be decided on use instead of picking the class at th eright level to get what you want. Inheiritance is powerful but inflexible, you'll find that much of Alans code is based on the concept of short inheiritance trees while using other methods to gain even greater flexibility. The one problem with this is it can make your api harder to document, but if done correctly it should be easier to use. Hopefulyl i'll have time and energy to review the code tonight, but i wouldn't bet on that happening since i've spent all day in a reporting meeting, hacking out prototypes for the business users. -josh
What you need is a decent api and the ability to support lots of features without lots of overhead over or a really complicated api. Using other patterns then just an interface and inheiritance may be a better way to go.
It may be that they both have that; Alan's seems to incorporate more into the base class for compiler control and loading, while mine seems to incorporate more for assignment and return. I've got a "placeholder" for a compiler object that gets built and configured externally to the template object itself, while Alan has a "placeholder" for assignment objects.


« previous php.pear.dev (#30449) next »