Hey Robert,
I hope that at least some parts of this rambling makes sense
It does. The thing with the ZF is because it's so flexible, there's more than one way to skin a cat.
Markizano, kudos for the effort, will have a look at it and see if in anyway I can contribute to it :) I have some files/classes laying around in the App_ namespace on top of which I usually develop applications, will see if it fits in to this story in any way
Thanks! I'm pretty sure there isn't going to be a "one size fits all" solution, but having a repository in which we can put generic modules such as user logins, registrations, contact-us pages and the like and an example on how they can be implemented in the ZF would be a great thing to have, IMO.
As for ZF code which I have published, there's the source code behind phpplaneta.net https://github.com/robertbasic/phpplaneta it's nothing complicated, docs and tests are missing (actually am writing the tests now). It's not pretty, but finally a piece of code about which I can say "hey look I wrote that!" :)
I think we all take a bit of pride in knowing we've contributed to something awesome :D
As for the ready made modules, how I see it, is that with ZF you can do something in so many ways and it's usually only a matter of taste (I, for example, prefer to do most of the stuff in the bootstrap's _init methods where as someone else likes to do most of the stuff in the application.ini config file). Someone will use a "hand-made" ORM, someone will use Doctrine 1 or 2, someone will use just Zend_Db_Table - none of this is wrong, but makes reusing modules much more difficult.
With this in mind, I think it would be a good idea to keep things organized and separated. That which uses Zend_Db would go in one class of a module, while that which uses Doctrine 1 would have its own class of module, and Doctrine 2 components would have their class of module. I would imagine this goes for ZF-extension and plugins as well.
Also, ZF has so many components, that most of the time my job is to glue together those components around my application specific business logic. Yes, there are places where this gluing together can be sped up, but that's usually only the "boring" part, like checking if a request is a POST, validating a form and other CRUD-y "patterns". Other parts are really the specific things for that project and that project only. But, if while writing that specific part I learned something new, I'll definitely share that on my blog.
I wouldn't imagine anything too specific to an application would be a good idea to add to this. If it's one of those one-hit-wonders that gets the job done for a specific application, not many people are going to be able to reuse that code. However, because of the vast majority of ways the same goal can be accomplished, I can see where the concern would come into play about making sure a component worked for a particular build.
One more thing is that, again from my perspective, a lot of code gets written between 9AM and 5PM and not many of us have the freedom to publish the code which is written while working for someone. I personally asked for permission to publish some of the code I write at work, and the answer was something like "sure why not, as long as you strip down the application specific part" which again leaves me with the components and the glue I used around them.
This is very true. I do hope that we will be able to contribute to this without too much of an issue. Here we will be border lining that "application-specific" stuff by creating modules and other components generic enough to be used in most [if not all] web applications.
Overall, I think these are really awesome things to consider. They had crossed my mind while I was creating the repository, but I didn't put too much thought into it because I wanted to see how generic was generic :P
Thanks for the input Robert :D -Kizano //----- Information Security eMail: [email protected] http://www.markizano.net/ -- List: [email protected] Info: http://framework.zend.com/archives Unsubscribe: [email protected]
