Hello, on 08/03/2006 02:49 PM Robert Cummings said the following: >>>> The point of the post is that there is no framework in particular to >>>> recommend. I use my own packages for my needs. They suit me well. It >>>> does not mean they will suit everybody. >>> How would you know that there is no framework to recommend if you neve >>> ruse anyone's code but your own. How could you have possibly given any >>> framework sufficient attention to have any idea of its pros and cons? >> I know many frameworks that exist, I have seen their code and their >> documentation, which is more than enough to reach the conclusion that >> using the frameworks that exist is not better that using my own >> solutions for my own purposes. > > Aaaah, so you are trully a genius to be able to at a glance of > documentation and source code fully deduce the usefulness of something. > I bow before you.
Be seriuos. Nobody needs to actually use any framework to see that it is not suitable for your needs, when you can just browse the source code and documentation. It would be insane to try all PHP frameworks that exist to reach that conclusion. >>> You can't have your cake and eat it too. You're either pro-choice with a >>> myriad of choices to choose from, or you're anti-choice and want only >>> one framework style. Get of the fence! >> Having standard API specifications does not prevent anybody to choose >> using solutions based on APIs that do not conform to any standard >> specifications. >> >> Furthermore I do not think that seem to understand the difference >> between an API specification and API implementation. J2EE is an API >> specification with many implementations from different vendors: Sun, >> IBM, Oracle, BEA, JBoss (this last one is Open Source). You can choose >> the implementation you want. >> >> There is plenty of choice to anybody. If you want to use a J2EE >> implementation to build your applications, otherwise you are free to use >> something else. > > > It's seems people have chosen... and they've chosen not to bother with > some kind of standard API. That's not to say one won't emerge, but it > doesn't seem like it's important at this time. Sure, but you are missing the point about the way Java specifications are built. They gather around interested players in the field of each kind of framework, so it is more consensual that just an unilateral proposal. If version 1.0 of an API is not good enough, they gather again, eventually joining more interested players and build a better specification. For instance, JDBC API specification had at least 3 major versions. There is no need to create a new completely backwards incompatible API specification. Everybody would loose with that. Building a completely new API specification would make sense if it was for very different purposes. >> Let me give a concrete example, I have developed some plug-ins for this >> forms class that provide auto-complete support to text inputs and linked >> select inputs. They use AJAX to retrieve auto-complete text options and >> switch the linked select options from a database on the server. >> >> http://www.phpclasses.org/formsgeneration >> >> It is not viable for me to support all database API that exist for PHP. >> Actually it is already a big deal that that I could find time to support >> MySQL (directly) or a bunch of other databases using Metabase or >> PEAR::MDB2 API. >> >> The developers that use other database API cannot benefit from these >> auto-complete and linked select plug-ins, unless they develop variants >> of the plugins that support the database API that they prefer, but then >> they would be on their own as I would not be able to provide support to >> them. > > There's this thing called an adapter pattern. Great for retrofitting > other people's code without actually modifying it. That is what Metabase and PEAR::MDB2 do, database adapting, same API and same behavior for all supported databases. Furthermore, the plug-in sub-classes that support different databases, only override a few base class methods . It would not be hard to adapt them for more API. I just do not have the time nor the interest to build variants for the bazillions of other database abstraction layers. Some do not even support the necessary abstraction features. For instance, AFAIK other database abstraction layers besides Metabase and PEAR::MDB2 do not support pattern escaping. This is necessary to escape wildcards characters that should be taken literally in patterns. It is needed to implement the auto-complete feature using SQL conditions of type field LIKE 'typed-text%'. If typed-text contains % or _, it must be escaped. Some databases like MS SQL need to escape other characters too. >> Everybody looses opportunities with this. If there was a standard API >> database specification for PHP like PDBC similar to JDBC, there would be >> no such problem. > > There are two ways for standards to come about. They can be hand picked > or they can emerge. Hand picked requires the "community organization" of > which you speak. Emergent standards requires the popular vote. I'm in > the latter camp, let the developers speak to the merits of any given > standard. And if they don't speak, it's probably not important. Right. The problem is that in the PHP world there are too many incompatible APIs for the same purposes in use by many people. This does not help people like the original poster that wanted specific recommendations. He will have too loose a lot of time and patience, probably to reach the conclusion that he will have to write his own framework. -- Regards, Manuel Lemos Metastorage - Data object relational mapping layer generator http://www.metastorage.net/ PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
