Re: [PHP] Re: PHP Frameworks - Opinion
On Tue, 2006-08-01 at 18:17 -0400, tedd wrote: > At 10:46 PM +0100 8/1/06, Colin Guthrie wrote: > >I'm surprised no-one has mentioned the Zend Framework yet. > > > >I'm looking to do a bit of a rewrite of a large PHP application in > >the near future and would like to think Zend would be a good horse > >to back, but the fact no-one here has mentioned it yet makes me > >doubt this tactic! > > > >Anyone got opinions (good or bad) on Zend that would be helpful for > >me (and others)? > > > >Col. > > Col: > > I own Zend Professional, but don't use it (not good or bad). > > I find that Macintosh GoLive CS (although not designed as a php > development platform) meets most of my needs, which are a mixture of > html, css, php, mysql, and javascript editing. Additionally, GoLive > works as a my-side/server-side file organizational and > synchronization system. An IDE is not a framework. it's an IDE :) Cheers, Rob. -- .-. | Worlds of Carnage - http://www.wocmud.org | :-: | Come visit a world of myth and legend where | | fantastical creatures come to life and the | | stuff of nightmares grasp for your soul.| `-' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
Colin Guthrie wrote: Satyam wrote: There is no 'common consensus' but I am sure you'll be getting lots and lots, I would even say LOTS, of sugestions. I'm surprised no-one has mentioned the Zend Framework yet. I'm looking to do a bit of a rewrite of a large PHP application in the near future and would like to think Zend would be a good horse to back, but the fact no-one here has mentioned it yet makes me doubt this tactic! Anyone got opinions (good or bad) on Zend that would be helpful for me (and others)? Col. I have played a bit with the ZF and liked it (0.1.3). I know PHPDeveloper.org is based off of it and I think the Zend developer zone as well. It has a number of prominent developers writing code for it and by the looks of the mailing list seems to have a large community. But it is still early in it's development so expect changes to it. My prediction for the ZF - it will not fit all needs - but will be used on many of the "enterprise" sites and will be one of those things that are listed in the "nice to have" section of job postings. -- life is a game... so have fun. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
karthikeyan balasubramanian wrote: > Tony Marston wrote: >> "Gabe" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >>> What's the common consensus as to a solid PHP framework to use for >>> application development? There seems to be a number of them out >>> there, but I'm not sure which one's are the most robust, actively >>> developed, secure, etc etc. >>> >>> Thoughts? >> >> If you want a rapid application development framework for >> administrative web applications then take a look at >> http://www.radicore.org It has dynamic menus, a role based access >> control system, audit logging without database triggers, a data >> dictionary, internationalisation, and a workflow engine. >> > > Speaking about framework. Anybody is aware there is a very popular > framework in Java called Spring which has pretty cool features like > "Inversion of Control", "Dependency Injection" etc. Anyone interested > in porting Spring Framework to PHP? I'll have it ready for you next week, what kind of license do you want? > > Regards, > > Karthikeyan B > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
Jochem Maas wrote: Stut wrote: Jochem Maas wrote: I'll have it ready for you next week, what kind of license do you want? One license to kill to go please. 006.5 your lic is in the post. and while I'm at it can I port an obscure OS to the hardware of your choice during my lunch break? Been done: http://mail-index.netbsd.org/tech-ports/2002/07/05/.html -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
Jochem Maas wrote: I'll have it ready for you next week, what kind of license do you want? One license to kill to go please. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
Stut wrote: > Jochem Maas wrote: >> I'll have it ready for you next week, what kind of license do you want? >> > > One license to kill to go please. 006.5 your lic is in the post. and while I'm at it can I port an obscure OS to the hardware of your choice during my lunch break? > > -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
On Wed, 2006-08-02 at 15:51 +0300, karthikeyan balasubramanian wrote: > > Speaking about framework. Anybody is aware there is a very popular > framework in Java called Spring which has pretty cool features like > "Inversion of Control", "Dependency Injection" etc. Sounds similar to the service system implemented in InterJinn. I implemented a lookup system allowing retrieval of service objects by custom names. This allows the mapping to be overriden with userland re-definitions which may or may not extend the original class. In this way, a developer can replace components and services without the need to change the code that makes use of such objects. The only caveat is that the override must at least support the methods and properties for the service or component being overriden. I have used this in many projects to extend the core components in InterJinn to provide customers with tailored functionality for their own specific needs. A simple example was overriding the mail service to dupe outgoing emails and store in an archive. It was as simple as extending the JinnMail class, overriding the send() method, and overriding the service registration. And voila, all existing code across the project automatically inherited the functionality, and the distribution code didn't need to be touched. 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
Re: [PHP] Re: PHP Frameworks - Opinion
On Wed, 2006-08-02 at 10:50 -0400, Gabe wrote: > Gabe wrote: > > What's the common consensus as to a solid PHP framework to use for > > application development? There seems to be a number of them out there, > > but I'm not sure which one's are the most robust, actively developed, > > secure, etc etc. > > > > Thoughts? > > Sounds like it's just personal preference. But thanks for all the posts! > > Too bad there isn't a skeleton sort-of system that you essentially then > just plug in the modules that you want/need to "flesh" it out. Then > you'd have your own customized framework for each app that is developed > and keeps *all* of the modules relevant to that app. Nothing extra > would be included that isn't needed. > > Then as a developer all you're looking for is modules and not huge > frameworks that may include lots of functionality that you don't have > any interest in. It would certainly keep any attack surface smaller > when it comes to vulnerabilities. > > Is there anything out there like that? A good framework won't load all of the code out there. It will load the code on an as-needed basis. So that if you only use one piece, that's the only piece loaded (notwithstanding the loading mechanism being loaded also :) 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
Re: [PHP] Re: PHP Frameworks - Opinion
> Too bad there isn't a skeleton sort-of system that you essentially then > just plug in the modules that you want/need to "flesh" it out. Then > you'd have your own customized framework for each app that is developed > and keeps *all* of the modules relevant to that app. Nothing extra > would be included that isn't needed. > > Then as a developer all you're looking for is modules and not huge > frameworks that may include lots of functionality that you don't have > any interest in. It would certainly keep any attack surface smaller > when it comes to vulnerabilities. > > Is there anything out there like that? > You have just described KINKY/Chisimba... --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
On Wed, 2006-08-02 at 18:08 +0200, Jochem Maas wrote: > Robert Cummings wrote: > > On Wed, 2006-08-02 at 15:51 +0300, karthikeyan balasubramanian wrote: > >> Speaking about framework. Anybody is aware there is a very popular > >> framework in Java called Spring which has pretty cool features like > >> "Inversion of Control", "Dependency Injection" etc. > > > > Sounds similar to the service system implemented in InterJinn. I > > implemented a lookup system allowing retrieval of service objects by > > custom names. This allows the mapping to be overriden with userland > > re-definitions which may or may not extend the original class. In this > > way, a developer can replace components and services without the need to > > change the code that makes use of such objects. The only caveat is that > > the override must at least support the methods and properties for the > > service or component being overriden. > > I guess you'll be needing the strict method signature 'goodness'* to make > you code better and more robust heh ;-) > > (and yes I have been following *that* thread on internals) *lol* No, I don't believe in forcing the issue. For instance providing method support does not necessarily mean same signature. For instance a subclass may provide a default value in the parameters effectively changing the signature of the parent class yet still keeping compatibility. I think the "strict" thing being discussed on the internals is nice to have, but I prefer the ability to change the signature when you know what you are doing, or ultimately some kind of method overloading based on parameter types signatures :) I am in the "give PHP users the power they want" camp, and not in the "put a cage around OOP users" camp. :) 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
Re: [PHP] Re: PHP Frameworks - Opinion
Robert Cummings wrote: On Wed, 2006-08-02 at 10:50 -0400, Gabe wrote: Gabe wrote: What's the common consensus as to a solid PHP framework to use for application development? There seems to be a number of them out there, but I'm not sure which one's are the most robust, actively developed, secure, etc etc. Thoughts? Sounds like it's just personal preference. But thanks for all the posts! Too bad there isn't a skeleton sort-of system that you essentially then just plug in the modules that you want/need to "flesh" it out. Then you'd have your own customized framework for each app that is developed and keeps *all* of the modules relevant to that app. Nothing extra would be included that isn't needed. Then as a developer all you're looking for is modules and not huge frameworks that may include lots of functionality that you don't have any interest in. It would certainly keep any attack surface smaller when it comes to vulnerabilities. Is there anything out there like that? A good framework won't load all of the code out there. It will load the code on an as-needed basis. So that if you only use one piece, that's the only piece loaded (notwithstanding the loading mechanism being loaded also :) Cheers, Rob. True, but I was also talking more about the package of files to install that contains all of the code. For instance, if the Zend Framework contains 8 different modules and all of the php code files to support those 8, and I only need to use 3 of those modules for my specific app, then it would be cool to be able to not have to have all the additional code files that aren't used. I just like to keep things as small and tidy as possible. :) Of course, maybe frameworks do this and I'm just missing something... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
Robert Cummings wrote: > On Wed, 2006-08-02 at 18:08 +0200, Jochem Maas wrote: >> Robert Cummings wrote: >>> On Wed, 2006-08-02 at 15:51 +0300, karthikeyan balasubramanian wrote: Speaking about framework. Anybody is aware there is a very popular framework in Java called Spring which has pretty cool features like "Inversion of Control", "Dependency Injection" etc. >>> Sounds similar to the service system implemented in InterJinn. I >>> implemented a lookup system allowing retrieval of service objects by >>> custom names. This allows the mapping to be overriden with userland >>> re-definitions which may or may not extend the original class. In this >>> way, a developer can replace components and services without the need to >>> change the code that makes use of such objects. The only caveat is that >>> the override must at least support the methods and properties for the >>> service or component being overriden. >> I guess you'll be needing the strict method signature 'goodness'* to make >> you code better and more robust heh ;-) >> >> (and yes I have been following *that* thread on internals) > > *lol* No, I don't believe in forcing the issue. For instance providing > method support does not necessarily mean same signature. For instance a > subclass may provide a default value in the parameters effectively > changing the signature of the parent class yet still keeping > compatibility. I think the "strict" thing being discussed on the > internals is nice to have, but I prefer the ability to change the > signature when you know what you are doing, or ultimately some kind of > method overloading based on parameter types signatures :) I am in the > "give PHP users the power they want" camp, and not in the "put a cage > around OOP users" camp. :) I did gather that from you posts. I have mostly refrained from commenting myself because I have been flamed plenty in times past for daring to comment on the 'purism crusade' that has been unfolding since about 5.0.2 (I did comment on the problem of E_STRICT being misused for depreciated stuff, meaning that causing an E_STRICT on 'loose' subclass methods means your basically saying 'shit code, shit code' by implication) me I'm on the same band wagon, shove enforced strictness where the sun doesn't shine. (and while your at it give me 'late static binding', which A should have been in there from the beginning and B is a basic OO concept that is implemented in every other decent dynamically-typed OO language). don't get me started on iterators in ruby and how flexible it is in changing stuff (like method parameters - or like redefining a whole class at runtime). hmmm :-/ pity my ruby skills suck. :-P > > Cheers, > Rob. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
Robert Cummings wrote: > On Wed, 2006-08-02 at 15:51 +0300, karthikeyan balasubramanian wrote: >> Speaking about framework. Anybody is aware there is a very popular >> framework in Java called Spring which has pretty cool features like >> "Inversion of Control", "Dependency Injection" etc. > > Sounds similar to the service system implemented in InterJinn. I > implemented a lookup system allowing retrieval of service objects by > custom names. This allows the mapping to be overriden with userland > re-definitions which may or may not extend the original class. In this > way, a developer can replace components and services without the need to > change the code that makes use of such objects. The only caveat is that > the override must at least support the methods and properties for the > service or component being overriden. I guess you'll be needing the strict method signature 'goodness'* to make you code better and more robust heh ;-) (and yes I have been following *that* thread on internals) > I have used this in many projects > to extend the core components in InterJinn to provide customers with > tailored functionality for their own specific needs. A simple example > was overriding the mail service to dupe outgoing emails and store in an > archive. It was as simple as extending the JinnMail class, overriding > the send() method, and overriding the service registration. And voila, > all existing code across the project automatically inherited the > functionality, and the distribution code didn't need to be touched. > > Cheers, > Rob. * 'goodness' as in 'pile of shit' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
Paul Scott wrote: Too bad there isn't a skeleton sort-of system that you essentially then just plug in the modules that you want/need to "flesh" it out. Then you'd have your own customized framework for each app that is developed and keeps *all* of the modules relevant to that app. Nothing extra would be included that isn't needed. Then as a developer all you're looking for is modules and not huge frameworks that may include lots of functionality that you don't have any interest in. It would certainly keep any attack surface smaller when it comes to vulnerabilities. Is there anything out there like that? You have just described KINKY/Chisimba... --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm I see that there are a few different Universities in Africa supporting that framework. How active is the developer community? How long has KINKY/Chisimba been around? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
> I see that there are a few different Universities in Africa supporting > that framework. How active is the developer community? How long has > KINKY/Chisimba been around? > The AVOIR Project has been going for about 2 years now. KINKY and KEWL.NextGen were the first products of that project. Chisimba is the PHP5 version of KINKY geared more towards a Services Oriented Architecture and a generally excellent framework. Our developers list is very active (over 100 mails a day) and we have over 60 developes in 16 countries that are active on a daily basis. Those numbers are growing constantly as well. We are always looking for others though, and the elearning aspect should not scare off other uses. We have over 20 different applications built on this framework besides elearning. All code is OOP and the overall framework is very robust. --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP Frameworks - Opinion
I'm not going to comment on the rest of the stuff that was said, which is why I snipped it. I'm not a purist when it comes to OO at all. But I do have to say that while iterators in ruby are amazingly powerful that leave me going wow.. that is so cool.. The thought of how they could be abused and the thought of having to support that abuse in maintenance mode gives me shivers of pure fear. And the fact that classes can very easily be defined in half a dozen places means trying to figure out what code does by finding a class and it's declarations can become a nightmare. Of course no we get off into the ruby versus php war.. maybe I shouldn't start this conversation at all... > don't get me started on iterators in ruby and how flexible it > is in changing stuff (like method parameters - or like > redefining a whole class at runtime). hmmm :-/ pity my ruby > skills suck. :-P > > > > > Cheers, > > Rob. > > -- > PHP General Mailing List (http://www.php.net/) To > unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
Kilbride, James P. wrote: > I'm not going to comment on the rest of the stuff that was said, which > is why I snipped it. I'm not a purist when it comes to OO at all. But I > do have to say that while iterators in ruby are amazingly powerful that > leave me going wow.. that is so cool.. The thought of how they could be > abused and the thought of having to support that abuse in maintenance > mode gives me shivers of pure fear. And the fact that classes can very > easily be defined in half a dozen places means trying to figure out what > code does by finding a class and it's declarations can become a > nightmare. you make very good points. it's tribute to php that code written in it is so transparent comparitively speaking. it might a little less nimble and a bit more verbose but when your debugging someone else's spaghetti that's a bonus :-) but taking away flexibility doesn't take away the ability to write monsterous, spaghetti OO - I'm quite sure I could write stuff like that whilst conforming to any/all purist rules you want to throw at me ;-) > > Of course no we get off into the ruby versus php war.. maybe I shouldn't > start this conversation at all... no war here, move along, these are not the droids your looking for. > >> don't get me started on iterators in ruby and how flexible it >> is in changing stuff (like method parameters - or like >> redefining a whole class at runtime). hmmm :-/ pity my ruby >> skills suck. :-P >> >>> Cheers, >>> Rob. >> -- >> PHP General Mailing List (http://www.php.net/) To >> unsubscribe, visit: http://www.php.net/unsub.php >> >> > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
On Thu, 2006-08-03 at 00:29 -0300, Manuel Lemos wrote: > Hello, > > on 08/01/2006 01:35 PM Gabe said the following: > > What's the common consensus as to a solid PHP framework to use for > > application development? There seems to be a number of them out there, > > but I'm not sure which one's are the most robust, actively developed, > > secure, etc etc. > > > > Thoughts? > > There is no common consense. PHP development is not very well organized, > like for instance in the Java world where several vendors can provide > their own implementations of the same specification. This makes possible > to use the same framework API from whatever vendor you prefer. > > In the PHP world all frameworks are incompatible, even when they attempt > to implement similar feature sets. > > 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? 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
Re: [PHP] Re: PHP Frameworks - Opinion
Hello, on 08/03/2006 01:24 AM Robert Cummings said the following: >>> What's the common consensus as to a solid PHP framework to use for >>> application development? There seems to be a number of them out there, >>> but I'm not sure which one's are the most robust, actively developed, >>> secure, etc etc. >>> >>> Thoughts? >> There is no common consense. PHP development is not very well organized, >> like for instance in the Java world where several vendors can provide >> their own implementations of the same specification. This makes possible >> to use the same framework API from whatever vendor you prefer. >> >> In the PHP world all frameworks are incompatible, even when they attempt >> to implement similar feature sets. >> >> 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. 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. 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. 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. -- 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
Re: [PHP] Re: PHP Frameworks - Opinion
On Thu, 2006-08-03 at 01:47 -0300, Manuel Lemos wrote: > Hello, > > on 08/03/2006 01:24 AM Robert Cummings said the following: > >>> What's the common consensus as to a solid PHP framework to use for > >>> application development? There seems to be a number of them out there, > >>> but I'm not sure which one's are the most robust, actively developed, > >>> secure, etc etc. > >>> > >>> Thoughts? > >> There is no common consense. PHP development is not very well organized, > >> like for instance in the Java world where several vendors can provide > >> their own implementations of the same specification. This makes possible > >> to use the same framework API from whatever vendor you prefer. > >> > >> In the PHP world all frameworks are incompatible, even when they attempt > >> to implement similar feature sets. > >> > >> 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? > 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! > > 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 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. > 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! 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
Re: [PHP] Re: PHP Frameworks - Opinion
> You mean we should all be happy that so much choice is available! > I agree with Rob! I am a botanist. I have never been trained in Computer Science, as far as "industry" is concerned, I am not qualified to turn on a PC. Fortunately for me, I am also a geek. My PHP experiences started when running experiments in my wet labs, monitoring seaweed growth. If PHP did not allow me to get away with writing "newbie" (read bad) code, I would have given up and just done it the old way that botanists have been doing it for centuries. PHP gave me that freedom to start, and as a result, I now am a reasonably decent PHP developer, and run a collaborative network in 16 (and growing) African countries working on a PHP framework that I designed and wrote. Go figure. Choice is that important. If I had started with JDBC or a Java based way of doing things, this stuff would have never happened. Frameworks are not only pieces of software, but create communities of like minded people. They also build skills (and business opportunities) as ours does. If there were no choice, we would all be VB style drones with no creativity and no forward movement. Please direct flames to file 13. --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
PHPClasses 0 - Botanist 1 :-) Paul Scott wrote: > >> You mean we should all be happy that so much choice is available! >> > > I agree with Rob! I am a botanist. I have never been trained in Computer > Science, as far as "industry" is concerned, I am not qualified to turn > on a PC. Fortunately for me, I am also a geek. My PHP experiences > started when running experiments in my wet labs, monitoring seaweed > growth. If PHP did not allow me to get away with writing "newbie" (read > bad) code, I would have given up and just done it the old way that > botanists have been doing it for centuries. > > PHP gave me that freedom to start, and as a result, I now am a > reasonably decent PHP developer, and run a collaborative network in 16 > (and growing) African countries working on a PHP framework that I > designed and wrote. Go figure. > > Choice is that important. If I had started with JDBC or a Java based way > of doing things, this stuff would have never happened. Frameworks are > not only pieces of software, but create communities of like minded > people. They also build skills (and business opportunities) as ours > does. If there were no choice, we would all be VB style drones with no > creativity and no forward movement. > > Please direct flames to file 13. > > --Paul > > > > > > All Email originating from UWC is covered by disclaimer > http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP Frameworks - Opinion
I'm not so sure if the botanist wasn't saying in a rather confused way that he was playing on the same side as PHPClasses, even if he did profess to be in the other team. Did he say he was rolling his own (in a way only botanists can do) or not? -Original Message- From: Jochem Maas [mailto:[EMAIL PROTECTED] Sent: 03 August 2006 12:37 To: Paul Scott Cc: Robert Cummings; Manuel Lemos; php-general@lists.php.net Subject: Re: [PHP] Re: PHP Frameworks - Opinion PHPClasses 0 - Botanist 1 :-) Paul Scott wrote: > >> You mean we should all be happy that so much choice is available! >> > > I agree with Rob! I am a botanist. I have never been trained in Computer > Science, as far as "industry" is concerned, I am not qualified to turn > on a PC. Fortunately for me, I am also a geek. My PHP experiences > started when running experiments in my wet labs, monitoring seaweed > growth. If PHP did not allow me to get away with writing "newbie" (read > bad) code, I would have given up and just done it the old way that > botanists have been doing it for centuries. > > PHP gave me that freedom to start, and as a result, I now am a > reasonably decent PHP developer, and run a collaborative network in 16 > (and growing) African countries working on a PHP framework that I > designed and wrote. Go figure. > > Choice is that important. If I had started with JDBC or a Java based way > of doing things, this stuff would have never happened. Frameworks are > not only pieces of software, but create communities of like minded > people. They also build skills (and business opportunities) as ours > does. If there were no choice, we would all be VB style drones with no > creativity and no forward movement. > > Please direct flames to file 13. > > --Paul > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
Arno Kuhl wrote: > I'm not so sure if the botanist wasn't saying in a rather confused way that > he was playing on the same side as PHPClasses, even if he did profess to be > in the other team. Did he say he was rolling his own (in a way only > botanists can do) or not? that's beside the point - manuel tried to have his cake and eat when he a, stated writing everying yourself was preferable and b, Java was better because they have standardized APIs for framework development allowing people to switch between frameworks. besides which manuel's 'article' is crap, rob's assessment of it was pretty spot on (and it's not the first time manuel has plugged the 'article'). in the end evilMe(tm) was just fanning the flames. ;-> > > > -Original Message- > From: Jochem Maas [mailto:[EMAIL PROTECTED] > Sent: 03 August 2006 12:37 > To: Paul Scott > Cc: Robert Cummings; Manuel Lemos; php-general@lists.php.net > Subject: Re: [PHP] Re: PHP Frameworks - Opinion > > > PHPClasses 0 - Botanist 1 > > :-) > > Paul Scott wrote: >>> You mean we should all be happy that so much choice is available! >>> >> I agree with Rob! I am a botanist. I have never been trained in Computer >> Science, as far as "industry" is concerned, I am not qualified to turn >> on a PC. Fortunately for me, I am also a geek. My PHP experiences >> started when running experiments in my wet labs, monitoring seaweed >> growth. If PHP did not allow me to get away with writing "newbie" (read >> bad) code, I would have given up and just done it the old way that >> botanists have been doing it for centuries. >> >> PHP gave me that freedom to start, and as a result, I now am a >> reasonably decent PHP developer, and run a collaborative network in 16 >> (and growing) African countries working on a PHP framework that I >> designed and wrote. Go figure. >> >> Choice is that important. If I had started with JDBC or a Java based way >> of doing things, this stuff would have never happened. Frameworks are >> not only pieces of software, but create communities of like minded >> people. They also build skills (and business opportunities) as ours >> does. If there were no choice, we would all be VB style drones with no >> creativity and no forward movement. >> >> Please direct flames to file 13. >> >> --Paul >> > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP Frameworks - Opinion
On Thu, 2006-08-03 at 13:43 +0200, Arno Kuhl wrote: > I'm not so sure if the botanist wasn't saying in a rather confused way that > he was playing on the same side as PHPClasses, even if he did profess to be > in the other team. Did he say he was rolling his own (in a way only > botanists can do) or not? > What I am saying is that PHPClasses is a cool site, hell, I have even contributed a bunch of classes to it; but, what Manuel is saying, I do not agree with. I am all for choice, I am all for my project, and I am all for working collaboratively. I _choose_ to code strictly OOP, I don't have to. I choose to abstract almost everything in my code, nobody forcing me to do that. I choose to use many different authors GPL/BSD/PHP licenced code in my projects, not because of any other reason that I am lazy, and choose not to re-invent the wheel. I choose to do these things because I have the option to choose. I also choose to release every piece of code that I have ever written under a Free licence, not a freedom from price licence only. I choose to release all of my publications under a CC-BY-SA licence too. I am free, I think freely, and I have the freedom to do what needs to be done. I sleep well at night on the rare occasions that I am not coding Free Software. :) The main thing in Manual's post that got me writing this in the first place was : "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." Now in summation I say "That is just asinine". That is what makes PHP cool, especially in Africa. period. --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
On Wed, August 2, 2006 9:50 am, Gabe wrote: > Gabe wrote: >> What's the common consensus as to a solid PHP framework to use for >> application development? There seems to be a number of them out >> there, >> but I'm not sure which one's are the most robust, actively >> developed, >> secure, etc etc. >> >> Thoughts? > > Sounds like it's just personal preference. But thanks for all the > posts! > > Too bad there isn't a skeleton sort-of system that you essentially > then > just plug in the modules that you want/need to "flesh" it out. Then > you'd have your own customized framework for each app that is > developed > and keeps *all* of the modules relevant to that app. Nothing extra > would be included that isn't needed. > > Then as a developer all you're looking for is modules and not huge > frameworks that may include lots of functionality that you don't have > any interest in. It would certainly keep any attack surface smaller > when it comes to vulnerabilities. It's arguable that using a highly popular framework makes your attack surface larger. The Bad Guys would MUCH rather have a hack that they can use to attack a million sites than one that would only work on one of my stupid little sites that nobody visits and nobody cares about anyway. > Is there anything out there like that? You may want to look at Drupal, Cake, PHPNuke, Smarty, ... The list is endless, really, with a dizzying array of different features. And you're not going to get any kind of concensus on this one at this time, and probably not for the forseeable future. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
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. 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. 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. >> 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. >> 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. > 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 disorganiz
Re: [PHP] Re: PHP Frameworks - Opinion
Hello, on 08/03/2006 07:37 AM Jochem Maas said the following: > PHPClasses 0 - Botanist 1 > > :-) Erm Paul Scott is a good contributor of the PHPClasses site: http://www.phpclasses.org/browse/author/145758.html Several of his classes have been nominated to the PHP Programming Innovation Award: http://www.phpclasses.org/winners.html -- 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
Re: [PHP] Re: PHP Frameworks - Opinion
Hello, on 08/03/2006 09:17 AM Jochem Maas said the following: > Arno Kuhl wrote: >> I'm not so sure if the botanist wasn't saying in a rather confused way that >> he was playing on the same side as PHPClasses, even if he did profess to be >> in the other team. Did he say he was rolling his own (in a way only >> botanists can do) or not? > > that's beside the point - manuel tried to have his cake and eat when he > a, stated writing everying yourself was preferable and b, Java was better > because they have standardized APIs for framework development allowing people > to switch between frameworks. You totally distorting what I said. a. I said my packages are preferred for my own purposes. I did not say that my packages are prefferrable for other peoples purposes. b. I did not say Java is better, otherwise I would use Java, which I don't. I said that in the Java world the is something called Java Community Process (JCP) which is a body made from people from the Java community that is responsible for specifying Java APIs. That would be a good thing to adopt by the PHP community if it were more organized and cooperative. > besides which manuel's 'article' is crap, rob's assessment of it was pretty > spot on (and it's not the first time manuel has plugged the 'article'). > > in the end evilMe(tm) was just fanning the flames. ;-> I am sorry you felt the need to be disrespectful and resort to personal insult, even more in public. It is a clear sign that you run out of serious arguments and do not have anything worthy to add to the discussion. But I cannot be bothered if your parents did not give you proper education. You do not deserve further of my attention. Do not bother to reply. I will not follow up. -- 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
Re: [PHP] Re: PHP Frameworks - Opinion
Hello, on 08/03/2006 09:25 AM Paul Scott said the following: > The main thing in Manual's post that got me writing this in the first > place was : > > "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." I admit I have not expressed myself clearly. What I meant is not that people should be disallowed to implement alternative APIs, but rather that they should not feel the need to do it. In the Java world, JDBC is the de facto standard because Java developers do not feel the need to develop other database APIs. That happens because JDBC is a standard API defined by several players from the SQL database world that sit together and defined a consensual API specification. In the PHP world there is no such organization nor the vision of the benefits of cooperating to define such standards. I already gave an example of the benefits of having such standard API specifications in the other comment to Rob. -- 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
Re: [PHP] Re: PHP Frameworks - Opinion
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 stand
Re: [PHP] Re: PHP Frameworks - Opinion
On Thu, 2006-08-03 at 14:42 -0300, Manuel Lemos wrote: > Hello, > > on 08/03/2006 09:25 AM Paul Scott said the following: > > The main thing in Manual's post that got me writing this in the first > > place was : > > > > "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." > > I admit I have not expressed myself clearly. What I meant is not that > people should be disallowed to implement alternative APIs, but rather > that they should not feel the need to do it. I think you may be missing the point. Many people probably don't feel the "need" to create an alternative API, they may just feel the desire to do so. It's a great way to practice your skills, and in the end, you have a nice API that meets your needs. > In the Java world, JDBC is the de facto standard because Java developers > do not feel the need to develop other database APIs. That happens > because JDBC is a standard API defined by several players from the SQL > database world that sit together and defined a consensual API specification. > > In the PHP world there is no such organization nor the vision of the > benefits of cooperating to define such standards. I already gave an > example of the benefits of having such standard API specifications in > the other comment to Rob. Almost all APIs can be wrapped when necessary. Hell, the PHP engine is in many cases just a wrapper around a C API. 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
RE: [PHP] Re: PHP Frameworks - Opinion
> -Original Message- > From: Manuel Lemos [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 03, 2006 1:43 PM > To: php-general@lists.php.net > Subject: Re: [PHP] Re: PHP Frameworks - Opinion > > Hello, > > on 08/03/2006 09:25 AM Paul Scott said the following: > > The main thing in Manual's post that got me writing this in > the first > > place was : > > > > "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." > > I admit I have not expressed myself clearly. What I meant is > not that people should be disallowed to implement alternative > APIs, but rather that they should not feel the need to do it. > > In the Java world, JDBC is the de facto standard because Java > developers do not feel the need to develop other database > APIs. That happens because JDBC is a standard API defined by > several players from the SQL database world that sit together > and defined a consensual API specification. This is partially true because Java is owned and managed by SUN, and SUN is all about developing API's, both to ensure that it's own later work will work, and because it meant a better way for people to interface. And while you use JDBC as an example of something that won out, it isn't the only way to interface with Databases through Java, nor was it always accepted as the best way. In fact there is still a lot of discussion about other methods, and follow ons to JDBC. Also, JDBC doesn't eliminate the database specific variations entirely. You still have to deal with slight variances between specific databases, or incomplete JDBC implementations or JDBC implementations that provide additional functionality that isn't part of the spec. By the same token Pear_DB, and the follow ons were much like the early versino of JDBC. As is PDO in a lot of ways. The majority of the database specifics have been abstracted out and a general interface has emerged. Unlike in Java though, the PDO and Pear_(M)DB(2) families haven't settled yet(nor did JDBC overnight) but they are being developed by the community. And many people DO recognize the advantage of standards and basic API's and are working to develop exactly those kinds of things in their frameworks. Solar, as a simple example I have some experience with, is spending a lot of time thinking about how components fit togethor, how to allow for a common API while not requiring that you use Solar's classes or pieces to do things. Of course the web development world is a lot bigger than it was in the early days of JSP/J2EE. And PhP has a huge part of that so the community is larger and therefore the competing ideas is larger. But you could argue, how is PDO not a standard interface like JDBC? How was it not designed by the community and put out there for people to implement their own methods for it? > > In the PHP world there is no such organization nor the vision > of the benefits of cooperating to define such standards. I > already gave an example of the benefits of having such > standard API specifications in the other comment to Rob. > > -- > > 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 > > James Kilbride -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
2006/8/3, Manuel Lemos <[EMAIL PROTECTED]>: Hello, on 08/01/2006 01:35 PM Gabe said the following: > What's the common consensus as to a solid PHP framework to use for > application development? There seems to be a number of them out there, > but I'm not sure which one's are the most robust, actively developed, > secure, etc etc. > > Thoughts? There is no common consense. PHP development is not very well organized, like for instance in the Java world where several vendors can provide their own implementations of the same specification. This makes possible to use the same framework API from whatever vendor you prefer. In the PHP world all frameworks are incompatible, even when they attempt to implement similar feature sets. 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 Sorry to intrude with my usual obnoxious behaviour, but this is starting to affect my self-esteem (what's left of it). Am I the only one who has a really hard time reading the blog posts in phpclasses.org? Everytime a reference to this blog is posted I lose track of the discussion, because I can't really grasp what Lemos is talking about. I'd like to make some some constructive criticism, not just to Lemos but to the community in general, since I think many of us need to improve our writing skills: 1 - Don't make lng boooring posts. 2 - Get to the point. Introduction are great when they are not two pages long. 3 - Stick to the topic. Or use appropiate titles. 4 - If the topic is inherently long, use distinguishable headers and subheaders. It's a pain in the ass to read a 5 pages long article that looks the same everywhere, with no easy way to know what is the subtopic of what are you reading now. 5 - Don't talk so much about your life! You can always make another blog for that... Unless your personal experience can bring an unique insight of the point you're trying to make. That's all folks. -- 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
Re: [PHP] Re: PHP Frameworks - Opinion
On Fri, 4 Aug 2006, Jens Kleikamp wrote: Matt Todd wrote: Because of this, I determined to build my own framework. This was a few months ago, and Canvas[1] was the result of my labor. I produced this framework while working on numerous projects at the university I work at. This allowed me to build an application concurrently with the framework and give it a good benchmark for usability, feature, performance, etc. M.T. 1. http://c.anvas.es/ Please do not recommend stuff like this. It is a funky framework! What do you mean by "funky"? And why should he not recommend it? Jonathan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
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
Re: [PHP] Re: PHP Frameworks - Opinion
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 n
Re: [PHP] Re: PHP Frameworks - Opinion
Hello, on 08/03/2006 02:53 PM Robert Cummings said the following: >>> The main thing in Manual's post that got me writing this in the first >>> place was : >>> >>> "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." >> I admit I have not expressed myself clearly. What I meant is not that >> people should be disallowed to implement alternative APIs, but rather >> that they should not feel the need to do it. > > I think you may be missing the point. Many people probably don't feel > the "need" to create an alternative API, they may just feel the desire > to do so. It's a great way to practice your skills, and in the end, you > have a nice API that meets your needs. I do not think many people want to reinvent the wheel. Only those that feel forced to do it, because the alternatives are insufficient, will do it, only if they feel capable of doing it. If there were consensual API specifications like in Java world, very few people would feel forced to reinvent the wheel. >> In the Java world, JDBC is the de facto standard because Java developers >> do not feel the need to develop other database APIs. That happens >> because JDBC is a standard API defined by several players from the SQL >> database world that sit together and defined a consensual API specification. >> >> In the PHP world there is no such organization nor the vision of the >> benefits of cooperating to define such standards. I already gave an >> example of the benefits of having such standard API specifications in >> the other comment to Rob. > > Almost all APIs can be wrapped when necessary. Hell, the PHP engine is > in many cases just a wrapper around a C API. The things you say just to avoid agreeing! ;-) Most of those C APIs are also not based in any consensual standard API specifications. Because of that, there will always be people that rewrite other API for the same purpose either in C or even in pure PHP. The lack of consense is the problem. -- 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
Re: [PHP] Re: PHP Frameworks - Opinion
Hello, on 08/03/2006 02:52 PM Kilbride, James P. said the following: >> I admit I have not expressed myself clearly. What I meant is >> not that people should be disallowed to implement alternative >> APIs, but rather that they should not feel the need to do it. >> >> In the Java world, JDBC is the de facto standard because Java >> developers do not feel the need to develop other database >> APIs. That happens because JDBC is a standard API defined by >> several players from the SQL database world that sit together >> and defined a consensual API specification. > > This is partially true because Java is owned and managed by SUN, and SUN > is all about developing API's, both to ensure that it's own later work > will work, and because it meant a better way for people to interface. I do not agree with that. Many Java API are defined by many parties besides Sun. For instance, the JDBC specification was defined by an experts group from several companies listed here: http://www.jcp.org/en/jsr/detail?id=54 > By the same token Pear_DB, and the follow ons were much like the early > versino of JDBC. As is PDO in a lot of ways. The majority of the > database specifics have been abstracted out and a general interface has > emerged. Unlike in Java though, the PDO and Pear_(M)DB(2) families > haven't settled yet(nor did JDBC overnight) but they are being developed > by the community. And many people DO recognize the advantage of The matter here is not PHP versus Java. The matter is using APIs defined in consense with several interested parties of the community. The PHP community is very uncooperative. Let me give you an example. It happens that I am the Metabase developer. Metabase is the base of PEAR::MDB. PEAR::MDB2 is the follow-up of PEAR::MDB. Before PEAR::MDB existed, I invited ADODB author to cooperate and develop a common PHP database instead of keep copying Metabase features to provide the same functionality with an incompatible API. He refused to cooperate without giving a proper reason. When I tried to submit Metabase to PEAR, it was refused with all possible lame excuses that PEAR people could find then. They demanded a complete rewrite to match their style guidelines. That was completely inviable to me as Metabase had already over 12,000 lines of code. Instead I proposed that somebody does it. Fortunately Lukas Smith was brave enough to accept the proposal. It took a lot of time to convert all the code and many bugs appeared when none existed due to normal human misunderstanding mistakes. Meanwhile Metabase continued to evolve and PEAR::MDB too, but independently, hardly benefiting of mutual efforts. Several tools have been developed around each API. Tools for one API do not work with another API without a signficant conversion effort. It would have been much better if all parties have sit together and cooperate in defining a consensual API. I am not even talking about having a single API implemention. Different implementations could exist based on the same API specification. It would all have been much better for all the PHP community. > But you could argue, how is PDO not a standard interface like JDBC? How > was it not designed by the community and put out there for people to > implement their own methods for it? Forget PDO, it is yet another attempt to succeed where PHP ODBC and DBX extensions have failed. PDO is not based on consensual API specification. Therefore, it is ill fated to be used only by a fraction of the PHP users. The same goes to Zend Framework and other unilateral developements. That was the point of the blog post. While different API developers do not open their minds and cooperate with each other, nobody will benefit from consensual API specifications in the PHP world. -- 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
Re: [PHP] Re: PHP Frameworks - Opinion
On Fri, 2006-08-04 at 17:23 -0300, Manuel Lemos wrote: > Hello, > > on 08/03/2006 02:53 PM Robert Cummings said the following: > >>> The main thing in Manual's post that got me writing this in the first > >>> place was : > >>> > >>> "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." > >> I admit I have not expressed myself clearly. What I meant is not that > >> people should be disallowed to implement alternative APIs, but rather > >> that they should not feel the need to do it. > > > > I think you may be missing the point. Many people probably don't feel > > the "need" to create an alternative API, they may just feel the desire > > to do so. It's a great way to practice your skills, and in the end, you > > have a nice API that meets your needs. > > I do not think many people want to reinvent the wheel. Only those that > feel forced to do it, because the alternatives are insufficient, will do > it, only if they feel capable of doing it. > > If there were consensual API specifications like in Java world, very few > people would feel forced to reinvent the wheel. I beg to differ. I think a good number of people really enjoy re-inventing the wheel :) 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
Re: [PHP] Re: PHP Frameworks - Opinion
Hello, on 08/03/2006 05:18 PM Martin Alterisio 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 > > > Sorry to intrude with my usual obnoxious behaviour, but this is starting to > affect my self-esteem (what's left of it). Am I the only one who has a > really hard time reading the blog posts in phpclasses.org? Everytime a > reference to this blog is posted I lose track of the discussion, because I > can't really grasp what Lemos is talking about. > > I'd like to make some some constructive criticism, not just to Lemos but to > the community in general, since I think many of us need to improve our > writing skills: > > 1 - Don't make lng boooring posts. This blog in reality is the site monthly announcement newsletter. Some months there is more to tell than in others. I usually put a list of contents when the post is about many subjects. > 2 - Get to the point. Introduction are great when they are not two pages > long. I don't know what you mean by introduction. Usually there is a summary that goes in the RSS feed that is no longer than 3 or 4 paragraphs. > 3 - Stick to the topic. Or use appropiate titles. > 4 - If the topic is inherently long, use distinguishable headers and > subheaders. It's a pain in the ass to read a 5 pages long article that > looks > the same everywhere, with no easy way to know what is the subtopic of what > are you reading now. As I said, these posts often cover many topics. It may not seem by topic sections use titles. The problem is that this newsletter posts used to go by e-mail to the site subscribers in plain text, so there was no way to format titles. Anyway, now that you mentioned it I applied an additional regular expression to add title formatting when presenting it in the site. Just let me know if it looks ok now. > 5 - Don't talk so much about your life! You can always make another blog > for > that... Unless your personal experience can bring an unique insight of the > point you're trying to make. I suppose you may be talking about other peoples blogs. Personal blogs are supposed to be personal. This is the PHPClasses site blog. Usually it covers matters about the site developments and matters of interest to the site users. It does not talk about my life. It may talk about my experience when it is relevant to the post topic. -- 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
Re: [PHP] Re: PHP Frameworks - Opinion
"Robert Cummings" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Fri, 2006-08-04 at 17:23 -0300, Manuel Lemos wrote: >> Hello, >> >> on 08/03/2006 02:53 PM Robert Cummings said the following: >> >>> The main thing in Manual's post that got me writing this in the first >> >>> place was : >> >>> >> >>> "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." >> >> I admit I have not expressed myself clearly. What I meant is not that >> >> people should be disallowed to implement alternative APIs, but rather >> >> that they should not feel the need to do it. >> > >> > I think you may be missing the point. Many people probably don't feel >> > the "need" to create an alternative API, they may just feel the desire >> > to do so. It's a great way to practice your skills, and in the end, you >> > have a nice API that meets your needs. >> >> I do not think many people want to reinvent the wheel. Only those that >> feel forced to do it, because the alternatives are insufficient, will do >> it, only if they feel capable of doing it. >> >> If there were consensual API specifications like in Java world, very few >> people would feel forced to reinvent the wheel. > > I beg to differ. I think a good number of people really enjoy > re-inventing the wheel :) Also because some people don't like working with other people's square wheels, or wheels designed for a pram when they want wheels for a racing bike, or wheels that run in the wrong direction, or wheels that turn too slowly, or wheels that need expensive tyres, or (the list is endless) -- Tony Marston http://www.tonymarston.net http://www.radicore.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Frameworks - Opinion
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. > 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
Re: [PHP] Re: PHP Frameworks - Opinion
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 way 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
Re: [PHP] Re: PHP Frameworks - Opinion
2006/8/4, Manuel Lemos <[EMAIL PROTECTED]>: Hello, on 08/03/2006 05:18 PM Martin Alterisio 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 > > > Sorry to intrude with my usual obnoxious behaviour, but this is starting to > affect my self-esteem (what's left of it). Am I the only one who has a > really hard time reading the blog posts in phpclasses.org? Everytime a > reference to this blog is posted I lose track of the discussion, because I > can't really grasp what Lemos is talking about. > > I'd like to make some some constructive criticism, not just to Lemos but to > the community in general, since I think many of us need to improve our > writing skills: > > 1 - Don't make lng boooring posts. This blog in reality is the site monthly announcement newsletter. Some months there is more to tell than in others. I usually put a list of contents when the post is about many subjects. Then maybe you should consider making it a _weekly_ announcement newsletter, 'cause some of those posts are really really too long to digest in only one shot. 2 - Get to the point. Introduction are great when they are not two pages > long. I don't know what you mean by introduction. Usually there is a summary that goes in the RSS feed that is no longer than 3 or 4 paragraphs. I mean all the things you need to say before actually getting into what you want to talk about. Just take for example the post about "recommend php framework", look how much you have to read before actually get any info relating directly to php frameworks. Is true that there are many things to say before about frameworks hype, but couldn't it be explained in less words? 3 - Stick to the topic. Or use appropiate titles. > 4 - If the topic is inherently long, use distinguishable headers and > subheaders. It's a pain in the ass to read a 5 pages long article that > looks > the same everywhere, with no easy way to know what is the subtopic of what > are you reading now. As I said, these posts often cover many topics. It may not seem by topic sections use titles. The problem is that this newsletter posts used to go by e-mail to the site subscribers in plain text, so there was no way to format titles. I was unaware of that, I understand now. It's really a pain in the ass to format a text only email for proper reading even more if the same text has to be used in a website. Anyway, now that you mentioned it I applied an additional regular expression to add title formatting when presenting it in the site. Just let me know if it looks ok now. Yeah, I saw that. I believe it's a little bit better now. 5 - Don't talk so much about your life! You can always make another blog > for > that... Unless your personal experience can bring an unique insight of the > point you're trying to make. I suppose you may be talking about other peoples blogs. Personal blogs are supposed to be personal. This is the PHPClasses site blog. Usually it covers matters about the site developments and matters of interest to the site users. It does not talk about my life. It may talk about my experience when it is relevant to the post topic. Generally speaking, yes, I'm talking about other peoples blogs. I'm sick tired of all the holy crusades out there, specially when it comes to Web2.0evangelists. You may have not noticed it but somewhere here or there you let your subconcious write for you, specially on the topic of Web2.0 (I used the term twice already, please stop me before I have to pay royalties to O'reilly). It may be just an adjective, but that's all it takes to make a mildly objetive point of view turn into a completely subjective point of view. Just check your article about "is php ready for ..." *that thing I said before*, and you'll see that how, without noticing it, personal feelings tend to appear and change the article completely. Probably that's what made you write so much about how you believe phpclasses.org is a *that term* enabled site, and why. Was all that really necesary for the purpose of the article? Or you were just uncounciously trying to prove something to all those lamers out there? Does it really matter if your site is "in" or "out"? We are not fashion designers...
Re: [PHP] Re: PHP Frameworks - Opinion
Hello, on 08/05/2006 11:47 PM Robert Cummings said the following: 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. If you go and read your replies to my messages throughout this thread you may notice a pattern of you trying to contradict almost everything I said. When you ended the phrase above with the word "Touché", it seemed that winning the argument was very important for you. Robert, relax! I am not in this thread to compete with anyone. If expresses disagreement with me, I think to myself that since I am not a native english speaker, I may have not expressed myself clearly. Therefore, I try to explain myself better. If you still disagree after my explanations, that is ok, I will not be upset because of that. I am not making myself important. My opinion is mine, yours is yours, neither is necessarily better than the other. There is no need for manifestations of excessive joy, as if winning an argument is a big deal. That is my opinion, of course. >> 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? I was not complaining, remember? I was just explaining that unlike you stated, I do not have a problem with other people's code. I just would rather not rely on packages that I don't control their development, as it may cause inconvinient effects to the progress of my projects. Somehow, I explained that in my post with advice for instance, of excessive framework class interdependencies, PHP 5 dependent frameworks, frameworks developed by people that did not try them much in real world applications, etc.. >>> >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 am afraid that you still do not get the point that I wrote an article that I wanted to be green, it is written in the summary that it is green, so people that do not like green do not bother reading it. Still you are complaining that the article is not red as you think it should be. What can I do for you? Nothing. Never mind. -- 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
Re: [PHP] Re: PHP Frameworks - Opinion
Hello, on 08/06/2006 09:52 PM Martin Alterisio 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 >> > >> > >> > Sorry to intrude with my usual obnoxious behaviour, but this is >> starting >> to >> > affect my self-esteem (what's left of it). Am I the only one who has a >> > really hard time reading the blog posts in phpclasses.org? Everytime a >> > reference to this blog is posted I lose track of the discussion, >> because >> I >> > can't really grasp what Lemos is talking about. >> > >> > I'd like to make some some constructive criticism, not just to Lemos >> but >> to >> > the community in general, since I think many of us need to improve our >> > writing skills: >> > >> > 1 - Don't make lng boooring posts. >> >> This blog in reality is the site monthly announcement newsletter. Some >> months there is more to tell than in others. I usually put a list of >> contents when the post is about many subjects. > > > Then maybe you should consider making it a _weekly_ announcement > newsletter, > 'cause some of those posts are really really too long to digest in only one > shot. Unfortunately I do not have so much time to post site announcements that often. Anyway, this one was not an announcement. I am commited to post something at least once every month to put something interesting in the site editors newsletter. When there are new features to announce, I try to fill the space with an opinion article. Some people like it, other people are not interested. In any case, at the top of the article there is a summary of the topics in the article so anybody can figure whether there is anything of interest in the article, so they do not have to read it all the way. >> 2 - Get to the point. Introduction are great when they are not two pages >> > long. >> >> I don't know what you mean by introduction. Usually there is a summary >> that goes in the RSS feed that is no longer than 3 or 4 paragraphs. > > > I mean all the things you need to say before actually getting into what you > want to talk about. Just take for example the post about "recommend php > framework", look how much you have to read before actually get any info > relating directly to php frameworks. Is true that there are many things to > say before about frameworks hype, but couldn't it be explained in less > words? I suppose it is a matter of style. As I said, some people appreciate a more articulated style, other people prefer a more objective style like you. Actually I also prefer a more objective style when I am reading other people's articles. That is why I split the article in sections so you can jump to whatever has what matters to you. >> 3 - Stick to the topic. Or use appropiate titles. >> >> > 4 - If the topic is inherently long, use distinguishable headers and >> > subheaders. It's a pain in the ass to read a 5 pages long article that >> > looks >> > the same everywhere, with no easy way to know what is the subtopic of >> what >> > are you reading now. >> >> As I said, these posts often cover many topics. It may not seem by topic >> sections use titles. The problem is that this newsletter posts used to >> go by e-mail to the site subscribers in plain text, so there was no way >> to format titles. > > > I was unaware of that, I understand now. It's really a pain in the ass to > format a text only email for proper reading even more if the same text > has to be used in a website. Currently I no longer send the whole article by e-mail. Only the summary is sent now. These posts were being sent to near 150,000 people and that made the site spend too much bandwidth. I just did not had the time to integrate an HTML or BBCode based editor where the articles are posted to make it look better. It is on my todo list. >> 5 - Don't talk so much about your life! You can always make another blog >> > for >> > that... Unless your personal experience can bring an unique insight of >> the >> > point you're trying to make. >> >> I suppose you may be talking about other peoples blogs. Personal blogs >> are supposed to be personal. This is the PHPClasses site blog. Usually >> it covers matters about the site developments and matters of interest to >> the site users. It does not talk about my life. It may talk about my >> experience when it is relevant to the post topic. > > > Generally speaking, yes, I'm talking about other peoples blogs. I'm sick > tired of all the holy crusades out there, specially when it comes to > Web2.0evangelists. You may have not noticed it but somewhere here or > there you let > your subconcious write for you, specially on the topic of Web2.0 (I used > the > term twice already, please stop me before I have to pay royalties to > O'reilly). It may be just an adjective, but that's all
Re: Re: [PHP] Re: PHP Frameworks - Opinion
In my experience with the other frameworks (primarily Wasp, CakePHP,
Symfony, eZ Components, and Zend Framework), I've found that I was not
satisfied with the quantity of low-quality code they advocate. I have
a high standard for code quality, readability, maintainability, and
(more generally) semantics.
Because of this, I determined to build my own framework. This was a
few months ago, and Canvas[1] was the result of my labor. I produced
this framework while working on numerous projects at the university I
work at. This allowed me to build an application concurrently with the
framework and give it a good benchmark for usability, feature,
performance, etc.
Some of the features include pretty URLs and a fairly capable router,
a simplistic implementation of the ActiveRecord pattern (with a very
easy way to make adapters for your favorite flavor of RDBMS),
incorporation of Smarty for its templating, and usage of the MVC
pattern. (Of course, this list is hardly sorted by priority.)
A quick sample of using the ActiveRecord implementation:
class shoe extends Model {}
$shoe = new shoe();
$shoe->find_by_color('green')->delete();
$shoe->find_by_id(12);
$shoe->color = 'red';
$shoe->save();
$shoe->find_or_create_by_color('tangerine');
$shoe->find(array("where"=>array('color like ":color" or size >
":size", "color"=>"pink", "size"=>"11")))->all();
Do check it out.
M.T.
1. http://c.anvas.es/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
