Page 3 of 4
Posted: Sun Apr 01, 2007 9:20 pm
by Ambush Commander
I'm curious: does Zend Framework provide facilities for upgrading applications (for example, database schema changes, etc?)
Posted: Mon Apr 02, 2007 12:07 am
by Christopher
ole wrote:Sounds great. I guess we should start with the admin stuff first and we'll need a db schema.
I was thinking of doing the easier frontend part first. Essentially the same application that Rob Allen has implemented for his CD catalog example, but with refactored and with some infrastructure. For example, instead of implementing a custom CRUD controller we can look into what the basics of a reusable CRUD controller might look like. Implementing a pager would do the same thing, but for lists. We should look a little deeper into templating to see what a hierarchical system my look like. It is really a design discussion about the architectural options.
Ambush Commander wrote:I'm curious: does Zend Framework provide facilities for upgrading applications (for example, database schema changes, etc?)
There is no O/RM support yet, but Bill Karwin seems to be laying the foundations for that.
Posted: Tue Apr 03, 2007 1:29 am
by Christopher
So I have been digging around in the ZF code a little again to get some sense of what some best practices might be. I pretty quickly found a bunch of code to support doing things that I probably would not do (or don't I think should necessarily be done). This is a problem I have with ZF is that it already seems a little bloated.
Specifically I am thinking about the Controller_Action, View and Response classes that all have lots of functionality. I tend to be willing to constrain myself to cleaner and perhaps dumber code for simplicity's sake. It is more a matter of finding a balance that produces the overall simpler solution. That leads me to think that it might make sense to constrain usage of the Action, View and Response classes to a subset of their functionality, or perhaps to extend some of them to make them into more of a coherent whole. The lack of hierarchical support is probably central to my thinking that.
A second question I have is about what best practices to define regarding using utility classes like Zend_Loader. I see the need to define some rules for when to use the various utility classes, which in practice probably means either embrace them or only use them when absolutely necessary.
And finally there is the issue of the directory layout best practices. I am assuming that it makes the most sense to just go with the defaults in ZF. That is mostly pertinent to the views directory and the controllers directory when using modular controllers. But there might be some cases where the defaults just make things harder ... it definitely needs some research.
Posted: Tue Apr 03, 2007 3:10 am
by Maugrim_The_Reaper
It's definitely bloated in parts around the MVC base elements - remember that the current Request object is only intended for use internally so in the future there may be yet another Response class (though I doubt it to be honest since I think most of the Zenders are happy to access Superglobals directly for filtering/validation). Part of the problem seems to be in how to use certain classes - many have different methods of getting the same result - for example, the Response object has getParam, getParams, getPost, getRequest, getQuery (breaks convention to avoid getGet), getCookie, and of course my favourite - __get(). For an internal class it seems to have a lot of access code for controller routing and dispatching.
On the Utility classes - these got introduced largely because the standalone Zend.php resulted in Subversion externals requiring an extra library directory (conceivably adding a few paths to the include_path for checking), and also because such a general class wasn't used enough to justify being an essential include. There was a long protracted argument to push the split forward which demonstrated a few interesting factors in how development is influenced.
The interesting ones tend to be pretty obvious once you really dig into the source code:
1. Test-Driven Development is an uncommon practice.
I was emailed once or twice about class skeletons missing in a proposal to which I replied I had none and had no intention of providing any. The most I offered was a general interface. Getting pushy over class skeletons is clear upfront design focusing - something TDD avoids like the plague. Also, most unit tests get added after a proposal is accepted and the code completed - unit testing after code completion is a lot more difficult since it starts pointing up weaknesses in the design which prevent efficient testing.
2. Widely used class methods being static.
I have this thing about Zend_Uri::check() being naughty and not very nice. It's a widely used, useful method, which recently (finally) added limited IDN support and it's a static method. I hate commonly used code being stuck into static methods.
3. Duplication of effort
I spent yesterday kicking myself after someone pointed out there's a set of reader/lexer classes buried in Zend_Pdf capable of handling ASCII strings and byte streams. This sort of functionality is common as dirt and shouldn't be buried into components out of sight. Hopefully yesterdays sudden splurge of support for a Zend_Parser or similar (needs a better name since technically there's also Lexers and Scanners in those files, or the abstracts/interfaces for such) will see something proposed for the top level directory to encourage reuse. Too late of two folk (me a third) who spent hours over the weekend implementing our home brewed classes for the exact same thing...
4. Lack of immediate user input safety
Enough said - it'll come after 1.0 but will take months to complete, test, and obviously check it's conformity with servers running ext/filter in various modes. Until then the lack of decent support will send developers running around looking for or concocting solutions. Fodder for proposals at least

. It's been argued to death on the mailing list with little progress so definitely a 1.1 or (as someone mentioned and I hope was kidding) 1.2.
Posted: Tue Apr 03, 2007 3:42 am
by Christopher
Interesting stuff Pádraic. You comments echo my experience and add a number of areas I need to look into. Thanks.
There has been a large group for using lots of statics from the beginning of the ZF. I think Zend mostly saw the error of that way after we were persistent in providing reasons to the contrary. I am not sure it ever made it to the big picture though.
They have been resistant to reducing duplication. I think it makes sense in some ways. It may not be the best idea early on because is might force design choices. I also get the sense that they want the modules to be usable without the core.
The lack of input safety in ZF 1.0 is a crime against PHP. We have been after them to do something for a year or more and they are unwilling to make the trade-offs necessary to make it happen. I really don't know where the countervailing force against doing the right thing is coming from, but it has been strong from Zend from the beginning. It really shows why PHP is still where it is regarding input safety.
I have just spend an hour looking into implementing simple Request, Response, Router and Dispatcher classes from the Interfaces or Abstracts already loaded by the Front Controller. Probably do the same with the Action class. There is just so much code in the "standard" classes that I don't use. I want to see if it is practical to strip them down to simple yet compatible versions ... and it seems like it will be. I should note that the spaghetti dependencies are not very nice in what has been implemented...
Posted: Tue Apr 03, 2007 6:24 am
by Maugrim_The_Reaper
I have just spend an hour looking into implementing simple Request, Response, Router and Dispatcher classes from the Interfaces or Abstracts already loaded by the Front Controller. Probably do the same with the Action class. There is just so much code in the "standard" classes that I don't use. I want to see if it is practical to strip them down to simple yet compatible versions ... and it seems like it will be. I should note that the spaghetti dependencies are not very nice in what has been implemented...
Should be possible - only problem area is if (I haven't checked the code since the recent refactoring to boil down the controller router classes into a single variation) the use of access methods are too varied. Should be possible to do some refactoring and limit the access methods to a minimum set though. It would be interesting to whip out XDebug and see if the routing phase is still hogging the overall execution time - worth noting there has been little to no formal optimisation of the framework as yet so there should be room for improvement. At least they ripped out Reflection way back when someone started comparing framework speed

.
They have been resistant to reducing duplication. I think it makes sense in some ways. It may not be the best idea early on because is might force design choices. I also get the sense that they want the modules to be usable without the core.
Yeah, but we're on the edge of 1.0 with an API requiring stability. There's always the risk that some of that duplication which forms part of the public API will lead to future backward compatibility issues once the duplication is removed. Like I said before there's an large expectation gap over what a 1.0 version means for the Zend Framework. You can't call an incomplete unoptimised framework "completed" and end users will need to be educated on that front so they know the framework is still progressing towards an end goal. I don't see that happening so users will inevitably learn the hard way.
I think the module argument tends to get overplayed and isn't borne out - it doesn't apply to Zend_Uri (obviously because of that lone static method I have a hate relationship with

) and other components like Zend_Loader and more besides. If they wanted true modularisation, they'd have an official PEAR channel with packages for each component and a dependency map to let users manage it automatically rather than by trial and error using subversion. It's telling how difficult it is to pull out individual components and then having to drag in the dependencies by hand - it's not feasible in a subversion external.
The lack of input safety in ZF 1.0 is a crime against PHP. We have been after them to do something for a year or more and they are unwilling to make the trade-offs necessary to make it happen. I really don't know where the countervailing force against doing the right thing is coming from, but it has been strong from Zend from the beginning. It really shows why PHP is still where it is regarding input safety.
I think the main suspect is a lack of urgency and priorities. When people with professions in security start raising their voices persistently and calling for changes are told to wait until a 1.1 version which I assume won't arrive until the Summer, then you get the feeling people aren't taking it seriously enough. It's frustrating to get brushed off with assurances of something happening in the future without a timeline, proposals, or any other undertakings. It's also frustrating when list members start arguing with you over security concepts they seem not to fully understand (or at least don't manage to explain correcly).
I remember I got a lashing by another list member over comments I made about the current Request object and it's questionable use by developers in public examples/help posts as generic superglobal accessors (getParam and __get are plain evil since they don't specifically access $_GET or $_POST but prioritise which to select from - which is just OOP trickery for simulating $_REQUEST when used in input filtering). On the face it seems very logical and persuasive but the guy manages to completely miss the point - generic access is a common vector for CSRF exploits since it treats GET and POST requests as being equally valid. The whole point is to make sure forging POST requests with GET is rendered useless - a simple but effective security measure most of the world's population of PHP developers still don't implement.
Chris Shiflett's response was classic as usual.
Posted: Tue Apr 03, 2007 12:25 pm
by Christopher
Maugrim_The_Reaper wrote:Should be possible - only problem area is if (I haven't checked the code since the recent refactoring to boil down the controller router classes into a single variation) the use of access methods are too varied. Should be possible to do some refactoring and limit the access methods to a minimum set though.
That is my hope ... I am going to give it a try over the next couple of days (if I can get the time).
Maugrim_The_Reaper wrote:...It's also frustrating when list members start arguing with you over security concepts they seem not to fully understand (or at least don't manage to explain correcly).
I remember I got a lashing by another list member over comments I made about the current Request object and it's questionable use by developers in public examples/help posts as generic superglobal accessors (getParam and __get are plain evil since they don't specifically access $_GET or $_POST but prioritise which to select from - which is just OOP trickery for simulating $_REQUEST when used in input filtering). On the face it seems very logical and persuasive but the guy manages to completely miss the point - generic access is a common vector for CSRF exploits since it treats GET and POST requests as being equally valid. The whole point is to make sure forging POST requests with GET is rendered useless - a simple but effective security measure most of the world's population of PHP developers still don't implement.
Chris Shiflett's response was classic as usual.
Yes ... it is very frustrating. I was one of those behind both a Request class and the FilterChain/Validators. I was glad that they saw the value of going that direction, but I suspect that lack of experience with that paradigm has limited their ability to fully embrace it. Hopefully when people live with ZF for a while it will move in the right direction.
In my original proposal, when the request was GET the request object provided values from $_GET. When the request was POST then the request object provided values from $_POST. Admittedly that is a trade-off. But for me the upsides from that trade-off are much bigger than the downsides. For newbies, the benefit is that they are always given the "right" set of values to deal with. The $_REQUEST problems are removed. For supporting classes the upside is a predictable container. FilterChain/Validators can act upon the request as a single container of values. The downside are edge conditions where you want to use GET vars in a POST request. That should be done eyes-wide-open anyway and you should explicitly importing the GET value into the POST values and check for overwriting.
I think I have lost ole in the process. It would be good to keep talking through implementing a demonstration app. Maybe going over the index.php file and config.ini would be the best place to start.
Posted: Tue Apr 03, 2007 3:50 pm
by dreamscape
Not to jump into the middle of the conversation, but if doing a sample application, and doing a store, maybe use the Java Pet Store as a guideline? It seems to be a pretty popular app to use to demo frameworks; for example Prado has a demo of it. That would also make Framework <-> Framework comparisons easier, if it was desired.
Posted: Tue Apr 03, 2007 4:36 pm
by Christopher
Please jump in. The Java Pet Store demo application is a great idea. I am not sure that we can get all of the way there with this discussion, but that demo has the basic features that I was thinking about. And I really like the apples and apples comparison.
http://www.sygel.com/petstore/jsp/shop/ ... anguage=en
I proposed starting simpler without departments/categories-- and growing out. Maybe adding the shopping cart/checkout second. I note that they implement a Pager for their product lists. And they probably have a CRUD system on the backend (I assume there is a simple one).
Posted: Wed Apr 04, 2007 7:04 am
by fastfingertips
I have a feeling that when ZF will be ready PHP 6 will be available and then the guys will have to create another framework version to use at full the new capabilities

Posted: Wed Apr 04, 2007 7:54 am
by Maugrim_The_Reaper
Simpler is better since a lot of the tricky stuff happens when setting up the framework in the initial stages - i.e. bootstrap, authentication/acl, registry or invoke arguments, subclassing of Zend_Controller_Action, etc.
The Java Pet Store or similar looks like a good small application to use.
Should we move this to another thread though? We've gotten off track in this one (well, I did anyway)

.
Posted: Sun Apr 08, 2007 9:31 am
by Ollie Saunders
So I have been digging around in the ZF code a little again to get some sense of what some best practices might be. I pretty quickly found a bunch of code to support doing things that I probably would not do (or don't I think should necessarily be done). This is a problem I have with ZF is that it already seems a little bloated.
I've been doing some thinking I tend to agree. The Zend Framework is too complicated, not test driven developed (very difficult to unit test at points) and in some places just plain wrong.... as a result I am no longer going to be using it on the level that I currently am. Whilst it has every poteniual to grow up to be really good, the principles of the framework are much better than others for instance, it's not going to be there for some time and to be quite honest I can do a better job myself.
That binding router thing I tried wasn't going to work out without a lot of effort integrating it into all the existing controller functionality but I've since come up with better solutions for CRUD.
So basically I'm dropping this.
Posted: Sun Apr 08, 2007 2:11 pm
by Christopher
ole wrote:I've been doing some thinking I tend to agree. The Zend Framework is too complicated, not test driven developed (very difficult to unit test at points) and in some places just plain wrong.... as a result I am no longer going to be using it on the level that I currently am. Whilst it has every poteniual to grow up to be really good, the principles of the framework are much better than others for instance, it's not going to be there for some time and to be quite honest I can do a better job myself.
I tend to agree. But on the other side, there is a lot of good functionality being build (and supported) in ZF. I think it makes sense to keep engaged.
ole wrote:That binding router thing I tried wasn't going to work out without a lot of effort integrating it into all the existing controller functionality but I've since come up with better solutions for CRUD.
So basically I'm dropping this.
First, it would really help me to know what your requirements were/are and what your "better solution" ended up as. I would appreciate if you could add what you have learned, what you need, and your ongoing opinions to the
new thread. Maugrim and I have already posted some detailed comments, but could use some help as that kind of thinking is time consuming.
It may be that we need to develop compatable replacements for the ZF controllers. I already have a sample app running with cut-down replacements that only use the interfaces/abstracts. If I get input that there is a need and what some requirements are I will include those in what I am doing. I tend toward the simplest code that does the minimum that I need. I am willing to accept tradeoffs for that.
Posted: Sun Apr 08, 2007 5:38 pm
by Ollie Saunders
But on the other side, there is a lot of good functionality being build (and supported) in ZF. I think it makes sense to keep engaged.
One of those good principles I mentioned is the fact you can just use the components you need/like. So yeah I'm not going to completely give up on the Zend Framework I'm just not going to be building ZF Applications simply because "this is the Zend Framework".
First, it would really help me to know what your requirements were/are and what your "better solution" ended up as.
Sure. I'll go post on that thread after I've written this.
It may be that we need to develop compatable replacements for the ZF controllers. I already have a sample app running with cut-down replacements that only use the interfaces/abstracts.
For the three hour test run for PHP Throw Down I wrote a really simple front controller in about 20 minutes... I might stick that on there too because served the needs pretty nicely at the time.
If I get input that there is a need and what some requirements are I will include those in what I am doing. I tend toward the simplest code that does the minimum that I need. I am willing to accept tradeoffs for that.
Some things that are too complex to implement as a library without code bloat and in these case we have to look to design patterns and custom user implementation to compromise where necessary. This is exactly why my forms library never saw the light of day....if it had it probably would have been too big for anyone to have bothered with.
Re: Something good written with the Zend Framework
Posted: Sat Nov 28, 2009 12:17 pm
by alex.barylski
Not to re-kindle an old flame, but...
="arborint"In my original proposal, when the request was GET the request object provided values from $_GET. When the request was POST then the request object provided values from $_POST. Admittedly that is a trade-off. But for me the upsides from that trade-off are much bigger than the downsides. For newbies, the benefit is that they are always given the "right" set of values to deal with. The $_REQUEST problems are removed. For supporting classes the upside is a predictable container. FilterChain/Validators can act upon the request as a single container of values. The downside are edge conditions where you want to use GET vars in a POST request. That should be done eyes-wide-open anyway and you should explicitly importing the GET value into the POST values and check for overwriting.
This is an interesting point...I have always used $_REQUEST in my request object but I wonder whether it would be more secure to simply (plain old better practice) to use the GET or POST depending on the method type.
Arborint, do you still feel this way, years later?
I rarely if ever post a form and require GET parameters anymore. Maybe back in the day before I used a framework and scripts were a hodge podge of SQL, XHTML and PHP in a single file but not today.
I assume this is something of a CSRF prevention technique? At least it would eliminate people trying to forge POST request with GET, correct?
Cheers,
Alex