Page 1 of 3

Frameworks

Posted: Mon Dec 22, 2008 6:44 am
by The_Anomaly
I'm sure this topic has been covered time and time again in this forum, but I had some extra concerns I wanted to address here. I'm relatively new when it comes to development, and I'll say I've probably developed two fully OOP production web applications. I don't really work as a web developer, so the development I do is as much for the learning experience as it is for the pay, so basically, I'm trying to figure out how to do things the best possible way.

My first web app I made after reading Zandstra's PHP 5: Objects, Patterns, Practice, which marked my "Awakening," to the world of OOP. Anyway, I basically created the web app according to this book, by using the patterns for Data Mapper, Front Controller, Template Views, etc all based on what was defined in the book. I probably could have found a framework that used these patterns, but as I said before, my goal was always to learn to do it, so coding it all from the ground up seemed natural. Anyway, I finished that project, and it works like a dream...I really like the framework I created for it.

Anyway, my next project came along--this one for another person, as opposed to the formerly mentioned personal project--so I thought I'd try out another framework, like Zend. I've just finished it, but it was a disaster. I won't go dissing the framework, as maybe my bad experience was just because I didn't study it well enough, but I honestly spent 90% of my time in that reference manual trying to figure out what craziness they had going on with the MVC framework. Again, maybe I just didn't understand it well enough, but it seemed extremely bloated, hard to use, and all around making the developer use obscure and unclean code, when I could do it much easier, and much cleaner in my old framework.

I'm writing this thread to ask if anyone has had the same experience, and could possibly give a bit of advice. I'm currently enjoying a nice vacation (two weeks) and I thought I'd spend the first week studying some frameworks and patterns (Reading Fowler and such), and then the next week really making my current framework perfect, and not use any 3rd party frameworks.

However, I know that there are other frameworks out there, and maybe they are better. Does anyone use other frameworks aside from Zend and could recommend I give them a try? Or if I didn't like Zend I probably won't like most of the others? Or should I just give Zend another try?

Re: Frameworks

Posted: Mon Dec 22, 2008 9:39 am
by alex.barylski
Again, maybe I just didn't understand it well enough, but it seemed extremely bloated, hard to use, and all around making the developer use obscure and unclean code, when I could do it much easier, and much cleaner in my old framework.
Little bit of column A, little bit of column B...

ZF is complex...overly complex...I think only those who have been tightly coupled with the project since it's inception would argue otherwise. :P

I occassionaly use parts of it, but for the most part, it's redunkulous and could be simplified...it suffers from:

1. To many Cooks in the kitchen...I know saying this defeats the idea of community driven open source but it's true.
2. Attempting to please everyone by abstracting everything imaginable.

Not sure about obscure...or unclean...as it's modeled after most common patterns, follows some convention and mostly separates common concerns. I think Zend ultimately suffers from pattern zeal, everyone that works with that framework seems so enthusiastic about their understanding of patterns they over engineer everything trying to meet exacting pattern definitions set forth in GoF or POEAA.
I'm writing this thread to ask if anyone has had the same experience, and could possibly give a bit of advice. I'm currently enjoying a nice vacation (two weeks) and I thought I'd spend the first week studying some frameworks and patterns (Reading Fowler and such), and then the next week really making my current framework perfect, and not use any 3rd party frameworks.
DRY KISS is more important than adhering to formal pattern definitions IMHO. If you can implement a solution following a pattern only partially...then do it...don't implement the entire pattern for the sake of completeness and personal satisfaction.

The front controller for instance, do you really need a distinct router? How about a dispatcher? Could you get away with keeping things simple and have those elements of a front controller inlined and be more transparent?

If your building an application from scratch...you should structure your file system in a consistent manner and have no reason to introduce a flexible dispatcher, and routing, same thing. Do you need to support CLI and HTTP? Can parsing of the URI be done by hand in the index.php and provide a more elegant, lightweight, easier to understand implementation?

I like to keep things simple, tying the peices togather manually if need be...Zend is better in this regard than others, like CodeIgnitor for example, but the classes are not as cohesive as they could be. I have a general rule of thumbe where if a method is more than 20-30 lines something is to complex and it's time for a refactor.

99% of my class files are no more than 100 lines of code, the exception being the models. and now with my recent implementation of an data mapper/gateway layer ontop my PDO library, model code has been further reduced to only a dozen lines per method as well.

My advice would be to continue learning about frameworks but challenge everything you read, including that of Fowler and other authorities. Don't just memorize the pattern, but truly understand the forces that lead to the discovery of the pattern, sometimes that means, reading an article and implementing a pattern manually, using it for a while, experiencing your failure, re-reading the article, re-implementing and repeating the whole process.

Look for breif articles that sum up a solution in a single "aha" moment...not verbose, dry, boring full of silly analogies type books (Head First is horrible in this regard).

Don't just stop at design patterns either, read up on object oriented analysis, design, principles and practices.

http://foozle.berkeley.edu/projects/str ... iples.html

Google each and read up on them...

Re: Frameworks

Posted: Mon Dec 22, 2008 10:35 am
by The_Anomaly
DRY KISS. I like that :D

Anyway, first off, thank you for the response. I greatly appreciate your advice and input, as I'm doing my best to master OOP theory to whatever level is possible.

I clearly agree with your description of ZF, and you stated exactly my issues with it. Especially with relation to keeping it simple, i.e. no need for dispatcher, router, CLI vs. HTTP and such.
My advice would be to continue learning about frameworks but challenge everything you read, including that of Fowler and other authorities. Don't just memorize the pattern, but truly understand the forces that lead to the discovery of the pattern, sometimes that means, reading an article and implementing a pattern manually, using it for a while, experiencing your failure, re-reading the article, re-implementing and repeating the whole process.
Makes a great deal of sense. I'll follow your advice, and check out the points listed in the link.

Again, thank you for your advice/input.

Re: Frameworks

Posted: Mon Dec 22, 2008 10:50 am
by matthijs
I haven't really worked with the ZF, but do read the articles about it which happen to find their way into my feedreader. I think PCSpectra could have a point that with the ZF every detail is so abstracted away/patterned out, that you end up with things like:

Code: Select all

 
$doctypeHelper = new Zend_View_Helper_Doctype();
$doctypeHelper->doctype('XHTML1_STRICT');
 
<?php echo $this->doctype() ?>
 
A complete object and at least 3 lines of code to replace 2 lines of plain simple html?

Re: Frameworks

Posted: Mon Dec 22, 2008 12:51 pm
by Eran
I think you guys are missing the point. ZF does have some bloat, but it's more a component library than a tight framework (like CakePHP). Apart from it's MVC components, most of the of components can be used standalone, and there are some really good ones there - the database component, filtering/validation component, the MVC component (with some tweaks), Authentication componenet, session component and others.

You don't have to use what you don't need. I for one, would never use what matthijs just described, though I can imagine how that could be used. Also, it's not three lines - helpers can be instanced directly from the views by calling their names as methods -

Code: Select all

<?php echo $this->doctype('XHTML1_STRICT'); ?>
Would suffice. The reasoning for using those view placeholders is the two-step view pattern, which is useful for defining such attributes on the fly. I won't get into when it's relevant to use it (I mostly don't), but there are such scenarios. The option is there - you can choose to use or not.

All in all, starting using ZF was the single biggest jump in productivity I have had as a developer. I learned so much from using it and examining the code and I highly recommend that anyone considering himself a serious developer should accumulate substantial experience with one of the major frameworks.

Re: Frameworks

Posted: Mon Dec 22, 2008 4:20 pm
by alex.barylski
You don't have to use what you don't need.
Thats true of any framework or library...even PEAR.

But using Zend_Feed for instance, requires:
- Zend_Http_Client
- Zend_Feed_Exception
- Zend_Feed_Rss
- Zend_Uri
- Zend_Uri_Exception
- Zend_Feed_Builder
- Zend_Loader

That is just from quickly glossing over the source...and doesn't include any of the dependencies required for the above to work as expected.

Now those dependencies might be needed, but in a self driven project they could be removed almost 10 fold. The point is, Zend is clearly not loosely coupled when a simple RSS feed reader has over half a dozen external dependencies, not including the dependencies of each of the dependencies.

The "use only what you need" argument is not as cut and dry and many seem to think it is.

Cheers,
Alex

Re: Frameworks

Posted: Tue Dec 23, 2008 5:29 am
by Eran
You could call this dependencies or you can call this code reuse... this way you can substitute those components for your own if you wish - for example extend Zend_Http_Client and pass it to setHttpClient(). Also by including the exception classes in your class count you were obviously trying to make a point rather than look at it objectively - what's better, having duplicate code in every component or having them reuse each other? the important thing you can mostly substitute your classes for Zend's if you wish to.

Re: Frameworks

Posted: Tue Dec 23, 2008 2:00 pm
by Christopher
PCSpectra wrote:The "use only what you need" argument is not as cut and dry and many seem to think it is.
If they split it out and duplicated the code then yours would be a "use only two you need" argument. If they cut then it wouldn't be as dry...

Re: Frameworks

Posted: Tue Dec 23, 2008 2:59 pm
by josh
PCSpectra wrote:Now those dependencies might be needed, but in a self driven project they could be removed almost 10 fold.
Great :-D cram everything into one god package.

@op care to share your API and explain the advantages it has over ZF? I'd be interested in the data Mapper

Re: Frameworks

Posted: Tue Dec 23, 2008 3:44 pm
by Christopher
jshpro2 wrote:I'd be interested in the data Mapper
Feel like working on a DataMapper project! ;)

Re: Frameworks

Posted: Tue Dec 23, 2008 7:09 pm
by alex.barylski
Also by including the exception classes in your class count you were obviously trying to make a point rather than look at it objectively - what's better, having duplicate code in every component or having them reuse each other? the important thing you can mostly substitute your classes for Zend's if you wish to.
I was trying to do both, but anyways...

Duplicate code anywhere is a cardinal sin...but so are over engineered objects.

Maybe I misunderstand the design and/or usage of Zend (in which case by all means show me) but...

Looking at Zend_Http_Client you will see that it does not implement an interface so you are stuck with two options:

1. Inherit from the original and override any required funcitonality -- which is a problem I will explain shortly
2. Create a class of the exact identity/signature and hope the *real* Zend_Http_Client never gets included and causes namespace collision

#1 Why would I inherit from the base class when it's the base class that makes me dislike it? It's bloated. All I needed for an RSS feed is an HTTP request and maybe response to check for errors on the external source, then to have the class parse the XML and return an array which I can easily iterate.

There is no need for file uploading, cookie support or other functionality found in Zend_Http_Client.

While the code *might* (I use that loosely) be DRY it's certainly not KISS nor is it adhering to SRP (Single Responsibility Principle).

There is nothing "wrong" with Zend...it's a good solution to many a problems I would just never use it for a personal project where DRY KISS was the impetus, and not the end user, making money, etc.

I use Joomla for commercial projects...and it's design it one of the most confusing, overly complex I have ever seen in PHP but it gets the job done faster than coding by hand or using something like ZF.

Re: Frameworks

Posted: Tue Dec 23, 2008 8:02 pm
by Eran
Again, I'm not sure what it is you are attacking. Feed handling is composed of several distinct actions that in the ZF are separated into different components, each with it's reponsibility matrix. That Zend_Feed uses those different components doesn't make it more complex or step outside of its responsibility (which is to handle feeds).

Zend_Http_Client abstract http requests/response actions which is a rather tedious part of php. Zend_Http_Client in this case is used to generate socket http request for retrieving feeds, and it saves a lot of grunt work of dealing with sockets etc. It bothers you that it can do other things as well, and hence it is "bloat"? you use Joomla freely, and it is much more bloated than the ZF and does much less.

It's true that zend_http_client doesn't have an interface. Possibly this was a mistake? I never had the urge to implement my own Http_Client for the reasons I mentioned above. You could open a ZF issue at their issue tracker if you want this resolved.

That you don't use ZF for your own projects, doesn't mean it can't be used for rapid application development by abstracting much of the technical background with reliable components, allowing you to focus on the problem domain (which is what good frameworks should do). Even if you get a little more than what you asked, I fail to see how is that such a deterrent to you. I think it strikes a good enough balance between separating functionality into small classes and having easy to follow class hierarchy.

Re: Frameworks

Posted: Tue Dec 23, 2008 9:46 pm
by Syntac
Abstraction is good, up to a point. Modularity is good, up to a point. Seems to me ZF has exceeded both. [Warning! Drunk person's opinion!]

If I need a ridiculously overcomplicated framework, I'll write one.

Also, pytrin: He did say Joomla is confusing and overly complex; apparently he just hates it less. :)

Re: Frameworks

Posted: Wed Dec 24, 2008 10:09 am
by josh
PCSpectra wrote: There is no need for file uploading, cookie support or other functionality found in Zend_Http_Client.
Oh come on. Just because you like minimal stuff doesn't make Zend "bad". You always say stuff is "bad" and usually your reasons boil down to "i dont like it". If you don't like it then fine, but some of your comments could scare away newcomers from what's an otherwise great framework. If you don't like it don't use it, but to me it seems like you hunt out reasons to throw it under the bus. My 2 cents.

Re: Frameworks

Posted: Wed Dec 24, 2008 12:44 pm
by Christopher
PCSpectra wrote:While the code *might* (I use that loosely) be DRY it's certainly not KISS nor is it adhering to SRP (Single Responsibility Principle).
I just had a realization that I hear about the importance of KISS from almost no one except PCSpectra (a quick search of this Theory and Design forum will confirm this). I think KISS is at the heart of most of PCSpectra's complaints about software.

That got me thinking about the reason why KISS is not as important to me. I think it is because to me KISS is not really a software principle -- it's just a general aphorism. It's not like DRY or SRP or YAGNI where you can actually see if code is repeated, has multiple responsibilities or is currently used. KISS is, no surprise, pretty subjective. The thing about KISS for me is that it is about unnecessary complexity, not complexity itself. And "unnecessary" is about features, not a design principle.