I think Daevid has some valid points although I think frameworks still have a lot of value, I've recently learned to use the CakePHP framework and have been happy with the development time improvements. But more then that I've found it has made my applications more extensible and flexible. As to the point about training new employees to the framework - in my experience I would have much prefered previous colleagues to have used a framework which would at least provide a reference for me to use rather than seeing several development styles throughout the code and inconsistent documentation. No, frameworks are not silver bullets but still a useful programming tool in the right situations/applications. Cheers, Ewen 2009/1/15 Phpster <phpster@xxxxxxxxx> > Core files are what my plans include too. > > Bastien > > Sent from my iPod > > On Jan 14, 2009, at 9:26 PM, "Kyle Terry" <kyle@xxxxxxxxxxxxx> wrote: > > On Wed, Jan 14, 2009 at 6:17 PM, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx >> >wrote: >> >> On Wed, Jan 14, 2009 at 01:39:02PM -0800, Daevid Vincent wrote: >>> >>> Not to start a Holy War (as these "to framework" or "not to framework" >>>> debates often turn into), but I personally had a horrible experience >>>> >>> with >>> >>>> using frameworks. I was forced to use Symfony at my last job and it >>>> >>> was so >>> >>>> cumbersome and slow to do even the simplest things. The whole MVC >>>> >>> thing >>> >>>> can be overkill. Plus the learning curve can be quite steep. Then if >>>> >>> you >>> >>>> want to hire other developers to work with you, you have to train them >>>> >>> and >>> >>>> let them ramp up on not only the framework but also your core project >>>> >>> too! >>> >>>> More wasted time. >>>> >>>> The pages are significantly slower than straight PHP by orders of >>>> magnitude: [1]http://paul-m-jones.com/?p=315 >>>> >>> >>> What a great link! I've never seen this kind of comparison before. HTML >>> is 70% faster than straight PHP, and the frameworks (even codeigniter) >>> deliver less than 20% of the performance of straight PHP. >>> >>> >>>> The basic problem with frameworks is they try to be one thing for all >>>> people. This carries a lot of baggage with it. There's a lot of crap >>>> >>> you >>> >>>> end up pulling in that you don't want/need. Plus if you want to >>>> >>> deviate at >>> >>>> all, you either have to roll your own, or sometimes you simply just >>>> >>> can't. >>> >>>> They seem attractive with all their plugins and stuff, but honestly, >>>> rarely do the plugins do EXACTLY what you want, the way you want. It >>>> >>> might >>> >>>> be as simple as trying to change the look/feel of a button or >>>> >>> something >>> >>>> and you'll find out that you can't -- so now you have this website >>>> >>> that >>> >>>> has this section that doesn't look like the rest of your site. And if >>>> >>> you >>> >>>> find a bug, you have to try to either fix it yourself and then keep >>>> >>> those >>> >>>> changes migrated into new updates, or submit it to the developer and >>>> >>> hope >>> >>>> they implement them (and trust me, you can submit to them and have >>>> >>> them >>> >>>> rejected for all sorts of lame reasons -- even though the work has >>>> >>> been >>> >>>> done and you're using it!) >>>> >>>> I advise against it. Just follow good practices and use thin wrappers >>>> >>> and >>> >>>> functions. Don't get all OO googlie eyed and try to over-engineer and >>>> over-OO the code. OO is great for some things (like a User class) but >>>> don't start making some OO page renderer or form builder. Don't fall >>>> >>> into >>> >>>> the DB Abstraction trap either -- just use a wrapper around your DB >>>> >>> calls >>> >>>> (see attached), so you can swap out that wrapper if (and you almost >>>> >>> never >>> >>>> do) you change the DB. Don't be suckered by something like QuickForms >>>> >>> -- >>> >>>> you WILL run into limitations that you can't get around and are at >>>> >>> their >>> >>>> mercy. Don't buy the hype that DIV's are the magic bullet and TABLEs >>>> >>> are >>> >>>> "poor design" -- Tables are still the best and most ubiquitous way to >>>> align things in a browser agnostic way (including mobile phones, etc.) >>>> >>> and >>> >>>> to layout forms. >>>> >>> >>> I agree and disagree. I agree there's waaay too much herd mentality in >>> the programming field. (Fortunately, Linus Torvalds didn't listen to the >>> academics who insisted that microkernels where THE WAY, or we wouldn't >>> have Linux today.) OO is nifty for some things, but it's certainly not >>> the "fountain of reusability" it was originally promoted to be. And I >>> also agree about tables versus CSS. I can render a page very precisely >>> with tables that would take me hours to get right with CSS. And I really >>> don't give a crap about what "experts" say about anything. I find >>> "experts" to be wrong much of the time. >>> >>> OTOH, I just finished writing about 80K lines of PHP/HTML, all by hand, >>> no OO, no classes, no nothing. Each page in one file, except for a few >>> helper functions in a couple of common files. I wouldn't want to go >>> through that again. I've opted for a framework on rewriting this code, >>> just to cut down on the number of lines of code I have to manually >>> write. But I built my own framework, which doesn't call in 20 files for >>> each page load. Very compact. Probably not suitable for every kind of >>> project, but it works for this. >>> >>> Incidentally, I would differ from the reviewer in the link above only in >>> this respect: He maintains that every line of code adds time. While this >>> is true, I believe it's the number of files which have to be opened >>> which drags down framework numbers the most. When I wrote C code, the >>> CPU would blaze through the actual code, but file opens and reads >>> consumed far more time than in-memory code execution. >>> >>> Paul >>> -- >>> Paul M. Foster >>> >>> -- >>> PHP General Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >>> I agree heavily on the file opening part. I hate having to look through >> a >> stack trace of 20 or 30 just to track down why an exception was thrown. We >> are working on moving our entire framework into less files and more of a >> core set of files that handles a lot of tasks. >> >> -- >> Kyle Terry | www.kyleterry.com >> > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
