Well I don’t agree with “picking and choosing cool components depending on what you need done” because that’s not the aim of a framework… That’s pear etc. you’re talking about, isn’t it?

The power of a framework is, in my opinion, it guides how to work and puts some standards on how to work, beyond providing some fancy libraries.

So that the application will be reliable, easy to develop and easily understandable by multiple developers. Even a developer lately joined the team can easily figure out what’s going on when the standards are well defined and known…

Either way (glue or full-stack), if you’re working on an advanced or moderate project you have to understand the structure of the framework well…
…and when you know how the framework works pretty well, you can still prefer your own solutions…

I’m going to try to hook it up to Qooxdoo for a web application using a single page and the entire site built in javascript. The Zend Framework allows me to hook into the MVC code at just the right location to change the output from the usual HTML pages to JSON. The last two I did simply used a ton of HTML with hundreds of INPUT tags.

Does anyone else have experience developing applications that runs in a webbrowser?

TurboGears is both full stack and glue. It covers everything you need to build a webapp and puts you on a path in terms of how to use the pieces, but it is built up from separate Python projects. Django is full-stack and largely consists of homegrown code.

There are so many frameworks (in every language) these days that they come in all kinds of shapes and sizes. Pick the one that gets you the most leverage on the project you’re tackling.

Not all the projects I do, are on that scale however. If I need to do a few contact forms, with spam/email injection protection, I don’t need a full blown MVC install to do that, just a good email class and spam filter system.

The glue approach, is not a “noob” approach, as there is much more to PHP development, then full integrated sites or applications. I personally dispise the dependency hell that ensues when trying to get something small done with re-usable components, when using something like PEAR, which is not as well supported or configurable, accross all the servers and hosters I have to work on.

I shouldn’t have to go back to writing non-reusable proceedural code, just because the project is small.

http://www.phpontrax.com

@Ian: You make some really good points there. I think Glue vs. Full-stack is also about programming styles. Of course, any custom-built solution that uses something like CodeIgniter as what glues it all together is likely to be faster than a full-stack solution…but I’m willing to be that adding things going forward is easier with a full-stack than with the glue approach. My friends who do use CodeIgniter tell me that they end up fiddling with their code quite a bit because, well, they end up having to write a lot of things themselves whereas CakePHP might already offer that to them.

You also talk about having to “… explain that to a client when they talk about scaling”. I think your argument is not a valid one, and that if you’re able to save a client $2K on development costs, you won’t be giving that back in terms of extra hardware requirements. What’s more expensive, developers or hardware? The answer is, of course, developers. In almost every application I’ve ever built, the bottleneck is not the code, it’s the main data source (database or otherwise) CodeIgniter is not going to make your database operations faster.

It’s okay to not use “the big stack frameworks”, but don’t kid yourself as to what the real issues are when you have to worry about “scaling” your application. It ain’t the code.