Rob Jellinghaus wrote:
>
> Speaking as a Cocoon user with Apache committer credentials (I am a
> committer to xml-axis):
>
> I'm ramping up on Cocoon right now. As of this moment, the thing that
> makes me most uncomfortable with Cocoon is its lack of modularity at the
> sub-site level. Installing a new "component" ("sub-sitemap" seems to be
> the closest equivalent in Cocoon 2.0.2) may involve changing cocoon.xconf
> and the top-level sitemap.xmap in various subtle ways (adding
> <builtin-logicsheet> definitions, adding sub-sitemap redirections, et al.).
>
> My goal in building Cocoon components is to make them easy to deploy --
> whatever I build on my home machine should be trivially installable on
> another Cocoon system. This need is not met by Cocoon right now. Consider
> chello -- it should be a single, self-contained, minimal,
> automatically-installable (drop it under cocoon/WEB-INF, or in some
> subdirectory thereof, and it just works) project. Instead it includes *all
> of Cocoon* because explaining how to install it is so hard as to confuse
> the people who most need it -- Cocoon newbies!
>
> Cocoon blocks, if I understand Stefano's characterization, are intended to
> address this issue.
Yes.
> However, Stefano talks not just about packaging a
> Cocoon "subproduct", but also about fetching dependent components over the
> web, and even about automatic contract validation of Cocoon "subproducts"
> (aka Cocoon blocks). To me, those latter areas -- fetching dependent
> blocks by URI, defining subproduct interactions, and defining *any* notion
> of contract *at all* -- are layers on top of a more basic and minimal
> packaging layer, which does not yet exist.
Hmmm, this would be true if blocks didn't expose polymorphic behavior.
> Cocoon badly needs a *minimal* definition of Cocoon blocks, defined as "a
> self-contained Cocoon product, containing builtin-logicsheets, sitemaps,
> classes, and anything else that may go into a Cocoon project, installable
> simply by dragging and dropping it into a specific area in a vanilla Cocoon
> installation with no changes to cocoon.xconf or sitemap.xmap." Until
> Cocoon has this, newbies (I speak from immediate experience!) will continue
> to suffer, and deploying Cocoon projects will be much harder than it should be.
This is a good point.
> This minimal Cocoon block mechanism is also a lot easier than the rest of
> it :-)
What you outline above *cannot* be called 'block' but simply 'package'
since blocks exhibit polymorphic nature unlike 'packages' which are
simply functional archives with a one-2-one relationship with its
contract and its implementation.
So, a minimal 'cocoon packages' mechanism (which clones the Servlet API
WAR concept without extending it to the use of Avalon Blocks) still
requires:
1) classloading
2) URI mounting
but I'm *dead sure* that people will soon start asking for 'inter
package' communication ("how do I access this stylesheet from package A
to package B?") and start doing 'hacks' such as absolute file
positioning of resources.
once this is in place and released, we *have* to support it.
This means that by the time we are ready to deploy Cocoon Blocks, people
will have to move things.
> In my strong opinion, this should be the first thing you do, maybe
> even in Cocoon 2.0.5 or something.
In my *even stronger* opinion, cloning the WAR package concept is a
*very poor* way of dealing with the problems outlined.
Sure, we won't implement 'install-over-the-web' functionalities at
first, but the architecture should start *complete* since incremental
functionality is just too weak and, besides, the *minimal* support is
probably 80% of the code to write, so the remaining 20% can be added
right there with no further delay and the design done coherently in one
big step.
> Then build the additional layers on top
> of this foundation, while all the book authors, tutorial writers, and
> Cocoon developers get started *using* this very useful mechanism that you
> haven't built yet.
I think you don't seem to understand the impact of polymorphism on this.
> Solve the smallest problem first, guys! You won't shoot yourselves in the
> foot by doing so, since you need all this minimal mechanism in order to do
> the rest of it *anyway*.
I strongly disagree in this specific case: look at it from a SoC
perspective? you are proposing to separate concerns depending on 'ease
of implementation', which is a *very* dangerous thing to do, expecially
if it refactors the system in such a way that is orthogonally oriented
compared to the whole architecture.
Please, consider that we have to *support* what we build and adding
polymorphism later on might *not* be back compatible.
Anyway, if you have any idea on how to make it 'incremental' and avoid
any possible back-compatibility drawbacks, I'll be all ears :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
