On Fri, 2006-08-04 at 17:15 -0300, Manuel Lemos wrote: > 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.
And there's the rub... your article was not about what YOU needed it was what YOU considered to be the best framework for everyone based on briefly browsing the code. Your article, if it had any real merit, would have reported on the actual trial of a substantial number of frameworks so that you could provide a valuable analysis instead of superficial opinion. Remember a recommendation, is not about YOU, it's about those reading the article. I can agree with your previous statement until you start recommending it in general. > >>> 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. I wasn't missing the point. I am quite aware of how the process works behind closed doors with a select few high profile companies and committees. I'm also quite aware of the pros of standardization, but I don't necessarily feel that hand picking the standard is necessarily better than an emergent standard. Either way, as I keep saying, if there was a strong enough desire for such standardization then I'm sure people would be forming such groups. maybe with the launch of Zend Framework there will be a rallying point, but then again, maybe it will just be yet another framework. > >> 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. If there was enough need for Metabase to support other layers then I'm sure the community would be submitting the code for you. But then again, you probably wouldn't accept outside code into your own codebase since that would violate your internal dislike for external code *lol*. Touché! > >> 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. >From your earlier statement, he could supposedly choose a framework just from browsing the source code. At any rate, he probably wasted time reading your article that purported to recommend a framework when in fact it had nothing of substantial value to say about any particular framework. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
