On Thu, 2006-08-03 at 13:32 -0300, Manuel Lemos wrote: > Hello, > > on 08/03/2006 02:01 AM Robert Cummings said the following: > >>>> Anyway, you may want to read this more in depth reflection of the state > >>>> of the PHP framework world and recommendations on how to pick what suits > >>>> best for you: > >>>> > >>>> http://www.phpclasses.org/blog/post/52-Recommended-PHP-frameworks.html > >>> I've read it before... it was crud. You provide no recommendation for > >>> any framework but instead try to pimp phpclasses. From what I gathered > >>> you haven't even actually tried anywhere in the vicinity of 10% of the > >>> frameworks in existence and yet you feel obliged to write a commenatary > >>> called "Recommended PHP Frameworks" in which you don't even recommend a > >>> framework. Additionally somehow while pimping phpclasses you also feel > >>> it necessary to indicate how you don't use any code other than what you > >>> write yourself. Egads, if you won't use the code on your site why the > >>> hell should anyone else? > >> The answer to that question is in the post. I only use my own (PHP) > >> packages because I can. Not everybody can afford writing package for > >> their own needs from scratch. > >> > >> Why would I lie when that post expresses exactly how I feel? > >> > >> 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. > > I do not need to jump off a building to realize that it would not be a > better idea than using the stairs or the elevator. That depends, if there was one of those great big inflated stunt things at the bottom, I'd certainly give it a go. But then I generally look before I leap. > It is a bit exaggerated metaphor because I really do not think that > using somebody else's PHP code is like suicide. I just think that using > my own code that is proven and has matured during many years, is much > better for my own purposes than using something existing frameworks. You are fully entitle to that stance, I commend it, but then to move forward and write a commentary about recommended PHP frameworks in which you make no recommendation... well that just doesn't sit right. The utility of many things in life is rarely realized until it has been used in practice. many people have said they don't like Linux, they've read the books, they've looked under the hood. But unless they give it a good go, I just can't take their opinion seriously. > >> The PHPClasses site content is made of packages contributed by > >> developers that wrote their own packages. Those other packages often > >> serve the same purposes as some of my packages. > >> > >> I am pro-choice. That is the spirit of the PHPClasses site. Everybody > >> can publish their packages. Let the users be the judges of which are the > >> best for whatever purposes. That is pure fair play. Is that a bad thing? > >> I don't think so. > >> > >> I also would like to emphasize what I said above regarding the total > >> lack of organization and cooperation of the PHP community. > > > > 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. > >> If there were standard specifications for packages and frameworks like > >> there is in the Java world, maybe you would not have this discussion. > >> There could be a consense to use the same standard API with eventual > >> multiple implementations from different developers or vendors. > >> > >> Imagine if there would be only one PDBC (JDBC for PHP). Instead of that > >> we have a never ending choice of PHP database abstraction layers that > >> does not help newcoming developers that are lost and don't know what to use. > > > > You presume that any chosen standard methodology or whatever you want to > > I am not talking of implementation methodologies, I am talking about API > specifications. The same API specification can be implement with > different methodologies. As long as they pass API compliance tests, that > is all right. Allow me to rephrase. You presume that any API specification would be optimal. Because if it wasn't optimal, no matter how organized you think the community might be, a new API WILL emerge. > > call it would be correct. Because if it wasn't correct, no matter how > > organized you think a community might be, something different WILL > > emerge. Right now there may be 100 frameworks, probably still growing, > > but not all will be accepted into mainstream use, and that ultimately > > will determine which one's have staying power or at the very least -- > > which ones have reach. The fact that there are so many is a testament to > > how easy it is to manipulate the power placed in the hands of the PHP > > developer. It is not indicative of disorganization within the community. > > You totally misunderstand me. When I talk about lack of organization in > the PHP community, I am not saying that the people that implement > frameworks are disorganized. What I am saying is that there is no > organized effort to site together and produce standard API > specifications for the frameworks, like there is the Java community. No I understood you perfectly fine. I understood that you were speaking about the PHP community at large and not individual communities around any given framework or API. > >> This is admitidly a criticism to the lack of organization of the whole > >> PHP community including myself. We are all guilty for this mess and I am > >> afraid there is not much hope to fix it. > > > > You mean we should all be happy that so much choice is available! > > I am pro-choice, so having choice is a good thing. > > That is not my point. My point is that for instance, when you want to > develop PHP database applications, there is no consense on which API > would be the best to use. > > The reason why it is a bad thing is that that when people develop PHP > components that need to access to a database, they will hardly support > more than one database API. Whoever uses other database API may not > benefit from those components. > > 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. > 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. 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
