You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Rob Jellinghaus <ro...@helium.com> on 2002/03/29 20:07:54 UTC
Cocoon Blocks and contract validation
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. 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.
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 minimal Cocoon block mechanism is also a lot easier than the rest of
it :-) In my strong opinion, this should be the first thing you do, maybe
even in Cocoon 2.0.5 or something. 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.
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*.
Sincerely,
Rob Jellinghaus
http://www.helium.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks and contract validation
Posted by Ivelin Ivanov <iv...@iname.com>.
Just want to express my solidarity with Rob.
It's been somewhat surprisingly painful experience for me to get Cocoon
running and consequently to get my own demos running. I am also a believer,
from experience, in building small pieces at a time. Just big enough to have
value on their own and small enough for everyone to understand and embrace.
In my experience, the big and nice things have been built over multiple
iterations, not at once.
If it counts, I vote for a first iteration of Cocoon blocks where one can
drop a .cob file and swtich to the browser.
Maybe by the time this iteration is ready, Cocoon will have a more
sophisticate validation infrastructure which could be leveraged.
Ivelin
----- Original Message -----
From: "Rob Jellinghaus" <ro...@helium.com>
To: <co...@xml.apache.org>
Sent: Friday, March 29, 2002 1:07 PM
Subject: Cocoon Blocks and contract validation
> 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. 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.
>
> 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 minimal Cocoon block mechanism is also a lot easier than the rest of
> it :-) In my strong opinion, this should be the first thing you do, maybe
> even in Cocoon 2.0.5 or something. 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.
>
> 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*.
>
> Sincerely,
> Rob Jellinghaus
> http://www.helium.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks and contract validation
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org