which framework

[deeppak]

Since i am a new bee to PHP just six months old and learning day by day in the same flow i just wanted to know which framework should i pick.

It should be simple as well as easy to implement and tries to cover up all the required things which are regularly in use by the programmers.

What comes to mind is PEAR is it OK to start with pear since as i have already stated that i was undergoing the user authentication system should i pick its PEAR::Auth or some other available frame work is available or some open source application is available.

And let me know some link where i can understand pear in the best way lets say PEAR in practical lets say sample project in pear.

Some where i came across that pear is really confusing so should i go for some other framework.
Hey if ever go for a frame work which is the best i know there are sometimes problems in implementing them even then sometimes for completion of work in time or meeting targets is possible through a framework only.One more thing when i will have to prove my versatility to some one lets say for an interview it will be better to have some knowledge of frameworks..hat are the frameworks which adds some value to my resume and what open source projects should i include so that it satisfies the other person..
What is up in market means more demanding ..

i want the answer from all the techies in this forum if possible


Thanks,
Deeppak
deepak_gupta_hello@yahoo.com

[beetle]

Well, first of all you need to understand that PEAR isn't actually a framework - not in the traditional sense. It's much too large to be a framework, although it pretty much contains everything a framework normally does. But PEAR is mostly a collection of abstract components.

The guys over at WACT (many of whom are sitepointers) have a nice list of MVC frameworks on their site (http://www.phpwact.org/php/mvc_frameworks)

It's pretty comprehensive, but not complete. For example, I know of WASP which doesn't seem to be listed there (http://wasp.sourceforge.net/content/).

Do I have a recommendation? Unfortunately no. I haven't yet used any of these in sufficient quantity to feel I can endorse one over another.

Happy coding!

[NativeMind]

I recommend Mojavi http://www.mojavi.org -- it has all of the MVC design pattern and does not force you into specifics for rendering (e.g. use Smarty or something else) or how you define your model (use a database, use web services, it's up to you).

Enjoy!

[h3rald]

Personally I'd recommend CakePHP. I've been using it for about eight months now, after trying other frameworks, and that was the only one I could stick with: it's simple to learn, intuitive and powerful.

I didn't really like Prado's event-driven approach, it's interesting but definitely has a steeper learning curve and I prefer MVC frameworks.

I recently wrote a comparative review of six "Rails-inspired PHP frameworks"...

[kyberfabrikken]

PEAR is quite different from the other frameworks mentioned here. There seems to be two related framework trends going on at the moment. They both label themselves frameworks, but they mean slightly different things by that term.

On one hand you have the full stack frameworks. Theese could also be called RAD frameworks, because they allow the programmer to quickly, almost without any real pogramming invloved, create an application. The idea is to create a rich enviroment of commonly used components. This makes it easy to produce a complex application in very short time, as long as the requirements for this application are trivial. In most projects, there will be a large ammount which is trivial and a smaller ammount which is not. The RAD frameworks allow the programmer to focus on the smaller non-trivial parts by automating the trivial.

RAD frameworks tend to be very monolithic. Although you may replace components or override default behaviour, this tends to be an expert task, which presuppose an in depth understanding of the frameworks internals.

The RAD frameworks have largely been inspired by the hype surrounding RoR, and as a result hereof mimics it. PRADO also belongs in this crowd, but rather than mimicing RoR, it mimics ASP.NET.

On the other side of the fence, you have the component based frameworks, which are looser coupled collections of libraries, that can be mixed and matched to produce the final application. They may have some degree of infrastructure, which makes it easier to integrate the components with each other, but they don't impose an overall architecture for your application. This gives you more freedom, but also force you to do more work yourself. PEAR belongs here, but recently ezComponents and to some degree the Zend Framework have appeared as well.

As a kind of in-between form, there are some frameworks which focus specifically on providing a structure for bridging the gap between procedural page controllers (the native php platform) and an object oriented application structure through a front controller. Theese tend to follow the MVC architecture, whatever that means (there's a lot of interpretations of that). Some of theese MVC frameworks grow in size, and become RAD's (as in the case of Mojavi and Symfony).

RAD's are getting a lot of positive attention at the moment, but the hype mean that people overlook the backside of the medal. PHP's success has a lot to do with the direct interaction with the http request. RAD's put abstractions on top of this, which may make some tasks easier, but also limits your options as a programmer. If the abstractions match your problem domain and your way of thinking, that's fine, but don't close your eyes for the hidden cost.

[wei]

I think designs like Java Server Faces, ASP.NET and Prado (may be others like WACT) belong to the camp of components and events (here components are in terms of the component model for user interfaces, authentication & authoriazation).

The Rails and its derivatives, and others like symphony belong to a different style camp, one which that is more traditional for php. One of the difference between these two camps are how their views are designed, e.g. http://www.phpwact.org/pattern/template_view, one is more scripting style, the other are custom components.

Each framework is design to solve a particular set of problems and must be evaluated as such with their advantages/disadvantages and how they can help to solve your problem. Frameworks will force, to what extent depends on framework, the way you design your application. Using a particular framework usually means you need to invest resources (time, people) to learn it. Frameworks will usually have made some design choices in terms of your application design (and you should find out what these are). So for a particular project, the framework choice must be considered carefully. You do not want to change the use of a framework pass the initial stage of a project (that may be an argument to use less structured frameworks).

As kyberfabrikken points out, RAD usually means less control for you as a trade off for possibily quicker returns.

framework = components + patterns (PDF file)

[nacho]

@kyberfabrikken,wei

Good points both. Nicely put.

[jadmadi]

I prefer to go with CodeIgniter as it's not a code generator and it force you to organise your work

[pestilence_gr]

I prefer to go with CodeIgniter as it's not a code generator and it force you to organise your work

+1000 i love the ingiter, simplistick it doesn't trouble you to understand it...

[jplush76]

If you want to make yourself valuable in the PHP job market start getting up to speed on the "zend framework" which will be the defacto framework for PHP once it matures it's featureset.

you can't argue the points that it will be maintained by some of the leaders in the PHP community and being backed by companies like IBM isn't half bad either.

[ualex]

there is http://framework.zend.com that is very good.

thanks a lot.

[aranworld]

"which will be the defacto framework for PHP once it matures it's featureset."

I don't mean to be cynical here, but when I hear things like "X will be incredible as soon as Y is accomplished" all the little warning flags on my desk start going off.

I think anyone familiar with the way things go in the computer industry, would have to agree that there is probably a greater than 50% chance that the Zend framework will NOT become any sort of defacto anything.

How many times have we seen something start off with all the best intentions with a lot of positive hype, but only die a horrible death a couple years into its lifespan.

The fact is that the Zend Framework is extremely basic at this point. We really have no way of knowing at all if this beautiful simple framework will wind up becoming some sort of bloated mess once it starts getting fully fleshed out. Yes, it has a great pedigree, but great pedigrees have not stopped things from getting messed up in the past.

I think for a high level developer Zend is an interesting project to follow, but for someone just starting out who is looking for a framework that works RIGHT NOW, Zend is probably something that is better left for later.

Anyways, when/if Zend becomes the defacto framework, there will likely be oodles of books providing tutorials that will help you get a quick start on it. At least that is when I plan on getting involved.

[ahundiak]

If you want to make yourself valuable in the PHP job market start getting up to speed on the "zend framework" which will be the defacto framework for PHP once it matures it's featureset.

you can't argue the points that it will be maintained by some of the leaders in the PHP community and being backed by companies like IBM isn't half bad either.

On the other hand, would you hire a developer who thought that a static registry class was a good thing?

[dagfinn]

On the other hand, would you hire a developer who thought that a static registry class was a good thing?

"On the third hand", anyone who understands the phrase "static registry class" is a lot more knowledgable about design than the average PHP freak.

[Dr Livingston]

> The fact is that the Zend Framework is extremely basic at this point.

Considering that the amount of effort required to manage the red tape at the level that Zend are moving towards, in business terms, it's a pleasant surprise with the amount of community based involvement that Zend and their framework has managed to accumalte - in such a short space of time.

So, if they have come this far in 3 months, imagine where they're going in 9 months time, and yes the Zend framework will (proberly) be the basic requirement to gain employment in the not too distant future for a lot of people.

Consider that having knowledge of Zends framework will be some form of right of passage in some circles. That is how I look at it anyways

> At least that is when I plan on getting involved.

If you get involved right now, you can help make history.

[Ezku]

right of passage

Rite. Yes, really.

[DougBTX]

Write you are Ezku.

[ahundiak]

Zend Framework is a good start but I think it would be considerably better if it started using objects. Static registry, static logs, static validations, heck they even designed a static http Request class and that's not easy.

And when they absolutely can't figure out how to make something work with static methods then they start sprinkling private and final keywords everywhere. Almost like they really don't want you extending their classes.

[33degrees]

Zend Framework is a good start but I think it would be considerably better if it started using objects. Static registry, static logs, static validations, heck they even designed a static http Request class and that's not easy.

I think part of the reason for that is their "component" approach. In a full stack framework, much of the wiring together of objects is taken care of for you, wereas with the component approach zend has gone for, the end user has to do it himself. Using static calls means you don't have to worry about creating objects and passing them around, making things simpler for the developper, which is one of their stated goals. It remains to be see if the advantages of this approach will outweigh it's disadvantages in the long run.

[kyberfabrikken]

Using static calls means you don't have to worry about creating objects and passing them around, making things simpler for the developper, which is one of their stated goals.

If you're right (and you might just be), I think zend should seriously reconsider. If they mean to write procedural code, why don't they? There's no point in using classes to pretend you code is object oriented, when it's not.

[moraes]

Off Topic:

There's no point in using classes to pretend you code is object oriented, when it's not.

Oh, this is not true. Although there is a lot of static methods in Zend Framework, there's a lot of use of OO and patterns also, but they are not specified in the docs yet (the new RewriteRouter, for example). Zend wants to make it usable by the average PHP coder which is not used to OO, and also to make it as modular as possible. So it is a natural choice to build an API full of static methods, but be sure that there is room for other uses. And based on their purposes, they are doing a pretty nice job. Yeah, I believe in this "ZF will be the defacto" rumor. ;-)

[kyberfabrikken]

I'm not saying that you can't mix OO and procedural - PHP works fine that way. I'm saying that when you're using procedural design, you should express it with procedural syntax - not with classes. Or did you mean that some of the static classes can also be instantiated and used as objects, if that's what I want ?

I can see the need for namespaces in procedural code (in particular, but also in OO code for that matter), but using classes as namespaces is just plain out wrong.

[dagfinn]

I can see the need for namespaces in procedural code (in particular, but also in OO code for that matter), but using classes as namespaces is just plain out wrong.

Why? It doesn't seem wrong to me, perhaps because I used to do Perl. In Perl, there's no class concept, just "packages" which may act as classes or as collections of procedural functions (or as higher-order namespaces, since they can be nested).

[DougBTX]

using classes as namespaces is just plain out wrong.

Naming Conventions

The Zend Framework employs a class naming convention whereby the names of the classes directly map to the directories in which they are stored. The root level directory of the Zend Framework is the "Zend/" directory, under which all classes are stored hierarchially.

... the filename "Zend/Db/Table.php" must map to the class name "Zend_Db_Table"

Classes are not just namespaces, they are nestled namespaces

Douglas

[ahundiak]

Or did you mean that some of the static classes can also be instantiated and used as objects, if that's what I want ?

No you can't instantiate these classes. In fact, in the case of the Registry class they didn't even put the methods in their own class but rather mixed them in with their base Zend class.

What you can do is to wrap the static methods with an object. So I wrote my own little service locator class which also stores a copy of the created objects in the static registry. So for my own code I can just pass the locator around while still maintaining some compatiblety with the rest of the frame work.

Bit of a hack though.