The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I was thinking about the reasons why frameworks become bloated, and I came up with three C's: cleverness, completeness and convenience.

Cleverness: over-engineering, using design patterns because they look good, etc.

Completeness: adding stuff just to cover all the technical options. I'm just trying to implement form handling, and I want PHP code to handle a text input control for validation, but not Submit buttons. The Submit button will just be represented as HTML in the template. So I'm not implementing PHP code for all the possible elements of a form just to make it complete.

Since a framework or toolkit needs to cater to many people's needs, the demands for completeness will obviously be greater. But I would at least keep this in mind.

Convenience: hiding too much of what's going on inside. I was studying the PEAR package HTML_Quickform, and one thing I don't like about it is that it handles the HTTP request behind the scenes, setting the values in the form without my knowledge. I'd rather have something more explicit, like:

PHP Code:

// Don't take this too literally; I know you need some testing on the results of
// validation, etc.
$request = new HttpRequest;
$form = new Form;
$form->valiidate($request);
$form->populateWith($request);

I would propose exercising great caution in making a framework/toolkit excessively convenient; real productivity gain is something else. Give the client code a chance to be expressive.

In the beginning, I thought that the include and wrap tags were sufficient tools for composition. This has turned out not to be true. wrap, especially has turned out to be a dead end, as it has several bugs and gotchas that cannot be easily fixed in the current architecture.

I've always written everything from new, I never rely on frameworks or even pear (except to borrow ideas I suppose). Two main reasons: can't trust other's code as I have had bad experiences with perl's cpan, and frameworks are always too inefficient for me - it may not matter at the beginning, but when you get millions of page views then every extra layer of function/method calls and manipulation of data really does add up in both time and CPU usage. It's like all that .NET framework stuff, just don't see the point of it, way too clunky.

I was thinking about the reasons why frameworks become bloated, and I came up with three C's: cleverness, completeness and convenience.

That's why I have repeatedly suggested that what we need is a code base where the code is basic, incomplete and requires work to extend into a framework.

Perhaps we should rewind the "skeleton" thread and start over with dagfinn, DougBTX, etc. involved? They have had good insight into the flaws of the earler process. Define a core team and agree on a process and goals. It is certainly difficult work to make the comprimises necessary to create a clean set of base classes. But the reward is great for those involved (and the broader community). There are a couple of SourceForge projects available so the development can be under CVS.

I was thinking about the reasons why frameworks become bloated, and I came up with three C's: cleverness, completeness and convenience.

Cleverness: over-engineering, using design patterns because they look good, etc.

I agree with this but with some additions. Which kind of erase the subsequent C's.

Frameworks become bloated and useless the moment some "smarty" decides to add a template system to the entire presentation layer.

Frameworks become bloated when the developers go on a training exercise and add in everything they are curious about (AJAX) but never complete the addition. In other words the project becomes a playground.

My recommendation to a newbie is to pick a OSS portal system that works like a framework and learn it. Stay away from the phpnuke variants though. Go with (PHP)Typo3, Drupal or (Perl) Midgard, WebGUI. You might try Rails but be aware of the pitsfalls of using a new system.

any framework is going to require a learning curve of some kind and if you go oop (and incorporate things like Reflection, Interfaces, and even Events), that is going to increase that learning curve.

One thing that many php frameworks lack that the language itself is so good about, is the amount of documentation (along with community comments and tutorials everywhere).

Also you have to think about the framework, is this something for you or for the masses, and if its for everyone, why should they use it? what are you offering them? not everyone has a xp methodology and not everyone wants to develop with mvc in mind.

and should a framework force you to develop with a certain style or methodology?

greater flexibility often increases complexity.

it also might be wiser to start with php5 for a framework rather than php4, so that once php 5 finally takes a hold on most of the servers, it will be something solid to build off of.

any framework is going to require a learning curve of some kind and if you go oop (and incorporate things like Reflection, Interfaces, and even Events), that is going to increase that learning curve.

The learning cuve to use the framework or to develop the framework? Are those two different, and should they be different?

Originally Posted by mx2k

One thing that many php frameworks lack that the language itself is so good about, is the amount of documentation (along with community comments and tutorials everywhere).

Good point.

Originally Posted by mx2k

Also you have to think about the framework, is this something for you or for the masses,

I'm not sure if there is such a thing as "the masses" in this context.

Originally Posted by mx2k

what are you offering them?

Your vision embodied in something you would want to use?

Originally Posted by mx2k

not everyone has a xp methodology and not everyone wants to develop with mvc in mind.

Then they should use a framework without mvc in mind, who don't want to use an xp methodology. For people who do want to use mvc with an xp methodology, then they should be able to find a framework with mvc in mind which they can use an xp methodology with. The question is, do we want to write that framework?

Originally Posted by mx2k

and should a framework force you to develop with a certain style or methodology?

The only "force" would be if you sold it to someone's boss, and the boss forced his minions to use it. The framework cannot force the developer if the deveoper is not forced to use the framework, the framework can only support or encourage a certain style or methodology. If it doesn't do either, what is it doing? How do you encourage apathy? Is that what we want to do?

Originally Posted by mx2k

greater flexibility often increases complexity.

Another good point.

Originally Posted by mx2k

it also might be wiser to start with php5 for a framework rather than php4, so that once php 5 finally takes a hold on most of the servers, it will be something solid to build off of.

Or if it is truly compelling, it might be a reason for them to encourage their host to switch, or for them to switch hosts.

The learning cuve to use the framework or to develop the framework? Are those two different, and should they be different?

i'm thinking the framework will have a learning curve for both. however good documentation and tutorials with a powerful framework with many levels of entry would more enticing than just say a framework for developers. Php appeals to people because its supposed to encourage rapid development.

Originally Posted by DougBTX

I'm not sure if there is such a thing as "the masses" in this context.

well there have been mentioning of personal use and some for a wider use, one that a ton of phpers could rally behind.

Originally Posted by DougBTX

Your vision embodied in something you would want to use?

i'm not quite sure what you mean, so please forgive me if i answer out of context. I have spent a good while from the web designers side of things and have gotten thrown into web development as well as some other avenues. So coming out of that, i try to make things easier on designers and other people as possible. The less they have to think and the more they can do without having to learn a ton of extra stuff, the happier they are.

Originally Posted by DougBTX

The only "force" would be if you sold it to someone's boss, and the boss forced his minions to use it. The framework cannot force the developer if the deveoper is not forced to use the framework, the framework can only support or encourage a certain style or methodology. If it doesn't do either, what is it doing? How do you encourage apathy? Is that what we want to do?

this answer is not for argument sake, but just a p.o.v. but if popular applications use a framework, and you are paid to modify or incorporate that appliction into another, then you are forced to work with that framework in order to get that job done, unless you want to rewrite that whole thing.

And if there going to be one widely used framework that is adopted to the point where even applications like phpbb will use it, i would hope in flexibility of that framework that people can build off of using their own methodologies rather being limited by such a framework to do things only in such a way.

Originally Posted by DougBTX

Or if it is truly compelling, it might be a reason for them to encourage their host to switch, or for them to switch hosts.

would be nice. =)

and i still think it would not be a bad idea to build a core framework platform in c and add it as a php extention. I've looked at prado and a ton of other stuff. The T and com and prop can get annoying and web designers don't want to learn 50 billion different ways to generate a dynamic anchor tag or image. i like the prado idea, and wact seems promising but its still easier for me to write something versuses building on that and then trying to work with a designer or someone who can only do html, cause php would still be easier for them to learn. (so i guess add less confusing to the usability needs of a framework)

My professor enlightened me yesterday by explaining that on average about 65% of the cost of a project is spent on code maintenance and only about 15% of the cost is spent on coding.

My point (his point actually) is that you should aim at reducing cost (and thus time) on maintenance rather than coding time as in the long run you'll benefit most from it.

Having said that I believe you should review the project carefully and decide wether it is wise too choose a CMS for it could reduce you development time. On the other hand, if you expect much customization in the future, perhaps it is best to write the code yourself, as you'll write it according to current and future needs.

Also keep in mind that setting up CMS' usually takes more time than you have planned, as a CMS is a large package with so many functions you'll have a hard time understanding the code and finding the things you want to fix..

Just think about it!

UPDATE: I just re-read you post and found out that I misread it before. The point above is still valid though, though it might not be relevant to your question anymore

A framework and a Content Management System are quite different things. A CMS is an application, a framework is something you build an application on. You could build an application based on a CMS (you would extend the original application into a new application), but you won't get the maintenance benifits you would get using a good framework (where you wouldn't change the framework, you would just build an application which uses the framework). This is because you should be able to update the framework without large changes to your current applicaiton. If you are extending another application, you would have to work out how any changes to the original application apply to your new application, or whether they apply at all. That maintenance work could be more trouble than it's worth.

These conversations usually take a theoretical turn towards "here are all the reasons it won't work" which is not a bad thing in itself. For me the problems is that there are not enough comments about "here are the things that would work." The experience from the "skeleton" script it that the common classes are very similar when the pool of programmers are the OO developers in this forum. That basic set: DataSpace, Validator, Filter, FrontController, base Controller, filter and controller chains, etc. are all classes that a good group of developers in this forum have and use varients of.

The problem was not the code or the ideas. It was getting the interface style to be acceptable to programmers who's current code is slightly different. Much if it was naming and directory structure so those need to be definable. But the subtler design issues just need to be worked through, either by allowing for variation within the design or providing enough other good stuff so that people are willing to adapt in a few areas.

Going back to the "skeleton" thread, we found common ground on: DataSpace, Validator, Filter, FrontController, filter and controller chains. Those are either fairly standard classes such as Validator and Filter. Or they are far enough from the application code (e.g. FrontController and controller chains) that we could us them without much change to our code. All of those classes are also relatively simple. As we got closer to the application code with the Page Controllers the complexity increased and the impact on our existing app code became more apparent. Things bogged down and forked as they usually do, but it was more from the difficulty of maintaining a focused conversation in a public forum as the complexity increased. That could be solved by moving development to a SourceForge site.

I guess that what I am saying is: sure we can think of a thousand reasons why it won't work -- we're programmers. But it really would be not as difficult as these conversations imply to build this usefull code base that gets discussed over and over. The "skeleton" is a good prototype for what the code and the process would look like. Certainly kyberfabrikken, Ezku and I came away from that process with a lot of good code and ideas for our own three frameworks (hopefully others did too).

The project development space is available on SourceForge, the talented pool of likeminded developers is available here, all that is missing is some clear goals and the willingness of the developers to embrace a common code base that differs slightly from their own or find a clean way to extend it to appeal to programmers who want that style.

I just finished reading the skeleton thread and the application thread. Whew! That took a while. There seemed to be a emphasis on structure in those threads. I think one quality that makes a framework good is that it is extracted from a working application, rather than designed up front. There were some great points in those threads, but it was hard for me to evaluate some of the decisions because the examples of use were so trivial.

The original poster asked should I use a PHP framework and if so, which one should I use. Let me suggest then a way to compare and evaluate PHP frameworks.

I think the only way to evaluate a framework is to look at sample applications written with that framework. The more complete the example, the better the feel one can get for the framework.

I would suggest that such an application should include the following use cases:
CRUD with validation
User authentication
A Many to Many relationship
Paging a list
A mass delete/edit option
A portal style page that composes smaller units
A multiple page (wizard style) form
Alternate views of the same data (say HTML and RSS)

Perhaps a clone of del.ici.ous could be made to implement these use cases? Perhaps a scouring of hotscripts would turn up something open source that could serve as a starting point.

One can evaluate two frameworks (or a framework versus native PHP) based on the amount of code needed to write this application.

An additional way to evaluate frameworks would be to specify a few "change cases." An example might be "Change the footer on every page to have link X." The size of the patch to the original application and the number of places that require change can help get a feel for how well the framework organizes the code. As Quaint reminds us, maintenance takes the most time.

The evaluation application could be specified as a set of web test cases and a native PHP reference implementation that passed the test.

I think having more or more standard framework evaluation examples such as this would help focus the efforts of various framework authors as well as allowing framework users to more directly compare frameworks.

I think the only way to evaluate a framework is to look at sample applications written with that framework.

Taking it further, I think the only examples you will find which are worth looking at, are applications which are projects in their own right. For example with Rails the examples include: Basecamp, Odeo, StrongSpace and 43things. Noone is going to build one of them just to show off their framework, there needs to be the drive beyond the framework.

Originally Posted by arborint

It was getting the interface style to be acceptable to programmers who's current code is slightly different.

I think we need to take the plunge, and use the code we are sharing as is - in the DI threads, I've been posting code I actually want to use, whether that helps others directly, I don't know. (It also helps that those threads have a focus on PHP4, so I don't need to defend an ideological position against type hints and declaring functions public )

Originally Posted by Selkirk

One can evaluate two frameworks (or a framework versus native PHP) based on the amount of code needed to write this application.

That gives a measure of how close the framework is to the application in mind. If you wanted to write a blogging application, and knowing nothing you picked TextPattern as your "framework", and you found you had very little code to write to turn it into a blog, you'd declare that it is the "better" "framework".

something I read in a review once when I was looking at 3D drawing programs: feel free to ignore the examples in the "made by XYZ product" galleries. There might be beautiful pictures, but all that tells you is that there was a good artist behind them, it doesn't tell you if the program was crashing every five minutes while they were drawing the picture.

I'm not sure what better way there is to evaluate a framework than to use it. With that in mind, here's an idea: have the code in CVS, and we all set up a cron job to force all our local copies to be up to date. You commit any local changes, by the next day, everyone working with the code uses those changes. We should be able to find a balance where we can have code stable enough, and if we attach automated tests to the CVS cron script, and we rely only on parts of the framework that are tested, at least we'll be able to see what changed.

That's exactly the point: the ease with which you can swap out a different presentational context might tell you a lot about the design.

On the other hand, you could argue that this is adding an unecessary constraint to the problem. I don't know. I expect you wouldn't want to make a cli portal but you might well want to run a backup program from the command line.

OK but suppose I'm writing an installation script. It's got to move files around, run tests, maybe move the files back again if the tests fail. If I've got a backup app lying around I'll already have much of the file copying code I need. A few tweaks and it can maybe be used in the installation script.

Php may not be the best shell scripting language but it's the one I know and I use it a lot at work for simple maintenance tasks on an office network. I'm always keeping an eye on the cli (Incidentally, it's amazing how a useless old celeron 400 which struggles with windows can become a very useful little server with Gentoo ).

Noone is going to build one of them just to show off their framework, there needs to be the drive beyond the framework.

Actually, they will. Petstore has become a standard comparison application in the Java world. I know of at least a half a dozen working pet store examples written in various frameworks. The appfuse project has a contact manager demo written in five different java frameworks.

Unfortunately, I don't know of a single fully functional working petstore application for PHP.

I just finished reading the skeleton thread and the application thread. Whew! That took a while. There seemed to be a emphasis on structure in those threads. I think one quality that makes a framework good is that it is extracted from a working application, rather than designed up front.

I agree with this in principle, but a part of what was going on in that thread was not to build a framework, but to create the building blocks for a framework from our common expericence. As I recall it started with kyberfabrikken and I comparing FrontController ideas and realizing that we had so much in common -- except mapping. His plug-in Request Mappers made it so we could both share the same base code. For me that was the experience that made things interesting. We didn't just agree to disagree -- we designed what I think is a clean system to allow disagreements within a common codebase. Defining the what we agree on and what we don't and designing in flex points for the latter is critical for me.

One of my main problems is the lack of design flexiblity in current frameworks (which may be real or only that the framework developer only documented the way she/he uses it).

Originally Posted by Selkirk

There were some great points in those threads, but it was hard for me to evaluate some of the decisions because the examples of use were so trivial.

Yes, the lack of examples and tests was a real problem. It got so that only a few people could actually follow the twists and turns. This was unfortunate because there where a number of really good people like DougBTX and dagfinn who had great input but were not involved becaue it was difficult to follow after a point.

Originally Posted by Selkirk

The original poster asked should I use a PHP framework and if so, which one should I use. Let me suggest then a way to compare and evaluate PHP frameworks.

I think the only way to evaluate a framework is to look at sample applications written with that framework. The more complete the example, the better the feel one can get for the framework.

I could not agree more with this statement. Getting to some kind of apples and apples comparison is essential. I have often said that we would find out that the frameworks were more alike than different if we did this. And that would give insight into what a common codebase would be.

Originally Posted by Selkirk

I would suggest that such an application should include the following use cases:
CRUD with validation
User authentication
A Many to Many relationship
Paging a list
A mass delete/edit option
A portal style page that composes smaller units
A multiple page (wizard style) form
Alternate views of the same data (say HTML and RSS)

I was thinking of a much simpler list:
- Two pages with links that link to each other via the various common URL styles
- Paging a list
- A form with filtering, validation, and error messages
- A multiple page (wizard style) form (with features of single form)

I think something like CRUD with validation can be built from the above pieces.

User Authentication, as I think if it, is the sign-in page that sets data somewhere (session?) There then need to be clear places where access control code can be added and maybe some examples of different implementations.

A portal style page that composes smaller units, Alternate views of the same data (say HTML and RSS) are examples of View code (which I know is a big part of WACT). But there is so much variety in this area that I think some sort of supporting view controllers is a far as we should go.

A Many to Many relationship and A mass delete/edit option seem like they are part of the Model and I think that's where frameworks start biting off more than they can chew. A sub-project could deal with these.

Originally Posted by Selkirk

Perhaps a clone of del.ici.ous could be made to implement these use cases? Perhaps a scouring of hotscripts would turn up something open source that could serve as a starting point.

Perhaps too much to ask?

Originally Posted by Selkirk

One can evaluate two frameworks (or a framework versus native PHP) based on the amount of code needed to write this application.

An additional way to evaluate frameworks would be to specify a few "change cases." An example might be "Change the footer on every page to have link X." The size of the patch to the original application and the number of places that require change can help get a feel for how well the framework organizes the code. As Quaint reminds us, maintenance takes the most time.

I agree, but it is not always the amount of code needed, but the ease to implement and change. Sometimes more verbose code is better. However some of these intangables can only be learned with a lot of use and feedback, and that means a large user base, which gets us back to creating a system that many kinds of programmers can get involved with.

Originally Posted by Selkirk

The evaluation application could be specified as a set of web test cases and a native PHP reference implementation that passed the test.

I think having more or more standard framework evaluation examples such as this would help focus the efforts of various framework authors as well as allowing framework users to more directly compare frameworks.

Again, I think a set of web tests would be a brilliant way to define use cases for building and evaluating frameworks. It is not to big a task if we start modestly. There are many programmers facile with SimpleTest on this list.

Finally, I think there is a difference between a code base and a framework. I am looking for a low level, common code base from which frameworks can be built, but that enables common tools and extensions to possibly be shared between those frameworks. I am looking for easy uptake and something that creates more (I hate to use the word but) synergy for further work. You have already done several iterations with WACT and are rightly focused the high level framework problems especially with the complexities of the View.

I think we need to take the plunge, and use the code we are sharing as is - in the DI threads, I've been posting code I actually want to use, whether that helps others directly, I don't know. (It also helps that those threads have a focus on PHP4, so I don't need to defend an ideological position against type hints and declaring functions public )

The hardest part of working together on a framework is for each programmer to separate the coding style and habits they are used to from the actual needs of the implementation. I find it very hard to bend my mind around code that is very different from the style of my code. It takes a level of trust that the other developers are likewise allowing the solutions to be revealed through the process rather then imposing their habits on the design to make the process work.

PS - I do generally agree with doing things in PHP4 because besides object references, there is little different in PHP5 that is needed for non-tricky code. That's probably why PHP5 is the huge flop that it appears to be.