On Wed, 2009-01-14 at 13:39 -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: http://paul-m-jones.com/?p=315 > > 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've not used Zend myself, so I can't say for certain, but the above > tenements I think would still hold true. I guess I would trust the > Zend one the most given they actually make PHP, but at this point in > time, I would never choose to use a bloated framework. Then again, I > write enterprise level and very custom applications (Saas) so maybe > this doesn't apply if all you're trying to do is make yet another Blog > or Photo-album or personal/corporate website or something > generic/basic. I've been coding nearly 20 years and founded several > $MM companies. That's my take (or rant depending on how you look at > it). > > Daevid. > http://daevid.com > > > On Wed, 2009-01-14 at 20:36 +0000, jcorry@xxxxxxxxx wrote: > > I've been reading about these great new 'frameworks' for PHP development. > > > > The most similar experience I have so far is using PEAR/Smarty in > > application development. > > > > I am becoming very interested in adding one (or more) of these frameworks > > to my work existence. > > > > I'm leaning toward the Zend Framework for the following reasons: > > 1. Zend's commitment to PHP in the enterprise environment > > 2. I'm studying for Zend PHP certification...so remaining within the same > > family sort of makes sense. > > 3. It's widely heralded as a very good 'framework' > > 4. Integration with my IDE, Zend Studio > > 5. Great support/userbase/forums/docs > > > > I'm getting ready to start a new project that is going to be somewhat of a > > stretch for me. It'll be probably the most complex project I've done where > > I'm the only designer/developer and have to do everything myself: from func > > spec to mockups to wireframes to database design to documentation to code > > to maintenance...all of it is me. > > > > What do you think, should I kill 2 birds with one stone and use the ZF to > > build this new project? Or would it slow me down to add 'learning the ins > > and outs of a new way of working' to my already long list of tasks and > > short time to complete them? > > > > Zend touts this thing as 'saving time' and 'letting you work more > > efficiently'. Will the new developer who is learning how to use ZF realize > > those efficiencies or are they only for the people who are quite > > experienced with the framework? > > > > I'm curious about whether it's practical to begin with a framework by using > > it on a real, production project. > > > > ?? > > > > John Corry > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php I agree with you right up to the DIV magic bullet part. You're actually better off using divs properly, as you can create a nice flowing layout that is catered for well in mobile browsers, tables slow the rendering of pages (some browsers wait until the whole table has loaded before it starts to display them) and it is actually very easy to create a nice layout without using tables. Keep tables for what they were intended for - tabular data! I do understand what you mean about frameworks though. Sometimes it's just better to build without them, as you end up with something built for a specific purpose, which will tend to work as you want, and more efficiently too. Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
