SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 55

Thread: which framework

  1. #1
    SitePoint Member
    Join Date
    May 2006
    Location
    India
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up which framework

    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

  2. #2
    Web-coding NINJA! silver trophy beetle's Avatar
    Join Date
    Jul 2002
    Location
    Dallas, TX
    Posts
    2,900
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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!
    beetle a.k.a. Peter Bailey
    blogs: php | prophp | security | design | zen | software
    refs: dhtml | gecko | prototype | phpdocs | unicode | charsets
    tools: ide | ftp | regex | ffdev




  3. #3
    SitePoint Enthusiast NativeMind's Avatar
    Join Date
    Aug 2003
    Location
    USA
    Posts
    80
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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!

  4. #4
    SitePoint Member h3rald's Avatar
    Join Date
    Feb 2005
    Location
    Italy
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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"...
    -- h3raLd
    www.H3RALD.com

  5. #5
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  6. #6
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Australia
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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)

  7. #7
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @kyberfabrikken,wei

    Good points both. Nicely put.
    There’s more than one way to skin a cat.

  8. #8
    SitePoint Zealot jadmadi's Avatar
    Join Date
    Sep 2003
    Location
    Jordan
    Posts
    154
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I prefer to go with CodeIgniter as it's not a code generator and it force you to organise your work

  9. #9
    SitePoint Enthusiast
    Join Date
    Apr 2006
    Posts
    30
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jadmadi
    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...

  10. #10
    SitePoint Evangelist jplush76's Avatar
    Join Date
    Nov 2003
    Location
    Los Angeles, CA
    Posts
    460
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    My-Bic - Easiest AJAX/PHP Framework Around
    Now Debug PHP scripts with Firebug!

  11. #11
    SitePoint Enthusiast
    Join Date
    Jul 2004
    Posts
    43
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    another framework

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

    thanks a lot.

  12. #12
    SitePoint Member
    Join Date
    Mar 2006
    Posts
    22
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "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.

  13. #13
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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.
    On the other hand, would you hire a developer who thought that a static registry class was a good thing?

  14. #14
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ahundiak
    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.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  15. #15
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > 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.

  16. #16
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    right of passage
    Rite. Yes, really.

  17. #17
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Write you are Ezku.
    Hello World

  18. #18
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    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.

  19. #19
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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.
    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.

  20. #20
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    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.

  21. #21
    SitePoint Member
    Join Date
    Sep 2003
    Location
    Brazil
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by kyberfabrikken
    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. ;-)

  22. #22
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  23. #23
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    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).
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  24. #24
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    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
    Hello World

  25. #25
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •