SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 97
  1. #26
    SitePoint Member
    Join Date
    Jan 2005
    Location
    Brisbane, Australia
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I thought I'd compare the code between the two frameworks after blueyon's comment about the number of files in Zend_Cache and to be honest I don't think you know what your talking about.

    With Zend_Cache, 12 of those 16 files are implementing various backends (File, APC, Memcache etc). With Code Ignitor, it has a simple file based cache embedded into the output handling class for the controller.

    There is no comparison really.

    Zend Cache can be used as a individual component or as part of the framework.
    CI Cache cannot.

    Zend Cache can support muliple backends really easily because of the strategy pattern it uses (a good choice in this instance).
    CI Cache is limited to a single file backend.

    Sure there is a number of files, but that has nothing to do with "bloat".
    You don't see Zend Cache loading every single backend for every request do you?
    No.

    With a PHP accelerator the number of files doesn't even matter as they are precompiled and stored in shared memory.

    Now this isn't a dig on CI, I just have a problem with using file counts as a metric for bloat. CI's goal is totally different to ZF.

    CI is a very specific framework that requires you to work within the boundaries it sets because it is extracted from ExpressionEngine. ZF is a collection of libraries that can be used together or seperately while still supporting a number of backends. This means code must be modular and the structure needs to be loosely coupled. Seperating unrelated code into seperate files is the way to go.

  2. #27
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Look I know what your saying when you say you have not just file cache but meme cache etc..

    So if done properly you should have these classes:

    Cache
    CacheFile
    CacheMem
    CacheAPC

    The main cache file will use the other cache classes as adaptors.

    Theres not need to split it into frontend and backend.

    parts like:

    class Zend_Cache_Frontend_Class extends Zend_Cache_Core

    is useless.

  3. #28
    SitePoint Enthusiast
    Join Date
    Jun 2009
    Location
    Brisbane, Australia
    Posts
    30
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blueyon View Post
    Look I know what your saying when you say you have not just file cache but meme cache etc..

    So if done properly you should have these classes:

    Cache
    CacheFile
    CacheMem
    CacheAPC

    The main cache file will use the other cache classes as adaptors.

    Theres not need to split it into frontend and backend.

    parts like:

    class Zend_Cache_Frontend_Class extends Zend_Cache_Core

    is useless.
    If you understand how separating each backend adapter into a separate class/file is logical. How do you not recognize the advantage of separating each cache frontend into a separate class/file?

    Following your logic, we should just combine every class into a single file.. better yet, forget using PHPs flawed object interpretation, let's just roll with a single standalone file of procedural drivel. The end product is the same as Zend Framework and I'll never have to wade my way through the filesystem to find that damned Zend_View_Helper_Placeholder_Container_Abstract class again...

  4. #29
    SitePoint Guru
    Join Date
    Mar 2006
    Posts
    701
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    These days I saw file helper code of CI.
    This and I thing all the helpers are not classes, it is a file with functions,so you can not extend file helper as Yii (just the framework I used) file class can do (and I did that).
    If you want to add to file helper code you may thing add the function to this file or make another seperate class.
    I am just asking,what are your opinion from the OOP view for this?
    Dimis

  5. #30
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Look it does not have to be code ingiter to compare ZF againest. There are so many better ways of coding than the way ZF does things.

  6. #31
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Your claim about ZF bloat is nonsense. Just because 14 files exist does NOT mean they are all used every time. As someone else said, I'd rather work with 10 files of 100 lines of code, rather than 1 file with 1000 lines of code. The separation of responsibilities in files is a terrific practice to follow, and as such makes the framework much more extensible. I don't know why you're hellbent on ripping apart ZF, but fanboy-ism is a terrible quality to have. If you prefer codeigniter, go ahead and use it - but don't start spreading false information about other frameworks on a forum that is meant to HELP developers. By doing so you're only making life harder for someone who's trying to learn.

  7. #32
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Arrrms View Post
    Your claim about ZF bloat is nonsense. Just because 14 files exist does NOT mean they are all used every time. As someone else said, I'd rather work with 10 files of 100 lines of code, rather than 1 file with 1000 lines of code. The separation of responsibilities in files is a terrific practice to follow, and as such makes the framework much more extensible. I don't know why you're hellbent on ripping apart ZF, but fanboy-ism is a terrible quality to have. If you prefer codeigniter, go ahead and use it - but don't start spreading false information about other frameworks on a forum that is meant to HELP developers. By doing so you're only making life harder for someone who's trying to learn.

    "The separation of responsibilities in files is a terrific practice to follow, and as such makes the framework much more extensible."

    yes well done you idot! I never said this was bad practise. But again you point out something that ever other framework does!

    ZF does not have speration responsibilities as it still uses forces you to use the ZF error, db, and logging classes.

    I'm not a code igniter fan boy. I use my own framework of light weight classes.

    My information is not false as ZF encourages bad practises. it is the mosted bloated framework out there. Again take the it takes 40 files for a controller.

    You need 40 files, just 1.

    People want to learn a framework? learn one that does not have such a big foot print and forces you to include many uneeded files and libraries.

    you might as well learn more php than have to learn the api for zend framework to work.

    I just can not be bothered at the moment to write a cache class that can use files and mem cache just to prove a point.

    Take a look at Joomla framework as well. Hell that does things a lot better then ZF.

  8. #33
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Rather than getting defensive and even more childish, think before you write. You seem to acknowledge that all frameworks separate responsibilities amongst files, yet you criticize ZF for doing that even though you don't need to use ALL the files. You seem to be very ignorant of OOP practices, otherwise you would understand the benefit that this gives you. Your posts have been nothing but drivel and you've failed to address the points that other people have been making in this thread. Quit with the fanboy-ism/trolling, it's not helping your case.

  9. #34
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No idiots here, please.

  10. #35
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    First off I'm not arguing about OOP practises.

    I'm arguing how ZF implements them. When you make these sort of replies it seems to me that you only know ZF and don't know other frameworks use best pratises aswell.

    My argment is that you can do the same job that ZF does with a lot less files and a lot less coding using design patterns the correct way.

    It seems to me you don't know any other framework. Try looking at Kohana. It does a few things I don't like but it still achieves the same job and does things better than ZF.

    If I was wrong then why is ZF such a bottle neck when optimizing sites?

  11. #36
    SitePoint Member
    Join Date
    Oct 2009
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blueyon View Post
    First off I'm not arguing about OOP practises.

    I'm arguing how ZF implements them. When you make these sort of replies it seems to me that you only know ZF and don't know other frameworks use best pratises aswell.

    My argment is that you can do the same job that ZF does with a lot less files and a lot less coding using design patterns the correct way.

    It seems to me you don't know any other framework. Try looking at Kohana. It does a few things I don't like but it still achieves the same job and does things better than ZF.

    If I was wrong then why is ZF such a bottle neck when optimizing sites?
    If codeignitor is what works for you and not zend then go ahead and use codeignitor and don't go making baseless claims against the zend framework in forums.

  12. #37
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    blueyon, think about it this way: codeigniter (or any other small framework) will work great for you as long as you program according to their conventions. this is what allows them to have less files for the same or similar process as ZF. but once you try to deviate from their path, and want to do things your way, you're going to wish the framework was more easily modifiable / extensible. That's where the multiple files comes in handy. You get so many more points of access to tap in to. Don't like a specific part of ZF's cache class? Extend the subclass that handles that part of the functionality and rewrite what you want. Yes, it's possible to do this with single class files too, but you know it's not going to be as easy. if you're going to claim that ZF bottlenecks sites, then provide some cold hard numbers - otherwise your claim is baseless and it's hard to take anything you say seriously. Is ZF slower than some of the smaller frameworks? Maybe, maybe not. (I've heard CakePHP is the slowest). Is it slow enough to warrant not using it? Nope. If it was, then no one would use it. Throw in the option for PHP accelerators and framework performance almost becomes a moot point.

    I personally don't care what framework you use, and your comments certainly aren't going to change which framework I use, but don't throw baseless claims around as facts because you're only doing a disservice to people who read your posts and come back with false information.

  13. #38
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayrulez View Post
    If codeignitor is what works for you and not zend then go ahead and use codeignitor and don't go making baseless claims against the zend framework in forums.
    none are baseless as I have been explaining in this thread.

    there is seriously something wrong with some of the people here that are pushing for ZF.

    40+ files for a controller? is just stupied coding.

    Design patterns have been around since the 60's. ZF did not invent design patterns nor are they the first to use design patterns in a PHP framework.

    I'm not pushing for dumping everything into one file. As you just don't get what I'm saying!

    Example of a small light weight cache adaptor class and a file class:

    PHP Code:
    <?php
    final class Cache 
          public function 
    __construct($driver) {
            if (
    file_exists(DIR_DRIVER 'cache/' $driver '.php')) {
                require_once(
    DIR_DRIVER 'cache/' $driver '.php');
            } else {
                exit(
    'Error: Could not load cache driver ' $driver '!');
            }
                    
            
    $this->driver = new $driver();
          }

        public function 
    get($key) {
            return 
    $this->driver->get($key);
          }

          public function 
    set($key$value) {
            return 
    $this->driver->set($key$value);
          }
        
          public function 
    delete($key) {
            
    $this->driver->delete($key);
          }
    }

    final class 
    CacheFile 
        private 
    $expire 3600

          public function 
    __construct() {
            
    $files glob(DIR_CACHE 'cache.*');
            
            if (
    $files) {
                foreach (
    $files as $file) {
                    
    $time substr(strrchr($file'.'), 1);

                      if (
    $time time()) {
                        
    unlink($file);
                      }
                }
            }
          }

        public function 
    get($key) {
            
    $files glob(DIR_CACHE 'cache.' $key '.*');
            
            if (
    $files) {
                foreach (
    $files as $file) {
                      
    $handle fopen($file'r');
                      
    $cache fread($handlefilesize($file));
          
                      
    fclose($handle);

                      return 
    unserialize($cache);
                    }
            }
          }

          public function 
    set($key$value) {
            
    $this->delete($key);
            
            
    $file DIR_CACHE 'cache.' $key '.' . (time() + $this->expire);
            
            
    $handle fopen($file'w');

            
    fwrite($handleserialize($value));
            
            
    fclose($handle);
          }
        
          public function 
    delete($key) {
            
    $files glob(DIR_CACHE 'cache.' $key '.*');
            
            if (
    $files) {
                foreach (
    $files as $file) {
                      
    unlink($file);
                }
            }
          }
    }
    ?>
    What's wrong with doing it similar to this?

  14. #39
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    edit: This is a pointless argument, I regret ever getting involved in it.

  15. #40
    SitePoint Member
    Join Date
    Oct 2009
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Arrrms View Post
    edit: This is a pointless argument, I regret ever getting involved in it.
    Ditto. It's like talking to a brick wall. If the guy is so hell bent on not using zend then he should just not use it, don't go trolling forums trying to get people to see things from his perspective.

  16. #41
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You are wrong.

    The benchmarks for ZF speak for themselves!

    Other here agree with me aswell.

  17. #42
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blueyon View Post
    there is seriously something wrong with some of the people here that are pushing for ZF.
    There's not: it's you. I think you should tone it down a little, instead of calling people idiots. This is not a way to discuss a framework. I don't know what you're trying to accomplish with this topic, but I think this is not the way to achieve it. Look, I dislike the Zend Framework myself, and I have my arguments to do so. It's growing too fast for my puny brain to keep up with, to name one.

    Quote Originally Posted by blueyon View Post
    40+ files for a controller? is just stupied coding.
    You're bashing with incorrect, false and inaccurate statements. Yes, 40+ files for a controller is a lot to grok, but it's not the 40+ files that make it bad. You could do it with three files, but you wouldn't be able to have the same flexibility that the Zend Framework provides. You can scream at it all you like, but having more than forty files denotes (too?) extreme flexibility, not stupid coding like you seem to think. The number of files is not a way to judge the quality of code, the code itself does.

    Quote Originally Posted by blueyon View Post
    I'm not pushing for dumping everything into one file. As you just don't get what I'm saying!
    We don't get what you're saying because what you are saying isn't true. There is no relation between the number of files in a framework and the quality of the code in those files. The Zend Framework is a crowd pleaser: it tries to do everything for everyone. Me personally? I think that can never be achieved: I like the concept of small frameworks, which you can comprehend in a matter of hours rather than days. If there is a specific need the framework doesn't do for you: tough luck, go and make it yourself, maybe share it somewhere, but keep the framework base small and lean. I suspect you have same feelings I do, and you're simply not expressing yourself in a very friendly or fortunate way.

    I think this is actually an interesting observation nonetheless: the level of reuse in the Zend Framework has got too high for it to be easily comprehensible. By reusing the code from everybody's requirements, the code base is bloody huge and so is the manual. There are tons of things in the Zend Framework I wouldn't use for the life of me, but their mere presence makes it hard for me to understand what it is really about. There are so many options, there's so much flexibility, that I just don't remember what I should do to achieve a certain thing I want to achieve. We Dutchmen have a saying that you can't see the forest because of the trees in the way, and Damien Rice also had an excellent line to express the feeling I have whenever I think of the Zend Framework: "too many options may kill a man".

    I'm too stupid, maybe. I'm overwhelmed by the sheer number of lines of code, I'm flabbergasted by all of the options in the documentation: I can't find what I have to do to use the flexibility it provides. This does not mean the code is bad, just that it is too much code for me to comprehend. On that note: the API documentation of the latest and greatest version (1.9 at the time of writing), which is compressed in a .tar.gz file, is still 6 Mb. That's not to say that the documentation is bad; quite the contrary. I'm just saying it's too much code and documentation to find what I am looking for within reasonable time.

    It think the Zend Framework has, or soon will, fail in it's quest to be useful, because it's trying to be useful too much. This might sound contradictory, and it is, but there's logic behind it. The Zend Framework tries to be useful for any PHP programmer and their dogs, and in doing so it becomes increasingly difficult to understand and thus increasingly difficult to use. It's a noble cause, but I think it's been going the wrong way since the moment they decided they wanted to please everyone.

    It is my personal opinion that a framework should be easy to comprehend and easy to use. Code Igniter does a wonderful job at that: it's user guide tells you everything the framework will do for you, in a matter of a single page. It won't do anything else for you, but that makes it that much easier to comprehend. However, I also think a framework should be extend-able: you should be able to alter the behavior of the framework classes, without having to change the code of the framework itself. This is a concept well known and quite old, namely the Open Closed Principle. If you don't like how the framework does things by default, just write a class that implements a certain interface and plug that in, instead of the frameworks' default object. I am not the only one who thinks of frameworks like this. The Zend Framework seems to integrate too much, if you ask me, which makes it's API's cluttered.

    The extendability is where Code Igniter fails... miserably. I've used Code Igniter in the past and simply by looking at it's source, it becomes very apparent that OO best practices such as favoring composition over inheritance are simply ignored. Worse yet, the last time I looked, every time that a method was to be reused, the class with that method was extended upon. This, as we all know, is not the way to write flexible code.

    There are more things that bug me about the Zend Framework, apart from it's rapidly growing complexity. It's also the fact that you are unable to test two out of three layers, and it doesn't adhere to best practises all the time. Of course it doesn't. You must have really strict Quality Assurance to make sure that you get only code that follows best practises all of the time. But simple things like keeping your method body small are ignored by Zend Framework just as well: the +dispatch( ) method of Zend_Controller_Front, for example, has a body of 148 lines of code that aren't easy to read (for me, anyway). Also I find that the unneeded use of static methods is daunting, and I disagree with the implementation of Model View Controller. These things, however, are not enough reason for me not to use it. The fact that I have to learn new things and invest a heck of a lot of time every time I use it, is a reason for me not to use it.

    I do still use it, by the way, so this opinion is based on real-world usage. I've found that it was the best framework to use for our specific team, because almost everyone already knew the Zend Framework. I had used it before too, so I already invested a lot of time to learn the framework, so I know how to do most of the basic (or generic) stuff. When I'm trying to do something I haven't done before, I get into trouble. Last weekend, for example, I wanted to add a route to route some requests to a specific controller and action, so I didn't need to put parameters in the URL. I wanted to do this in an INI file, and not in code, so as to keep the dispatching code a little cleaner. This took me about half an hour, and involved asking two co-workers. I've been reading the manual, trying to figure it out on my own, but it took me too long for it to be called "simple to use".

    That's my fault, perhaps. I'm stupid, I guess. I need to be able to see an example of how the framework works, see if there's an alternative way available, and when I don't like it, I want to be able to whip up my own way of doing things and read the manual on how to plug it in, or even better: read the code on how to do that. What I don't want to do is see what a component does, and spit through thirty-something implementations that are delivered with the framework, all with separate ways of working and configuration.

    I think this discussion is heading the wrong way because of the different definitions we have for the word "bloat". I see stuff like benchmarking and "you don't load what you don't use" coming up in every reply. That's not my definition of bloat: I would argue that the definition of bloat is that you have too much classes and too many ways to accomplish one thing, which inevitably will "clutter" the framework, and it's ease of use. It's the sheer volume of the information you need to get it to work, the sheer time investment you have to make to understand what's going on and the lack of simplicity that I would call bloated.

    Too many options may kill a man.
    Last edited by webaddictz; Oct 13, 2009 at 04:43. Reason: spelling.
    Yes, I blog, too.

  18. #43
    SitePoint Zealot romance's Avatar
    Join Date
    Apr 2004
    Location
    UK
    Posts
    181
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Very well written and well reasoned response webaddictz, and I agree with some of the points you made in regards to the 'multiple ways to do the same thing' approach that ZF uses (and promotes?).

    Part of the issue of this code 'bloat' is that people compare ZF to full-stack frameworks such as cake, CI etc when Zf is much more a glue framework or library.

    A lot of the articles online never differentiate between these, so a new user coming along assumes that all frameworks are created (roughly) equal and so checks out the standard 'make a blog in 20 mins' type tutorials for each of the frameworks. Looking at the ZF ones you'll end up with multiple versions all implemented in different ways, with a (perceived ) larger overhead in regards to setting up bootstrapping, action helpers etc which the other framework tutorials never mention.

    I'm on the fence over whether this approach helps or hinders ZF's future. I've worked on different ZF projects, all setup using different methods and so there was already a wall I had to breach in regards to learning why things were done the way they were and addressing any shortcomings. A prime example of this is ACL/checking the right user is accessing the right resource. This can be added via an action helper, in the predispatch process, implementing a custom method in an extended controller, moving the ACL to a model, including the ACL as a library component, messing with the actionstack, controller plugins, the list goes on.

    This isn't really ZF's fault as its designed to be open-ended but surely one of the advantages of a framework is that you can hit the ground running?

    I think its quite telling that the only 'major' web app written in ZF (magento) has been critised for being poorly designed - by not implementing any rigid practices ZF allows bad design decisions to be made and so the framework as a whole gets tarnished with the same brush.

    Whilst its fine and even advantageous to include ZF components into a project, implementing a site purely in ZF can open more pitfalls than it solves, especially for novice framework users/developers.

  19. #44
    Twitter: @AnthonySterling silver trophy AnthonySterling's Avatar
    Join Date
    Apr 2008
    Location
    North-East, UK.
    Posts
    6,111
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Outstanding webaddictz, bravo.
    @AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.

  20. #45
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    great posts, webaddictz and romance - very useful information. i see what you're both saying about the "Too many options may kill a man." argument, and based off that, i want to ask what framework would you recommend for a large, long life-span project that will most likely need new features added as time goes on? are you better off sticking with ZF, or perhaps going with CakePHP or Symfony and simply using ZF as a library of classes? or is there another route entirely?

  21. #46
    SitePoint Zealot romance's Avatar
    Join Date
    Apr 2004
    Location
    UK
    Posts
    181
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think that really depends on the project Arrrms - you need to get a list of requirements and then check the framework implementations for each of these.

    For example, trying to coax Zend_Form to play nicely with your design can be a headache compared with sfForm and sfWidget. If this isn't going to be a big concern then no need worry about it.

    I'd probably lean towards symfony+doctrine with ZF components to fill the gaps if you wanted something up and running without worrying if you made the right choice over every single design decision (seeing as symfony makes some of these decisions for you).

    As ZF plays nicely with doctrine as well, you could even replace the VC part of your app with the ZFs MVC implementation down the line.

  22. #47
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's my situation: For the past year we've been using a custom framework that I built. It's been used on everything from small CMS's to larger sites and even a mid sized social network. It's worked great but I now see its limitations. So, rather than reinvent the wheel (even more than I already have) I decided to go with a 3rd party framework. The simpler frameworks (CI, Kohana, Cake) seem too inflexible from what I've heard - so this led me towards ZF. But, as you (and webaddictz) have already said, ZF may be too flexible. What further complicates this is that I'm looking for a one-size-fits-all solution; I need a setup that works on small projects to very large projects (of which we have a few coming up). I am the main developer, so the choice is pretty much mine, but I need my partner to eventually be able to learn the system and help with the less complicated programming tasks. I've researched Doctrine and I love it (I had begun implementing it into my own framework before making the decision to switch to a 3rd party one). So I'm leaning towards Symfony (with Doctrine) as the main framework with ZF to fill in the gaps. I hope that will provide me with a solid yet extensible platform, as we really can't afford to be switching out frameworks every few projects. What worries me, however, is that Symfony seems like it might be a pain to get up and running, but I guess I won't know for sure until I dive in.

  23. #48
    SitePoint Member
    Join Date
    Oct 2009
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Arrrms View Post
    Here's my situation: For the past year we've been using a custom framework that I built. It's been used on everything from small CMS's to larger sites and even a mid sized social network. It's worked great but I now see its limitations. So, rather than reinvent the wheel (even more than I already have) I decided to go with a 3rd party framework. The simpler frameworks (CI, Kohana, Cake) seem too inflexible from what I've heard - so this led me towards ZF. But, as you (and webaddictz) have already said, ZF may be too flexible. What further complicates this is that I'm looking for a one-size-fits-all solution; I need a setup that works on small projects to very large projects (of which we have a few coming up). I am the main developer, so the choice is pretty much mine, but I need my partner to eventually be able to learn the system and help with the less complicated programming tasks. I've researched Doctrine and I love it (I had begun implementing it into my own framework before making the decision to switch to a 3rd party one). So I'm leaning towards Symfony (with Doctrine) as the main framework with ZF to fill in the gaps. I hope that will provide me with a solid yet extensible platform, as we really can't afford to be switching out frameworks every few projects. What worries me, however, is that Symfony seems like it might be a pain to get up and running, but I guess I won't know for sure until I dive in.
    You can check out Yii, it's flexible and good for both small and large projects.

  24. #49
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Arrrms,
    You might want to spend the time to try both Symfony and Zend. Yes Zend has many options but you don't need to use most of them most of the time.

    This Code:
    PHP Code:
    $fc Zend_Controller_Front::getInstance();
    $fc->dispatch();
    ...
    class 
    MyAction extends Zend_Controller_Action
    {
        function 
    actionName()

    Will actually get you up and running. Now once you want to start modifying things, then the options start coming in to play. But it is really not that bad to get started. The manual has examples.

    I did take Symphony out for a test drive when it was first released. I found myself lost in the land of yaml. But I am sure it has improved significantly since then.

  25. #50
    SitePoint Guru
    Join Date
    Mar 2006
    Posts
    701
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayrulez View Post
    You can check out Yii, it's flexible and good for both small and large projects.
    I am using now Yii and I will agree.


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
  •