Yes, another framework question.

[Nick Carlson]

I've been developing with php for about 2 years now, and I've gotten to the point where I'm getting sick of reinventing the wheel with every new project I take on.

I do have some reusable code, but honestly, I need to get better at this.

So, in your opinion, what is a better road to take.

1.
I start to modularize my code more, and start using more premade classes. Basically, I'd be gathering all the tools I need from various sources, then just sticking with those.

-or-

2.
I stick my neck out and try to learn a framework, and hope it will solve some of my problems. I have to say, I've never really used a framework, but from what I've seen, they seem to be like all the CMS's out there, in the sense that they are bloated with a thousand features that I don't need.

My primary goal is to speed up the coding process. For those of you who think I should pick a framework, what would you recommend?

Please keep in mind, that I'm a commercial programmer (will code for food ), so any technology that I go with has to comply with this.

Thanks!

[Dr Livingston]

I would stick with number one. Your primary goal is to increase your development prowess and decrease your work load, so I would have to ask you if you do unit testing? If not, this will certainly be the first step to a bright, new future.

The problem with CMSs is what you've just pointed out... a) They are bloated, feature wise, and b) They may not be upto what your looking for, so at some point eventually you'll be forced to hack the CMS in question, to make it do what you want.

[That isn't software development.]

That is certainly the case with PHP at the moment, and thus is your focus language since it's the PHP forums. Other languages such as Java, Ruby, and Python are better situated I think?

Tools, the sense of what these are to me, are

PHPDocumentor, Simple Test, Creole, etc I'm sure others could add to the list. If you want modularity, what you need to do is to design first a generic module class, ie Calendar for example, so all your modules use the same Interface, and then you need a wrapper which wraps these modules.

You access your modules in that event, only via this wrapper. If at some point you find that you need to do more with the module, ie Use it in a different context, or you later move to another framework (other than your own), you do not need to modify these modules, you only modify the wrapper.

(The wrapper I believe is a Facade but I'm not too sure if that is the case, maybe Jason or Marcus could explain the Facade pattern?)

If that part makes sense? That is code re-use to me

[atu]

May you should take a look here. It's a framework based on php5. It comes with a few preinstalled modules (mysql 4.1 required) like user, navigation nodes, article,... It's simple to add or to develop your own modules with a complete other featured background. The core framework without the modules isnt bloaded (70kb) and is released under the LGPL. The main goal of this framework is to speed up the coding process in a simple way. The disadvantage is, that it is still alpha stuff.

[lastcraft]

Hi...

There are three ways to speed up your development that I've noticed comparing experienced developers to beginners.

Firstly they spend less time debugging, either because they get others to look at their code (peer review), they test (often before the code is written), but mainly because they spend longer writing clearer code. A good developer will struggle to get the name of a method or class right for example, and will refuse to write "clever" code.

Secondly they leave less code by always looking for the absolute minumum cleanest solution. They will rewrite if they find something similer and always remove the bloat from the exploration phase. As code is consumed by the brain more often than it is written, this saves time across the board. Paying developers by lines of code a day is a bad idea and very counterproductive. What happens is that the fewer reworked lines of code actually end up doing a lot more.

Thirdly they write less code by only hitting the requirements for the task. No extra features even if they are "free" (they aren't). This means showing the client something working quickly. For that matter it means showing themselves something quickly to illuminate options for further simplification. Requirements feedback is a must and a massive timesaver.

Good developers ultimately look for a very small solution to a big problem.

The use of frameworks on the other hand seems not to correlate. I guess it's a matter of personal taste. I have a hunch that developers who like learning stuff and investing in their own future will go their own way. People who want the job done effectively will gather together frameworks and libraries like a magpie. Usually this will be as separate exploration though, not introducing them afresh on a new project. Choosing the wrong framework is a bigger disaster than failing to use one.

Anyways, these are very unscientific personal observations.

yours, Marcus

[Selkirk]

The use of frameworks on the other hand seems not to correlate.

I believe that mature frameworks provide a significant productivity benefit over not using a framework. For example, writing a windows GUI application with Delphi and the VCL framework is probably an order of magnitude faster than writing directly to the windows API.

Circa 1987 I had a two volume book (Macintosh Revealed) on how to write a simple text editor for the Macintosh. It was that complicated. Today, there is Building a Text Editor in 15 Minutes. It is that simple. The difference is the framework. Text editing and structuring GUI applications are solved problems.

I don't think that structuring web applications are yet a solved problem. I see the sudden popularity of newcomer Rails as proof that the state of the art is still advancing. There are simply not yet any mature frameworks comparable to Cocoa, MFC, or the VCL available for PHP.

More thoughts on this at The value of MVC.

[Nick Carlson]

Thanks for the comments guys.

I may not need to use a framework yet.

I remember learning visual basic in school. I already had experience programming with VB, and thought I knew everything. I actually ended up getting a C in the class because my code didn't follow certain "standards & practices", as my teacher said. With the next VB class I took after that, I really learned to appreciate the use of standards. I was forced into writing uniform code, which was difficult at first. But in the end, it reduced my time to final product immensely.

That's really what I'm looking for with php. I'm looking for a standard that's followed, that I can follow, and that anyone who works on my team can follow. In tandem with this, I'm hoping for an already established code library to solve common problems. Although, I don't mind writing from scratch, or even porting some of my already written code to a standard.

The main problem I'm having with choosing a framework is that I can't find one with decent documentation. I've never used a framework in PHP, and I basically need to be hand fed until I understand whats going on.

There seem to be a lot of articles that talk about the theory of what these frameworks do, but none of them actually say "Ok, this is the code, and this is what it does, and this is why it does it."

Mabey it's just that I'm not "advanced" enough to move on to a framework yet. I hope not.

[dagfinn]

Hi...

There are three ways to speed up your development that I've noticed comparing experienced developers to beginners.

Firstly they spend less time debugging, either because they get others to look at their code (peer review), they test (often before the code is written), but mainly because they spend longer writing clearer code. A good developer will struggle to get the name of a method or class right for example, and will refuse to write "clever" code.

Secondly they leave less code by always looking for the absolute minumum cleanest solution. They will rewrite if they find something similer and always remove the bloat from the exploration phase. As code is consumed by the brain more often than it is written, this saves time across the board. Paying developers by lines of code a day is a bad idea and very counterproductive. What happens is that the fewer reworked lines of code actually end up doing a lot more.

Thirdly they write less code by only hitting the requirements for the task. No extra features even if they are "free" (they aren't). This means showing the client something working quickly. For that matter it means showing themselves something quickly to illuminate options for further simplification. Requirements feedback is a must and a massive timesaver.

Good developers ultimately look for a very small solution to a big problem.

The use of frameworks on the other hand seems not to correlate. I guess it's a matter of personal taste. I have a hunch that developers who like learning stuff and investing in their own future will go their own way. People who want the job done effectively will gather together frameworks and libraries like a magpie. Usually this will be as separate exploration though, not introducing them afresh on a new project. Choosing the wrong framework is a bigger disaster than failing to use one.

Anyways, these are very unscientific personal observations.

yours, Marcus

Here a hypothesis (unscientific): the reason for your your second observation (on frameworks) is in the first one (on simplicity). The people who make the frameworks haven't been able to keep them appropriately simple so far. And one of the reasons is that the requirements are harder to define, so it's harder to get a minimal set.

This is closely related to what I was saying recently when I revived "skeleton" thread. (Very temporarily revived, it seems.)

[arborint]

That's really what I'm looking for with php. I'm looking for a standard that's followed, that I can follow, and that anyone who works on my team can follow. In tandem with this, I'm hoping for an already established code library to solve common problems. Although, I don't mind writing from scratch, or even porting some of my already written code to a standard.

This is the desire of many including myself. I personally think that frameworks can be valuable once the target stops moving. The problem is that the web target still has a way to go. PHP is a good example of that. There were a number of frameworks maturing a year ago like like Mojavi, WACT, etc. but then things like AJAX and Rails hit and suddenly being stuck in last years Big Fancy Framework doesn't look so good.

I also agree with Marcus' outlook on development. I think the minimum development is the most responsible direction to take given the continuing fluid nature of web development. I think one of the most common conditions expressed in this forum is that programmers have their own home grown "framework" that they now clearly see needs some major improvements design-wise. But that is easier said than done. Following Marcus' direction there are fewer general lock-in decisions because all the choices were made for the immediate need rather than trying to build or squeeze into the artificial requirements of a framework.

I have repeatedly said that what PHP needs is what PEAR didn't do. That is: a set of small, clean, fully unit-tested classes that you can mix and match to build web applications, and that you can build extensions on top of. These classes really need to follow the design principles that the lastcrafts and sweatjes in our community keep beating the drum for.

I know my experience with kyberfabrikken, Ezku, Overrunner, et al. with some of the controllers was rewarding for those who were involved (and confusing to those not) and we certainly go a glimpse as many of the basic needs of web apps from a design POV. But it was also an insane design joyride with only general goals in mind. I think dagfinn has a good critique of that process.

I think a successful PHP codebase that would meet optimus prime's needs would need a bigger user base than current frameworks, so it would need to allow more of the programmer's here to utilize it. I have said before that I would dump my current code if there was something that even a third of the developers on this list were using/involved in. I know that critical mass would give what optimus prime is looking for which is a codebase "speed up the coding process". That's what they have with RoR.

But to do that you would need start with the goals, define a basic set of web application types, create a set of tests that define those apps and then evolve code to find the best solutions.

[kyberfabrikken]

That's really what I'm looking for with php. I'm looking for a standard that's followed, that I can follow, and that anyone who works on my team can follow. In tandem with this, I'm hoping for an already established code library to solve common problems. Although, I don't mind writing from scratch, or even porting some of my already written code to a standard.

PEAR may be the solution for you ?

[DougBTX]

I believe that mature frameworks provide a significant productivity benefit over not using a framework. For example, writing a windows GUI application with Delphi and the VCL framework is probably an order of magnitude faster than writing directly to the windows API.

True, but PHP isn't like C, it isn't a general purpose language. It is built for making web pages. Using a framework lets you tackle things at a higher level, PHP is already at a very high level library.

Douglas

[Selkirk]

True, but PHP isn't like C, it isn't a general purpose language. It is built for making web pages. Using a framework lets you tackle things at a higher level, PHP is already at a very high level library.

PHP's design philosophy is to be a thin wrapper around commonly available open source libraries. PHP's library of functions leave a great deal of room to tackle things at a higher level.

[Dr Livingston]

But to do that you would need start with the goals, define a basic set of web application types, create a set of tests that define those apps and then evolve code to find the best solutions.

Wasn't WACT (Web Application Component Toolkit) aimed at achieving this? I don't know yet, just how far this project has got along... Has there been a 1.0 release that was being talked about, been made public?

I think WACT has the potential of doing something, and maybe this is the area that everyone should in some manner, contribute to, instead of spending time releasing thier own YAMVC framework.

Doug,

I get the feeling Jeffs posting (above quotation) was an example, ie The difference between inmature and mature frameworks, and the difference it makes to the developers life?

[McGruff]

But to do that you would need start with the goals, define a basic set of web application types, create a set of tests that define those apps and then evolve code to find the best solutions.

Building a framework isn't easy. The big problem is that the requirements ("do anything") are just too vague. I think you'd be better off learning about agile methodologies, produce a few apps, and then come back to look at a framework with the benefit of experience.

[juls]

I think WACT has the potential of doing something, and maybe this is the area that everyone should in some manner, contribute to, instead of spending time releasing thier own YAMVC framework.

As a relative newcomer to PHP, I have a lot of questions regarding application design, controlling the flow of an application, OOP concepts, MVC, frameworks, etc. Unfortunately, there is nothing original to my confusion - all newbies experience roughly similar problems. For example, how often do people ask for advice in choosing a framework? Generally, the response they receive is a list of frameworks they can chose from... and there are many. As well meant as these responses are, a newcomer is ill equipped to make an educated choice. Wouldn't it be great if everyone could agree that framework x is a great place to start and learn from? Now, for there to be general consensus that framework x is generally a good choice, it would have to be widely supported. I might be short sighted regarding this issue, but I don't see this happening in the near future because it seems that a new framework pops up ever week. Why is this? Do all good developers disagree on what a frameworks should provide? Or do people just instinctively feel that they have to reinvent the wheel? Sure, I admit, there are many ways to skin a cat, but sometimes one technique is adequate... (ok, I acknowledge this is a bit naive...).

I agree wholeheartedly with Dr Livingston: WACT could/should be the framework that we all invest in. I have heard people sing WACT's praise over and over again, but the song always ends with the suffix, the API is still fluid, it's experimental, etc. A simple trawl of the PHP blogs reveals that WACT is a great contribution to the PHP community, but yet development efforts are still focused elsewhere. What is required to focus development effort to produce a mature and flexible framework for PHP?

[arborint]

PHP's design philosophy is to be a thin wrapper around commonly available open source libraries. PHP's library of functions leave a great deal of room to tackle things at a higher level.

I agree that frameworks are as welcom in PHP/web as they are on other platforms. I note a couple of things about your earlier comments. First that it took 10 years for Apple to get to something like Cocoa. And second, look at your Cocoa example that the first two steps in the process are not framework code related, but are framework tools related:

- Use Xcode to create a new document-based application.
- Use Interface Builder to add an NSTextView object to the application’s window.
- Add some code to the document’s controller class.
- Connect the user interface to the code.

That's why I think that PHP could benefit from a much smaller framework (than the current offerings) that could be used as a standard for tools development. A set of lean and mean controllers and the dozen support classes they need would probably be enough.

[arborint]

I agree wholeheartedly with Dr Livingston: WACT could/should be the framework that we all invest in. I have heard people sing WACT's praise over and over again, but the song always ends with the suffix, the API is still fluid, it's experimental, etc. A simple trawl of the PHP blogs reveals that WACT is a great contribution to the PHP community, but yet development efforts are still focused elsewhere. What is required to focus development effort to produce a mature and flexible framework for PHP?

I think you'd need to spin off the core WACT classes excluding the templating system and refactor it down to a clean, minimal code base. WACT would then extend this core code base to support its templating.

[lastcraft]

Hi...

That's why I think that PHP could benefit from a much smaller framework (than the current offerings) that could be used as a standard for tools development. A set of lean and mean controllers and the dozen support classes they need would probably be enough.

Sounds like Mojavi to me, except that development on that has become mired in a "second system effect".

yours, Marcus

[Dr Livingston]

What I did was to start with, was a template framework and things have evolved from there. The template framework again has went under the knife and after some refactoring, the new framework is a lot more flexible.

The original was based on XML configuration files (the structure) but that now isn't the case, the configuration files are gone. No more, are they

Now I use the same methodology (Composites) for example, to control the access to plugable modules, whereby each module can have smaller, more refinable modules themselves (their responsibilities). The smaller, more refinable modules are only every accessable from their parent module, so that's a security issue solved in just that aspect.

What is required to focus development effort to produce a mature and flexible framework for PHP?

It's down to individual needs of each developer, that is why there are so many frameworks out there. The actual needs, or requirements are not documented and thus they are duplicated, and they're all implemented differently.

If someone somewhere could make available a way to gather all these requirements, and the people who were to volunteer to start a project, could agree on the requirements, then something I think could be started.

Anyways, that what's on my mind at the moment.

[lastcraft]

Hi...

I don't think that structuring web applications are yet a solved problem. I see the sudden popularity of newcomer Rails as proof that the state of the art is still advancing. There are simply not yet any mature frameworks comparable to Cocoa, MFC, or the VCL available for PHP.

So will software evolutionists of the future think of Sitepoint as the Burgess shale?

yours, Marcus

[McGruff]

Hi...
So will software evolutionists of the future think of Sitepoint as the Burgess shale?
yours, Marcus

Great. Just 500 million years to go then.

[Selkirk]

i don't want to make this thread about WACT, but here is an assessment of the status of WACT.

First, WACT is already fairly minimal and modular. For example, the only required file is common.inc.php which sets a policy for error handling, defines a few constants and loads a small library for accessing configuration information.

One simply cannot have a framework without an error handling policy. WACT requires that all framework errors be raised by calling the RaiseError function defined in common.inc.

I've come to realize that the configuration module of WACT was a major design flaw. The components that now actively call this system should be replaced by a dependency injection based approach. This refactoring will make WACT even more modular than it is.

WACT has the beginnings of a PHP component model. Not surprising considering that component is part of the WACT acronym. Two files form the base of the component model. datasource.inc.php supports properties and callback.inc.php supports events. Both are the result of a long process of extracting appropriate functionality from running code, rather than speculative design.

The template engine is the most mature part of WACT. Unfortunately, early on, I made a design mistake in the generated code that the template compiler produces. Templates are compiled into functions, where they should have been compiled into methods. The difference is a bit technical, but the result was that WACT templates are very difficult to compose.

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 have a plan to refactor the generated code. Unfortunately, doing so is going to make every current WACT tag incorrect. Some of the complicated tags will require substantial work to convert over.

The template engine also suffers from the configuration problem mentioned before.

Some WACT template controls, namely the form and pager controls have some inappropriate code in them that really belongs in a separate controller component.

WACT has some powerful components, such as the pager and data:table. These components help to provide the productivity that one seeks in a framework, but they are built upon lots of lower level layers. Components like this provide much of the productivity boost that is possible with a framework. WACT has one more major productivity component, data:form, that remains to be written.

The API for writing template components in WACT has been a moving target and writing tags is much harder than it should be. Searching the WACT mailing list will show a post called "Tag authoring simplification project." I believe that the items on that list, converting from config to DI, and converting from functions to methods in the compiled code are necessary to achieve a stable API for developing WACT tag components.

The controllers have been one of the most volatile areas of WACT. They are the result of years of refactoring and removing duplicate code from a set of working web applications. By doing this and studying other frameworks, i've come up with a set of design principles for the controllers:

1. Hierarchical, compose-able organization.
2. REST style individually addressable components.
3. Declarative input.
4. Event driven.
5. Support for a sequence of HTTP requests.
6. MVC separation.

The hangman example is a proof of concept of these design principles.

I've been using several use cases to evaluate controllers.

• A simple CRUD application
• Multiple forms on a page
• Multiple page forms
• Arrays of controls
• Composable fragments (portal style)

WACT does not support anything beyond CRUD at this point, leading to a productivity cliff for the other cases. I believe that the new controller architecture can support all of these use cases well.

You can also see how the composability problems in the template cause problems for the composable requirement of the controllers.

The old form components do not support the new controller architecture. Unfortunately for the new controllers to support forms, the form controls must be re-written. A non-trivial task.

I am very optimistic about the new controller architecture.

The Model components of WACT are mostly placeholders for future work. WACT needs stronger introspection capabilities in the model layer in order to support the order of magnitude gains that I was talking about at the beginning of this thread. More on that in my post comparing WACT and Rails.

So a recap of the major things WACT needs to reach maturity, stability, and that productivity big bang:

• Support for the form use cases
• Composable templates
• Dependency injection based configuration
• Introspective model
• ORM Code generator
• data:form component

These are non-trivial things to do.

Unfortunately, few people are willing or able to take on some of the refactoring tasks and its hard to communicate the vision of things that don't yet exist, so progress is slow.

WACT is steadily if slowly marching towards becoming a mature framework. At the current rate, 500 million years sounds just about right.

What WACT needs most is just one more capable programmer that shares the vision and is willing to make a substantial, long term and continuous commitment to the project, and who is willing to do mundane, difficult, or unsexy tasks in order to help bring WACT to 1.0.

[McGruff]

WACT is steadily if slowly marching towards becoming a mature framework. At the current rate, 500 million years sounds just about right.

Sorry - that wasn't aimed at anyone in particular. WACT is about the only framework I take seriously. Unit-tested php code is hard to come by.

[arborint]

i don't want to make this thread about WACT, but here is an assessment of the status of WACT.

I don't think this is about WACT, but I think WACT is a good example of the problems with PHP frameworks because it is so good, so close and yet so far. You wrote far too much to comment on and I understand where you are coming from.

First, WACT is already fairly minimal and modular. For example, the only required file is common.inc.php which sets a policy for error handling, defines a few constants and loads a small library for accessing configuration information.

One simply cannot have a framework without an error handling policy. WACT requires that all framework errors be raised by calling the RaiseError function defined in common.inc.

I think it is not evenly modular. Nor is the unit test coverage very good (though still better that most anything else). The main reason that I don't use WACT is that there is too much code in the core to support the WACT templating. And a glance at common.inc.php by most programmers will confirm that how WACT does things is more complex and specific than you think it is. The barrier of entry has always been higher that you consider it to be.

What WACT needs most is just one more capable programmer that shares the vision and is willing to make a substantial, long term and continuous commitment to the project, and who is willing to do mundane, difficult, or unsexy tasks in order to help bring WACT to 1.0.

My recommendation was to spin off the core classes because I believe that is the only way that more programmers will get involved. You could still develop the WACT framework on top of the core (and influence it's design) and you would be free of much of the mundane, difficult, or unsexy tasks.

[Selkirk]

My recommendation was to spin off the core classes because I believe that is the only way that more programmers will get involved.

I agree with you.

We talked some on the mailing list about breaking WACT up into modules and using a PEAR channel to distribute them.

I have no problem making any changes to the framework necessary to do this. Other than getting rid of the mandatory config stuff, there are few changes required.

Unfortunately, I don't have a lot of time to spare right now to set up the the infrastructure for this.

[arborint]

I agree with you.

We talked some on the mailing list about breaking WACT up into modules and using a PEAR channel to distribute them.

I have no problem making any changes to the framework necessary to do this. Other than getting rid of the mandatory config stuff, there are few changes required.

Unfortunately, I don't have a lot of time to spare right now to set up the the infrastructure for this.

I know I would be interested in getting involved (and I think others would too, such as those from the skeleton thread) if I knew more about the makeup of the modules. As I have said before, I would gladly abandon my current code if I though there was a code base that would actually have broad support.

Is there somewhere where read more about this or can you summarize the discussion about breaking WACT up into modules.