On 14/07/2010 15:01, David Mintz wrote:
On Wed, Jul 14, 2010 at 9:50 AM, Paul <[email protected]
<mailto:[email protected]>> wrote:
On 7/14/2010 12:05 AM, Mike A wrote:
On 13/07/2010 22:44, Jonathon Suggs wrote:
Would the community find benefit in having a repository of
commonly
used models/entities?
The classes would all just be plain php classes with Doctrine2
annotations (and unit tests). I understand that use cases
will vary
between projects but the classes could always be extended and
overridden.
Subsequently, the classes could be used to create
pluggable modules.
I'm thinking that it would be a nice feature for the
framework to be
able to add in a blog or forum (or whatever) module that
could be part
of your codebase, but without requiring too much developer
customizations (unless wanted).
I realize this is somewhat of a vague and ambitious
request, but if
there is interest I'd like to get some ideas for defining
requirements
and use cases. I guess my only two initial
requirements/constraints
are Zend Framework (target ZF2) and Doctrine2. I also
would expect
for the development to happen outside of the official
project but
would (obviously) work closely with all projects involved.
I am writing a ZF book named ModJewelz at the moment. An
ongoing work it will eventually become a huge reference. The
idea of it is not only to act as a guide to building modular
ZF systems but as a reference for modules, plugins and helpers
built, tested and available in a central repository after
being subjected to scrutiny by the community. To give an idea
about the depth of reference, the chapter on building a common
foundation template as a basis for modular systems already
runs to about 70 pages.
So yes, I think the idea is good, but only for tested
components capable of interfacing with common templates.
Otherwise the repository could become saturated and obfusated
by poorly written components - as with other CMS and frameworks.
Sounds like a great book, but I do not see why we have to have to
put limitations on it. The community can filter these components
on their own. As long as users can rate the components you can
let the people choose what they want.
I think it as Larry Wall who said something about there being a law
that holds that 90% of everything is crap. Talking about CPAN, he goes
on to say that CPAN is so huge -- 18,000 modules at this point -- that
the other 10% of non-crap is quite a significant amount of quality code.
Seems like a middle course would be prudent: exercise a degree of
quality control, but without becoming too obsessive or exclusive about it.
Absolutely, which is why I thought qualified components would assist.
I've lost count of the wasted hours hunting through hoards of, and
trying, poorly explained components for the like of Drupal only to
discover that the component had flaws. Which is why I like loosely
coupled ZF so much.
To elaborate on the approach I have adopted, in legal circles there are
concisely set out references for everything from court practice (with
authorities) to specialist areas like family law (with authorities).
Every chapter, heading and paragraph carries a reference number, which
makes communication between practitioners and courts precise.
Authorities and reference text are updated according to latest case,
statute and authority, thus providing a good base from which
practitioners can work. I see nothing like this in the development
professions, leaving developers to wade through the mish-mash of
information without a clear method of navigation and communication. By
choosing the legal reference approach the ModJewelz reference* can be
updated at will by informed participants and according to the latest
components becoming available as singular, grouped, modular or
systematic plugins. They in turn can evolve and the community can
discuss/debate by referenece to specific numbered text.
There are positive marketing opportunities in this approach. Whilst the
development community would expect to share singular or grouped
components, developers can market modular or systematic components
special to specific commercial use: say for tourism or medical practice.
Perhaps it's worth mentioning that a project like the ModJewelz one
would normally be hampered by lack of consistent management. Now
approaching 58 and semi-retired I can devote long term attention to it
in the hope that more than a few will find the reference a first stop
when building or maintaining projects and delivering components for
distribution: like a conduit between all the Zend material, the vast
amount of material and tutorials available via search, and newly
arriving components, approaches or technology. I do not intend to sell
the book - more when the website is properly up. It's written to act as
a conduit between <v2.0 and v2.0 too.
Given all that, it would be useful to make contact with some interested
souls keen to help form a repository coupled with the reference book.
* Produced with InDesign and published in PDF.
