On Sat, 2006-08-05 at 15:36 -0300, Manuel Lemos wrote: > Hello, > > on 08/04/2006 05:47 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. > > My article is mine. It was not written for you but rather to the > PHPClasses site users in first place. Therefore it includes whatever I > think it is best for me to mention. If you do not agree and think it > should be something else, go and write your own article in your own blog > rather than bossing me to do something different, as if I owe you anything. I've been registered with the PHPClasses site for a couple of years at least now. I get the regular emails and I've never taken issue in the past. But this particular one was waaaaay out there. > >>>>> 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. > > People cannot have desire for something that they do not know or do not > have a vision about its benefits. Sun had a good vision about defining > API specification standards. It attracted many companies, including > competitors that made Java adoption grow enourmously. > > Zend does not seem to have such vision. Zend Framework is an > implementation, not a specification. Without a well defined > specification, nobody can provide alternative implementations even if > they wanted. > > I am afraid that Zend Framework is fated to be just yet another PHP > framework struggling against other frameworks for a small piece of > adoption share. > > I am sure their project would have much better adoption if they focused > on building a specification resulting from a consense among other strong > players in the PHP development scene, like Sun did with Java framework > API specifications, allowing alternative implementations of the same API. > > > > >>> 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é! > > Your obcession to diss everything I say is preventing you to see the > things the way they are. You're deluding yourself as to your importance. I really don't have an obsession with you. Having had very little interaction with you in the past leaves me with a generally agnostic opinion. Furthermore I'm npt having any trouble whatsoever seeing the way things are. Perhaps you are the one having clarity trouble. > I do not have a problem using other people's code, my problem is relying > on packages that need to be evolved to address my needs but I do not > control of their development. I control Metabase development, therefore > there is no problem in accepting other peoples contributions of patches > or even complete drivers. > > As a matter of fact Metabase always had many, many contributions, unlike > you imagined, as you may see in the contributors roll with the > respective credit for the contributed work here: > > http://www.meta-language.net/metabase.html#3.1.4 That's nice. So what are you complaining about? > >>>> 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. > > If you ever paid attention to what I wrote, my recommendation to the > original poster to read the article was about giving recommendations on > how to pick frameworks that suit his needs, rather than recommending any > specific frameworks. I am pasting the relevant quote of my original > reply so you can get a grip for once. > > > > 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 Oh I paid perfect attention. If you read what I originally wrote you'll see that I was commenting on the article itself that you suggested since I and many others find great fault with it. For your benefit I've pasted below my original comment: -------- 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?" -------- At any rate, this thread grows long and booooooooooooooring. I'm signing off from it permanently (unless there some other interesting post not including your self-indulgent feelings of persecution). 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
