You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/06/28 19:04:39 UTC
[RT] Cocoon Blocks
Even if the flowscript discussion isn't finished, I think we have
reached an important conclusion on that side: a flowscript isn't a
sitemap replacer, but a sitemap augmenter.
Architecturally, this has a major importance: the flowscript and all its
design details become part of the sitemap's concern island and we can
independently work on something that is therefore not directly connected
with the flowscript.
In the past, this architectural assumption wasn't recognized and for
this reason, the design of the Cocoon Blocks couldn't be finished
without finishing that part (or, at least, understanding that the two
aren't directly related).
In the past, the concern islands were these three:
block sitemap flowmap
the most general way to connect them is
block
/ \
/ \
sitemap --- flowmap
but now we know that the (blocks-flowmap) contract isn't necessary
(rather: it's perceived as dangerous because it allows to assemble
pipelines in scripting and this creates concern overlap with the
sitemap).
The current situation is
block ---- sitemap --- flowscript
which, from the block's point of view, becomes
block --- sitemap
since the sitemap makes the flowscript concern totally hidden inside its
own.
This contract analysis tells us that as long as the concern topology
remains this, there is no overlap or interference between the design
work on the flowscript and the design work on the Cocoon blocks.
All right, so we can focus on blocks.
- o -
A step back: what are the problems we are trying to solve
---------------------------------------------------------
Cocoon is a framework implemented as an application.
A 'framework' is supposed to give services to entities included in it,
while an application is supposed to be executed by a containing
framework.
While the above might sound weird at first, this is a very common
situation: an operating system is a framework implemented as an
application run at boot time. At the same time, an application server is
a framework implemented as an application. But even a browser is a
framework implemented as an application.
So, there is no inherently bad design in this concept, *but* the
framework must be implemented in such a way that it's inherently *easy*
to deploy/install/plug-in/connect/attach/inject/link an internal
application that must be executed by the framework.
Cocoon lacks this.
Let me give you an example: I would like to be able to package my stuff
that I wrote to be run *by* cocoon and deploy it on Cocoon, maybe even
at runtime.
The parallel is easily made: servlets and WARs archives. The Servlet API
introduced in a later release the concept of a WAR (Web ARchive) package
that includes all the resources needed for the servlet/jsp-based web
application to run, including libraries, resources, files and
everything.
So, the parallel I want to draw is simple:
WAR (Web ARchive) -> tomcat (or other servlet container)
COB (COcoon Block) -> cocoon
so, a WAR package is for tomcat what a COB will be for Cocoon.
In very short terms: a way for you to deploy your stuff on Cocoon
without hassle (including special libraries, resources and what not).
Are we really cloning the servlet API?
--------------------------------------
Many people from the pure J2EE world (even Apache people) believe that
Cocoon is just an attempt to rewrite the servlet API for XML. In a sense
it's true: the servlet API wasn't designed for pipelines and the
deployment descriptor wasn't designed for serious URI space mapping.
So, while the Servlet API introduces components (servlets and filters)
that are based on streams of bytes/chars, Cocoon introduces components
designed to be part of a pipeline [since 1997 I thought about a way to
allow servlet chaining to be feasible, that is probably what triggered
the idea of pipeline components for Cocoon].
Anyway, looking at this parallel, Cocoon really lacks a way to make its
applications deployed easily within a 'naked' container that includes
only the basic and default machinery.
- o -
I'm pretty sure that if I stopped here and went on describing the schema
of the COB descriptor file and so on, people would love it, thank me,
run to their boss to tell them and blah blah..
Sure, we could stop here, we could clone the WAR concept inside Cocoon,
allow you to deploy your stuff and you won't be missing anything.
But there is one thing that the servlet API architects didn't consider
(not even myself at that time since I was part of that group):
polymorphism.
Ok, a few blank lines so you think about it....
what does it mean to have a polymorphic package?
Applying Avalon COP philosophy over again
-----------------------------------------
If ever worked with Avalon, you know the feeling: at first it doesn't
make any sense at all. It's a mess of stupid and very abstract
interfaces... but after a while, a patter emerges and it sticks.
Some might think that Avalon (probably Cocoon itself) includes infecting
'memes' and I agree. [Look up the name on google if you don't know what
I'm talking about]
Once you start using COP (component oriented programming), it's very
hard to go back (so much so that many abuse it and over-componentize
their systems... even Cocoon itself suffers from this problem on some
parts).
COP is based on IoC (Inversion of Control) and SoC (Separation of
Concerns) [for those who still don't know about them!] and while the
servlet API makes extensive use of the IoC metapattern, SoC doesn't play
a clear and defined role (they tried to patch it with RequestDispatcher,
which is the biggest hack I ever seen, I even voted against it but I was
overruled).
Anyway, if the servlet API, internally, show use of IoC and SoC,
externally, from the WAR point of view, there is *absolutely* no notion
of it: a WAR is a package that includes a single and isolated
application.
Period. That's it. There are many mechanism that enforce the clear
separation between different WARs. So, they implement monolithic web
applications and this is *by design*.
A step up: Blocks as cocoon application components
--------------------------------------------------
If we design cocoon blocks as 'isolated units of application deployment'
we fall back in the good old web trap: making web applications
interoperate in the same URI space is a MAJOR PITA with *ANY* web
technology.
I'm talking about making Bugzilla and Horde IMP share the same look and
feel. Try it!
'coherence' is a value, expecially on professional sites, but coherence
shouldn't mean that everything has to be written by the same team!
Sure, I want Cocoon blocks to ease deployment of cocoon-based web
applications, but this is a secondary byproduct: what I really want is
to make it possible to *share* cocoon web applications as we currently
do with Avalon components.
- o -
Ok, enough introduction, let's get to the meat.
WARNING: what follows is the result of ideas collected from many people,
and was cleared in all parts with real-life discussion between Giacomo
and myself a few weeks ago. Anyway, what follows is still part of the RT
flow, so it must only be considered as a proposal and not something
carved in stone.
Cocoon Blocks
-------------
A Cocoon block is a zipped archive, just like JARs and WARs.
The extension of a cocoon block is .cob (for COcoon Block). The MIME
type is yet to be determined (might be required for over-the-net block
download).
A Cocoon Block (COB from now on) includes a directory called
/BLOCK-INF
which contains all the block metadata and the resources that must not be
directly referentiable from other blocks (for example, jars, classes or
file resources made available thru the classloader). The directories
/BLOCK-INF/classes
/BLOCK-INF/jar
are used for classes and jar files. This follows the WAR paradigm.
The main COB descriptor file is found at
/BLOCK-INF/block.info
[FIXME: can this create conflicts with Avalon blocks?]
This file MUST be an XML file, containing markup with a cob-specific
namespace and will include the following information:
1) block implementation metadata (name, author, license, URL of the
project and so on)
2) role(s): the URI(s) of the behavioral role(s) this block implements
and exposes [optional]
3) dependencies: the URI(s) of the behavioral roles this block expects,
along with the prefixes used by the block as shortcuts in protocol
resolvin (see below for the meaning of this)
[optional]
4) sitemap: the location inside the block file space of the sitemap
[optional]
Visually, the block metadata can be pictured like this:
implementation metadata
^
|
(exposed behaviors)? <---- [block] ----> (required behaviors)?
Also, the /BLOCK-INF/ directory contains the 'roles' file for Avalon
components:
/BLOCK-INF/block.roles
What is a 'block behavior'?
---------------------------
If you are familiar with Avalon, you probably understood the idea (it's
very similar to the concept of Avalon roles), but if not it might be a
little difficult, so let me write you an example of this:
let's take Forrest and let it decouple in two blocks:
1) one block provides the document production
2) another block provides the skinning and presentation layers
Currently, it is already done like this, but the change of the skin
(this is how the second block is currently called) must be done by hand:
there is no cocoon machinery in place to make this possible.
So, let us assume the machinery is now in place:
forrest itself becomes a block, but in order to function, it needs
access to the stylesheets contained in the skin, which, in order to
simplify decoupling, we want to implement as another block.
Result:
forrest.cob/BLOCK-INF/block.info
is something like
<block>
<metadata>
<name>Forrest</name>
<organization>ASF</organization>
...
</metadata>
<dependencies>
<block behavior="http://xml.apache.org/forrest/skin/1.0"
prefix="skin"/>
</dependencies>
<sitemap location="sitemap.xmap"/>
</block>
while:
skin.cob/BLOCK-INF/block.info
is something like
<block>
<metadata>
<name>Xmas Skin</name>
...
</metadata>
<behaviors>
<behavior uri="http://xml.apache.org/forrest/skin/1.0"/>
</behaviors>
</block>
Now: suppose you have your naked cocoon running in your favorite servlet
container, and you want to deploy forrest.cob, here is a possible
sequence of actions on an hypotetical web interface on top of Cocoon
(a-la Tomcat Manager)
1) upload the forrest.cob to Cocoon
2) Cocoon scans /BLOCK-INF/, reads block.info and finds out that
Forrest depends on a block which the given role
3) then it connects to the uber "Cocoon Block Librarian" web service
(hosted somewhere around *.apache.org) and asks for the list of blocks
that exhibit that required behavior.
4) the librarian returns a list of those blocks, so the users chooses,
or the manager allows the user to deploy its own block that implements
the required behavior.
5) Cocoon checks that all dependencies are met, then unpacks the blocks
6) Since 'forrest.cob' exposes a sitemap, the deployment manager asks
the deploying user where he/she wants to *mount* that block in the
managed URI space.
7) If no collisions in the URI spaces are found, the blocks are made
available for servicing. [note: the skin block doesn't exposes a sitemap
so it's not mounted on the URI space]
A big issue: resource dereferencing
-----------------------------------
Security concerns aside, the above scenario shows one major issue:
blocks are managed, deployed and mounted by the container. There is (and
there should not be) a way for a block to directly access another block
because this would ruin IoC.
So, one block doesn't know where the blocks it depends on are located,
both on disk *and* on the URI space as well.
The proposed solution is to use block-specific protocols to identify the
dereferenced resources.
For example, the forrest.cob/sitemap.xmap file could contain a global
matcher which works like this:
<map:match pattern="**/*.html">
<map:aggregate element="site">
<map:part src="cocoon:/{1}/book-{1}/{2}.xml"/>
<map:part src="cocoon:/{1}/tab-{1}/{2}.xml"/>
<map:part src="cocoon:/body-{1}/{2}.xml" label="content"/>
</map:aggregate>
<map:transform src="block:skin:/stylesheets/site2xhtml.xslt"/>
<map:serialize/>
</map:match>
please note the
block:skin:/stylesheets/site2xhtml.xslt
which indicates
block -> use the block protocol
skin -> use the 'skin' prefix to lookup the block behavior URI and thus
the block which implements it for this block (the block manager knows
this)
/stylesheets/site2xhtml.xslt -> since the 'skin' block doesn't expose a
sitemap, give me the file located in that position of the internal block
file space (except /BLOCK-INF/ which is protected)
[in case the block exposes a sitemap, the block: protocol connects to
the URI space exposed by the sitemap... before you start suggesting a
block-raw: protocol to get access to that, think twice because, to me,
it smells like FS a lot!]
Dereferencing navigation
------------------------
Not only a sitemap needs to connect to the resources contained in the
blocks on which the block depends on, but the resulting pages as well.
In fact, suppose you have a block that exposes a web service and another
one that exposes a web application that wraps that web service. For
sure, the generated web page will have to have a URI to connect to that
service, since it's the client's browser that makes the call (unless we
want to virtualize everything thru the sitemaps, but I wouldn't suggest
it).
So, a possible solution is to use the "block:" protocol in the pages as
well and have a URI-mapping transformer right before the serialization
stage.
For example, things like
<form action="block:web-service:/post">...</form>
is trasnformed into
<form action="/servizio-web/post"/>...</form>
- 0 -
Some design decision taken
--------------------------
o) NO BEHAVIOR VALIDATION:
I thought a lot about it but I think that having 'behavior description
languages' (such as the WSDL-equivalent for blocks) is going to be
terribly complicated, expensive to implement and hard to use and
enforce, even for simple blocks which don't expose a sitemap and are
just repositories for informations.
For this reason, there is no validation taking place: if a block
implements a particular behavior and exposes it thru its descriptor
file, Cocoon automatically assume it implements the behavior correctly.
In the future, we might think of adding a behavior description layer to
enforce a little more validation, but I fear the complexity (for
example) of validating stylesheets against a particular required
behavior.
IMO, only human try/fail and patching will allow interoperability.
o) VERSIONING AS PART OF THE BEHAVIOR URI
The behavior URI *MUST* terminate with a /x.y that indicates the
major.minor version of the behavior that a block implements.
On dependencies, each block must be able to specify the 'ranges' of
versioning that it is known to work with. For example
<block behavior="http://xml.apache.org/forrest/skin/1.x"
prefix="skin"/>
But I haven't really thought about the patterns that could be used for
this.
Please, help on this.
o) CROSS-BLOCK SECURITY
Even I don't think anybody is stupid enough to use a single Cocoon
instance to run a full ISP and ask for sandboxing of the single blocks,
cross-block security is a big concern, expecially since you might be
deploying components on the fly in a binary format.
So, first thing is to protect the /BLOCK-INF/ directory.
The second thing is to wrap each block with its own classloader,
connected to the block dependency map, so that each class discovery is
done only on the class space of the dependent blocks.
[NOTE: this doesn't prevent people from using blocks as trojans, but we
won't host blocks which don't come with the source code so we solve that
problem].
o) COCOON MANAGER SECURITY
The cocoon manager might be a block itself that connects to specific
cocoon internals and provides a web interface for it. So, it can be
removed or disabled when put on production.
Also, the feature of automatic discovery of blocks thru the 'cocoon
block library' can be turned off or substituted with its own (even the
'cocoon block library' could be a block, so you could have your own
block library on your system instead of connecting to the apache one).
o) OPTIONAL COP
The block.info file makes it *optional* to expose behaviors or to depend
on them. This allows the COP model to nicely downgrade to the good old
single-archive WAR paradigm for those who don't care about block
polymorphism.
Possible Problems
-----------------
1) classloading performance:
since classloading will become more complicated, it will be slower, but
this will impact only the startup performance not the runtime
performance so no real issues here.
2) possible reduced portability of Cocoon:
some servlet containers don't like servlets to come up with their own
classloaders. In those environments a block-enabled Cocoon might simply
not work. This doens't mean that Cocoon won't work, but that blocks
can't be deployed.
NOTE: the next servlet API might fix that by requiring a better
classloading behavior by the containers.
3) difficult block interoperability
without a way to automatically validate if a block implements a behavior
correctly, the type of that component is inherently weak and might lead
to problems that might become hard to fix.
The block manager *must* be able to *clone* a block and let you modify
one clone without disturbine the other. [but these are implementation
details and we'll see in the future how serious this problem becomes. in
fact, sitemap pipelines aren't validated as well but nobody had enough
itch to scratch this]
4) difficult transition
When we have blocks, it's easy to imagine that will exist pure-code
blocks that wrap around libraries and provide only sitemap components
(think FOP, POI, Batik and so on).
In that case, a 'naked Cocoon' becomes "de facto" back incompatible
because some sitemap components which are now included by default in
Cocoon) might not be present anymore, unless you wrap your code in
blocks and you depend explicitly on those blocks that expose that
specific behavior.
So, some working is required.
This might force us to call a block-enabled Cocoon: Cocoon 3.0
- o -
Conclusions
-----------
I think I have exposed a detailed plan on how to implement blocks and
solve a number of issues we are having:
1) allow users to 'compose' Cocoon only with those modules they need
2) allow users to easily deploy their stuff on cocoon
3) allow users to easily reuse web applications components without
sacrificing coherence
4) allow users to be helped by Cocoon to 'fill the gaps' and be
suggested on what components is best required and feed it automatically
(apt-get like)
5) allow the Cocoon communities to clearly separate concerns between
the core and the application-level stuff (a-la Zope)
6) allows, for the first time in the history of the web, to use
polymorphism and COP at a web application level.
That's all folks.
Fire your comments and try to tear it appart: I'm pretty confident this
is really a big thing for Cocoon!
--
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
Re: [RT] Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
Gerhard Froehlich wrote:
>
> Stefano Mazzocchi wrote:
>
> <skip/>
>
> > No, not remote code, but packages downloaded from remote locations (like
> > anybody has always been doing!).
> >
> > Think about it: you have apt-get, red-hat rpm updating, ximian
> > red-carpet, FreeBSD ports, Windows Update, Ecplise update manager, JEdit
> > plugins... just to name a few.
> >
> > I don't think nobody will ever mess with a production environment, but
> > during development, one might want to update the blocks used to the
> > latest bugfix releases, or even decide to use another implementation
> > (here is where polymorphism kicks in) of the block used before, because
> > it has, say, better performance or implements new features.
> >
> > Blocks will not only make it easier to deploy stuff on a production
> > environment, but also on development.
>
> Hmmm do we want to provide some security, like server/client
> certificates to sign the blocks?
>
> So that it is guaranteed that the blocks come from trusted servers and
> the components are allowed to use the local Cocoon Kernel services
> (Filesystem, Database, ...).
>
> Just a random thought.
Yes, I thought about it but I was considering this to be an
implementation detail (in fact, the java JAR infrastructure already
allows package signing)
--
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
RE: [RT] Cocoon Blocks
Posted by John Morrison <jo...@ntlworld.com>.
> From: Gerhard Froehlich [mailto:g-froehlich@gmx.de]
>
> Hmmm do we want to provide some security, like server/client
> certificates to sign the blocks?
XML Signature? Would that be OK?
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by Gerhard Froehlich <g-...@gmx.de>.
Stefano Mazzocchi wrote:
<skip/>
> No, not remote code, but packages downloaded from remote locations (like
> anybody has always been doing!).
>
> Think about it: you have apt-get, red-hat rpm updating, ximian
> red-carpet, FreeBSD ports, Windows Update, Ecplise update manager, JEdit
> plugins... just to name a few.
>
> I don't think nobody will ever mess with a production environment, but
> during development, one might want to update the blocks used to the
> latest bugfix releases, or even decide to use another implementation
> (here is where polymorphism kicks in) of the block used before, because
> it has, say, better performance or implements new features.
>
> Blocks will not only make it easier to deploy stuff on a production
> environment, but also on development.
Hmmm do we want to provide some security, like server/client
certificates to sign the blocks?
So that it is guaranteed that the blocks come from trusted servers and
the components are allowed to use the local Cocoon Kernel services
(Filesystem, Database, ...).
Just a random thought.
<skip/>
Greets
Gerhard
--
---------------------------------------------------------
I don't suffer from insanity. I enjoy every minute of it.
---------------------------------------------------------
Weblogging at: http://radio.weblogs.com/0107791/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Sylvain Wallez wrote:
>
>
<snip/>
>>Ok. I understand your concerns. So what about, for this particular case,
>>having 3 skins : a "super-skin" that's the one used by other blocks,
>>that dispatches to concrete skins depending on the environment ?
>>
>>
>
>Hmmm, define "dispatches" before I can answer.
>
>
Sorry, "delegates" should sound better.
The idea is that the "super-skin" chooses the actual skin depending on
the environment and delegates the actual work to that skin.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> >Good point. In that case, we might add another flag to the block
> >descriptor to indicate whether or not the sitemap should be mounted on a
> >URI space available to the outside.
> >
>
> An additional question related to external mount points : how do your
> envision them to be defined ? Will it like in web.xml or through a sitemap?
Since I consider this an implementation detail, I haven't thought about
it yet.
> I reused the current syntax for calling resources, but another one can
> be used. The important issue here is that we can have a pipeline defined
> across several sitemaps or blocks, which isn't possible today.
Correct. I'll be addressing the semantic problems I see in the current
sitemap shortly in another RT.
> Ok. I understand your concerns. So what about, for this particular case,
> having 3 skins : a "super-skin" that's the one used by other blocks,
> that dispatches to concrete skins depending on the environment ?
Hmmm, define "dispatches" before I can answer.
--
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
Re: [RT] Cocoon Blocks
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Sylvain Wallez wrote:
>
>
>>Stefano Mazzocchi wrote:
>>
<snip/>
>>Why should COBs be downloaded from a remote location ? Do you really
>>think people will allow remote code to run on their production servers ?
>>
>>
>
>No, not remote code, but packages downloaded from remote locations (like
>anybody has always been doing!).
>
>Think about it: you have apt-get, red-hat rpm updating, ximian
>red-carpet, FreeBSD ports, Windows Update, Ecplise update manager, JEdit
>plugins... just to name a few.
>
>I don't think nobody will ever mess with a production environment, but
>during development, one might want to update the blocks used to the
>latest bugfix releases, or even decide to use another implementation
>(here is where polymorphism kicks in) of the block used before, because
>it has, say, better performance or implements new features.
>
>Blocks will not only make it easier to deploy stuff on a production
>environment, but also on development.
>
>
Ok, I understand now.
<snip/>
>>It seems to me block mounting is in fact the configuration of a "root"
>>Processor component (the interface implemented by the sitemap) that
>>performs first-level dispatching between mounted blocks. This allows to
>>keep unchanged the architecture that exists today.
>>
>>
>
>I really don't know: I didn't want any technical details to constraint
>the design, so I didn't really look at how to implement it. But I'm
>pretty confident that it won't be hard to do given the current and very
>flexible architecture.
>
>
Ok.
>>Now I don't think all blocks should be mounted on an
>>externally-available URI : some blocks will provide only services to
>>other blocks and no external service. The sitemap for such blocks is
>>likely to contain only internal-only="true" pipelines, but then why
>>should we have to mount them on an external URI ?
>>
>>
>
>Good point. In that case, we might add another flag to the block
>descriptor to indicate whether or not the sitemap should be mounted on a
>URI space available to the outside.
>
An additional question related to external mount points : how do your
envision them to be defined ? Will it like in web.xml or through a sitemap ?
>>>For example, the forrest.cob/sitemap.xmap file could contain a global
>>>matcher which works like this:
>>>
>>> <map:match pattern="**/*.html">
>>> <map:aggregate element="site">
>>> <map:part src="cocoon:/{1}/book-{1}/{2}.xml"/>
>>> <map:part src="cocoon:/{1}/tab-{1}/{2}.xml"/>
>>> <map:part src="cocoon:/body-{1}/{2}.xml" label="content"/>
>>> </map:aggregate>
>>> <map:transform src="block:skin:/stylesheets/site2xhtml.xslt"/>
>>> <map:serialize/>
>>> </map:match>
>>>
>>>please note the
>>>
>>>block:skin:/stylesheets/site2xhtml.xslt
>>>
>>>
>>>
>>IMHO, this example goes strongly against the benefits that blocks want
>>to bring. The functionnality brought by the 'skin' block is... skinning.
>>It's not an XSL stylesheet at a particular location. What if someone has
>>written the killer skin for his site, but this skin requires a
>>multi-stage pipeline that cannot be represented by a single stylesheet ?
>>
>>The contract of a block should be services identified by their URI, and
>>not files at well-known locations (even if these 'files' are in fact
>>produced by a pipeline).
>>
>>
>
>Great point, Sylvain. I must admit I like your suggestion of forcing
>blocks to expose their capabilities via a URI space mapping, decoupling
>it from actual implementation makes perfect sense.
>
>I agree, accessing resources directly mixes concerns.
>
>
>
>>So what about something like :
>> ...
>> </map:aggregate>
>> <map:call resource="block:skin:/site2xhtml"/>
>></map:match>
>>
>>
>
>Hmmm...
>
>
>
>>This call "jumps" to a service provided by the block and its URI is part
>>of the block's contract. We don't care (because we don't have to) if the
>>service is implemented by an XSL or by the next-generation transformer.
>>
>>
>
>This is absolutely true, I agree, but this requires more thinking on the
>sitemap semantics (see below).
>
I reused the current syntax for calling resources, but another one can
be used. The important issue here is that we can have a pipeline defined
across several sitemaps or blocks, which isn't possible today.
<snip/>
>>Will it be possible to have several blocks fulfilling the same contract
>>in a single Cocoon instance?
>>
>>
>
>Absolutely! Since all contact between blocks is performed at the
>behavior level, it's Cocoon that knows what behavior instance is
>connected to each block. In fact, during update, I think it will be wise
>to make Cocoon keep an instance of the previous version of the block, so
>that if something weird happens, you can always go back to the previous
>version.
>
>
>
>>For example, a site could use different
>>skins depending on the user agent or depending on the location of the
>>client (intranet / internet).
>>
>>
>
>*NO*! that will definately break the elegance of the system! It should
>be the skin's concern to *know* how to skin the site.
>
>So, just like we are debating over at avalon-dev, you should *not* be
>using 'hints' for block lookup since you should *not* be knowing
>anything about the block you are depending from, except its behavior.
>
>
Ok. I understand your concerns. So what about, for this particular case,
having 3 skins : a "super-skin" that's the one used by other blocks,
that dispatches to concrete skins depending on the environment ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
>
> I envision a cocoon block management interface which capable of
> connecting to the central cocoon block library and check for updates of
> the blocks currently deployed on the running Cocoon.
BTW JJAR works for this and Centipede uses it with great pleasure.
I'd be glad to make Cocoon use JJAR :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
>
> Stefano Mazzocchi wrote:
>
> >Even if the flowscript discussion isn't finished, I think we have
> >reached an important conclusion on that side: a flowscript isn't a
> >sitemap replacer, but a sitemap augmenter.
> >
>
> A minor remark : could we avoid the use of "flowscript" or "flowmap"
> which imply the way they're implemented and speak simply of "flow" which
> only designates the functionality ?
Ok, no prob.
> Why should COBs be downloaded from a remote location ? Do you really
> think people will allow remote code to run on their production servers ?
No, not remote code, but packages downloaded from remote locations (like
anybody has always been doing!).
Think about it: you have apt-get, red-hat rpm updating, ximian
red-carpet, FreeBSD ports, Windows Update, Ecplise update manager, JEdit
plugins... just to name a few.
I don't think nobody will ever mess with a production environment, but
during development, one might want to update the blocks used to the
latest bugfix releases, or even decide to use another implementation
(here is where polymorphism kicks in) of the block used before, because
it has, say, better performance or implements new features.
Blocks will not only make it easier to deploy stuff on a production
environment, but also on development.
> It looks a lot like a Phoenix block .xinfo file. Couldn't the same
> syntax be used ? I'm don't know much about Phoenix services so this may
> be a silly question, but what could be the relationship between a Cocoon
> block and a Phoenix service ?
I still have to investigate this in detail but one thing is for sure: a
cocoon block *might* be an extension of an avalon block (please don't
call them "phoenix blocks" because Phoenix is just the codename of the
*implementation* of the block container).
I'll report on this later.
> Ok, here's the need for remote code. Although a catalog is good to help
> resolving dependencies and discover existing implementations, I'm still
> not sure about auto-deployment of downloaded code on production systems.
Nothing is *automatically* done, nothing happens behind your back. What
I envision is a block management interface on top of Cocoon that *helps*
you during the deployment by suggesting the location of the blocks that
implement the behaviors your own blocks depend upon.
There is no automatic deployment taking place: the deployer chooses what
package to install. The fact that is downloaded from an apache.org
domain or uploaded via web or found on the local file system is just a
detail and if you don't trust those components downloaded from the
outside, simply don't use them, but use your own on your local system.
Up to you, but Cocoon will *never* do something automatically behind
your back.
Also, note: it is possible to follow the Phoenix approach of having
Cocoon generate a 'service package', which is a collection of all the
blocks that make up your service and that you can deploy directly on a
production server without having the need to go around shopping for
blocks.
Anyway, please understand that these are just implementation details and
they do not limit the scope of the block design concept.
> > 5) Cocoon checks that all dependencies are met, then unpacks the blocks
> > 6) Since 'forrest.cob' exposes a sitemap, the deployment manager asks
> >the deploying user where he/she wants to *mount* that block in the
> >managed URI space.
> >
>
> It seems to me block mounting is in fact the configuration of a "root"
> Processor component (the interface implemented by the sitemap) that
> performs first-level dispatching between mounted blocks. This allows to
> keep unchanged the architecture that exists today.
I really don't know: I didn't want any technical details to constraint
the design, so I didn't really look at how to implement it. But I'm
pretty confident that it won't be hard to do given the current and very
flexible architecture.
> Now I don't think all blocks should be mounted on an
> externally-available URI : some blocks will provide only services to
> other blocks and no external service. The sitemap for such blocks is
> likely to contain only internal-only="true" pipelines, but then why
> should we have to mount them on an external URI ?
Good point. In that case, we might add another flag to the block
descriptor to indicate whether or not the sitemap should be mounted on a
URI space available to the outside.
> >For example, the forrest.cob/sitemap.xmap file could contain a global
> >matcher which works like this:
> >
> > <map:match pattern="**/*.html">
> > <map:aggregate element="site">
> > <map:part src="cocoon:/{1}/book-{1}/{2}.xml"/>
> > <map:part src="cocoon:/{1}/tab-{1}/{2}.xml"/>
> > <map:part src="cocoon:/body-{1}/{2}.xml" label="content"/>
> > </map:aggregate>
> > <map:transform src="block:skin:/stylesheets/site2xhtml.xslt"/>
> > <map:serialize/>
> > </map:match>
> >
> >please note the
> >
> > block:skin:/stylesheets/site2xhtml.xslt
> >
>
> IMHO, this example goes strongly against the benefits that blocks want
> to bring. The functionnality brought by the 'skin' block is... skinning.
> It's not an XSL stylesheet at a particular location. What if someone has
> written the killer skin for his site, but this skin requires a
> multi-stage pipeline that cannot be represented by a single stylesheet ?
>
> The contract of a block should be services identified by their URI, and
> not files at well-known locations (even if these 'files' are in fact
> produced by a pipeline).
Great point, Sylvain. I must admit I like your suggestion of forcing
blocks to expose their capabilities via a URI space mapping, decoupling
it from actual implementation makes perfect sense.
I agree, accessing resources directly mixes concerns.
> So what about something like :
> ...
> </map:aggregate>
> <map:call resource="block:skin:/site2xhtml"/>
> </map:match>
Hmmm...
> This call "jumps" to a service provided by the block and its URI is part
> of the block's contract. We don't care (because we don't have to) if the
> service is implemented by an XSL or by the next-generation transformer.
This is absolutely true, I agree, but this requires more thinking on the
sitemap semantics (see below).
> What the "jump" does is feed a pipeline in the block with the result of
> the current pipeline. The whole pipeline is terminated in the called block.
>
> But just as a pipeline can serialize or not depending on if it's an
> internal request or not (see SitemapSource), the same service could be
> used as a transformation. We could then write something like :
> ...
> </map:aggregate>
> <map:transform type="pipeline" src="block:skin:/site2xhtml"/>
> <map:transform type="urlencoder"/>
> <map:serialize/>
> </map:match>
>
> By considering blocks as pipeline services, we really achieve true
> polymorphism for blocks, because we totally abstract the way their
> contracts are implemented.
>
> [note that all the above isn't in fact block-specific and can be made
> today inside a single sitemap]
Exactly, the above is not block-specific. So I'll separate the
discussion an other thread (right after this email).
> Agree. Let's keep validation away for now and see in the future if it's
> really usefull and if/how it can be implemented.
Great.
> >o) VERSIONING AS PART OF THE BEHAVIOR URI
> >
> >The behavior URI *MUST* terminate with a /x.y that indicates the
> >major.minor version of the behavior that a block implements.
> >
> >On dependencies, each block must be able to specify the 'ranges' of
> >versioning that it is known to work with. For example
> >
> > <block behavior="http://xml.apache.org/forrest/skin/1.x"
> >prefix="skin"/>
> >
> >But I haven't really thought about the patterns that could be used for
> >this.
> >
> >Please, help on this.
> >
> >
>
> Once again, have you looked at Phoenix blocks ? The version of a block
> isn't in its name but as a separate attribute, and IIRC there are some
> features to check for version compatibility.
Yes, I'll report on cocoon/avalon block overlap soon.
> >o) OPTIONAL COP
> >
> >The block.info file makes it *optional* to expose behaviors or to depend
> >on them. This allows the COP model to nicely downgrade to the good old
> >single-archive WAR paradigm for those who don't care about block
> >polymorphism.
> >
> >
>
> This point is really important : people shouldn't have to package a COB
> and deploy it just to write a few pipelines. If a Processor
> implementation is used to mount blocks, this problem disappears as the
> current architecture is kept.
No, careful, I'm talking about something else here: you are stating that
COB (cocoon blocks) should be optional, while I was stating that COP
(component oriented programming) should be optional.
I agree that it should be possible to use Cocoon as we do today (read:
without knowing about blocks and application level componentization),
thus keeping back compatibility.
> >Possible Problems
> >-----------------
> >
> >1) classloading performance:
> >
> >since classloading will become more complicated, it will be slower, but
> >this will impact only the startup performance not the runtime
> >performance so no real issues here.
> >
> >
>
> Why will it be slower ? Because there's an additional classloader in the
> hierarchy ? As you say, this shouldn't be an issue.
Yep.
> >2) possible reduced portability of Cocoon:
> >
> >some servlet containers don't like servlets to come up with their own
> >classloaders. In those environments a block-enabled Cocoon might simply
> >not work. This doens't mean that Cocoon won't work, but that blocks
> >can't be deployed.
> >
> >NOTE: the next servlet API might fix that by requiring a better
> >classloading behavior by the containers.
> >
> >
>
> What about the note you wrote for the servlet JSR group ?
I didn't write it yet, but I'll do right away since there was no more
feedback.
> >3) difficult block interoperability
> >
> >without a way to automatically validate if a block implements a behavior
> >correctly, the type of that component is inherently weak and might lead
> >to problems that might become hard to fix.
> >
> >The block manager *must* be able to *clone* a block and let you modify
> >one clone without disturbine the other. [but these are implementation
> >details and we'll see in the future how serious this problem becomes. in
> >fact, sitemap pipelines aren't validated as well but nobody had enough
> >itch to scratch this]
> >
> >4) difficult transition
> >
> >When we have blocks, it's easy to imagine that will exist pure-code
> >blocks that wrap around libraries and provide only sitemap components
> >(think FOP, POI, Batik and so on).
> >
> >In that case, a 'naked Cocoon' becomes "de facto" back incompatible
> >because some sitemap components which are now included by default in
> >Cocoon) might not be present anymore, unless you wrap your code in
> >blocks and you depend explicitly on those blocks that expose that
> >specific behavior.
> >
> >So, some working is required.
> >
> >
>
> Is this really an issue ? People that want to use FOP or Batik without
> blocks can still put these blocks libs into the good old WEB-INF/lib to
> have the behaviour we have today.
Yes, but I was thinking about removing, say, the FOPSerializer class
implementation and place it inside the block.... but I see that, even if
architecturally cleaner, it might create more problems that those
solved.
> >This might force us to call a block-enabled Cocoon: Cocoon 3.0
> >
> >
>
> Or 2.2 if the architecture is backwards compatible, which seems to be
> possible.
Yes, it's possible. I agree.
> Sure this is a big thing ! Here are some additional random thoughts :
>
> How to "discover" available blocks to automatically update the structure
> of a portal site ?
I envision a cocoon block management interface which capable of
connecting to the central cocoon block library and check for updates of
the blocks currently deployed on the running Cocoon.
Note: nothing happens behind your back, just it prompts you that there
are newer compatible releases of the blocks you are currently using and
that he might feed them for you and install them. Given the advanced
classloading and request handling architecture we will need for blocks,
this could also be done at runtime without needing to stop the service
Cocoon provides (much like the asynchronous sitemap recompilation we
have).
> Will it be possible to have several blocks fulfilling the same contract
> in a single Cocoon instance?
Absolutely! Since all contact between blocks is performed at the
behavior level, it's Cocoon that knows what behavior instance is
connected to each block. In fact, during update, I think it will be wise
to make Cocoon keep an instance of the previous version of the block, so
that if something weird happens, you can always go back to the previous
version.
> For example, a site could use different
> skins depending on the user agent or depending on the location of the
> client (intranet / internet).
*NO*! that will definately break the elegance of the system! It should
be the skin's concern to *know* how to skin the site.
So, just like we are debating over at avalon-dev, you should *not* be
using 'hints' for block lookup since you should *not* be knowing
anything about the block you are depending from, except its behavior.
--
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
Re: [RT] Cocoon Blocks
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Even if the flowscript discussion isn't finished, I think we have
>reached an important conclusion on that side: a flowscript isn't a
>sitemap replacer, but a sitemap augmenter.
>
A minor remark : could we avoid the use of "flowscript" or "flowmap"
which imply the way they're implemented and speak simply of "flow" which
only designates the functionality ?
<large-snip/>
> - o -
>
>I'm pretty sure that if I stopped here and went on describing the schema
>of the COB descriptor file and so on, people would love it, thank me,
>run to their boss to tell them and blah blah..
>
>Sure, we could stop here, we could clone the WAR concept inside Cocoon,
>allow you to deploy your stuff and you won't be missing anything.
>
>But there is one thing that the servlet API architects didn't consider
>(not even myself at that time since I was part of that group):
>polymorphism.
>
>Ok, a few blank lines so you think about it....
>
>
Oh, my, what a suspense ;-)
>
>
>
>
>
>
>
>
>what does it mean to have a polymorphic package?
>
>
Please, please, explain us ;-))
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Applying Avalon COP philosophy over again
>-----------------------------------------
>
>
Phewww... Here comes the answer ;-D
>If ever worked with Avalon, you know the feeling: at first it doesn't
>make any sense at all. It's a mess of stupid and very abstract
>interfaces... but after a while, a patter emerges and it sticks.
>
The same can be said about Cocoon : the first time I encountered it (it
was 1.7.4), I didn't understand, but had the feeling there was something
interesting in it, and gave it a try... Two years after, I'm still there :)
>Some might think that Avalon (probably Cocoon itself) includes infecting
>'memes' and I agree. [Look up the name on google if you don't know what
>I'm talking about]
>
>Once you start using COP (component oriented programming), it's very
>hard to go back (so much so that many abuse it and over-componentize
>their systems... even Cocoon itself suffers from this problem on some
>parts).
>
>COP is based on IoC (Inversion of Control) and SoC (Separation of
>Concerns) [for those who still don't know about them!] and while the
>servlet API makes extensive use of the IoC metapattern, SoC doesn't play
>a clear and defined role (they tried to patch it with RequestDispatcher,
>which is the biggest hack I ever seen, I even voted against it but I was
>overruled).
>
>Anyway, if the servlet API, internally, show use of IoC and SoC,
>externally, from the WAR point of view, there is *absolutely* no notion
>of it: a WAR is a package that includes a single and isolated
>application.
>
>Period. That's it. There are many mechanism that enforce the clear
>separation between different WARs. So, they implement monolithic web
>applications and this is *by design*.
>
>A step up: Blocks as cocoon application components
>--------------------------------------------------
>
>If we design cocoon blocks as 'isolated units of application deployment'
>we fall back in the good old web trap: making web applications
>interoperate in the same URI space is a MAJOR PITA with *ANY* web
>technology.
>
>I'm talking about making Bugzilla and Horde IMP share the same look and
>feel. Try it!
>
>'coherence' is a value, expecially on professional sites, but coherence
>shouldn't mean that everything has to be written by the same team!
>
>Sure, I want Cocoon blocks to ease deployment of cocoon-based web
>applications, but this is a secondary byproduct: what I really want is
>to make it possible to *share* cocoon web applications as we currently
>do with Avalon components.
>
> - o -
>
>Ok, enough introduction, let's get to the meat.
>
>WARNING: what follows is the result of ideas collected from many people,
>and was cleared in all parts with real-life discussion between Giacomo
>and myself a few weeks ago. Anyway, what follows is still part of the RT
>flow, so it must only be considered as a proposal and not something
>carved in stone.
>
>Cocoon Blocks
>-------------
>
>A Cocoon block is a zipped archive, just like JARs and WARs.
>
>The extension of a cocoon block is .cob (for COcoon Block). The MIME
>type is yet to be determined (might be required for over-the-net block
>download).
>
Why should COBs be downloaded from a remote location ? Do you really
think people will allow remote code to run on their production servers ?
>A Cocoon Block (COB from now on) includes a directory called
>
> /BLOCK-INF
>
>which contains all the block metadata and the resources that must not be
>directly referentiable from other blocks (for example, jars, classes or
>file resources made available thru the classloader). The directories
>
> /BLOCK-INF/classes
> /BLOCK-INF/jar
>
>are used for classes and jar files. This follows the WAR paradigm.
>
>The main COB descriptor file is found at
>
> /BLOCK-INF/block.info
>
>[FIXME: can this create conflicts with Avalon blocks?]
>
>This file MUST be an XML file, containing markup with a cob-specific
>namespace and will include the following information:
>
> 1) block implementation metadata (name, author, license, URL of the
>project and so on)
> 2) role(s): the URI(s) of the behavioral role(s) this block implements
>and exposes [optional]
> 3) dependencies: the URI(s) of the behavioral roles this block expects,
>along with the prefixes used by the block as shortcuts in protocol
>resolvin (see below for the meaning of this)
>[optional]
> 4) sitemap: the location inside the block file space of the sitemap
>[optional]
>
>Visually, the block metadata can be pictured like this:
>
>
> implementation metadata
> ^
> |
> (exposed behaviors)? <---- [block] ----> (required behaviors)?
>
>Also, the /BLOCK-INF/ directory contains the 'roles' file for Avalon
>components:
>
> /BLOCK-INF/block.roles
>
>
>What is a 'block behavior'?
>---------------------------
>
>If you are familiar with Avalon, you probably understood the idea (it's
>very similar to the concept of Avalon roles), but if not it might be a
>little difficult, so let me write you an example of this:
>
>let's take Forrest and let it decouple in two blocks:
>
> 1) one block provides the document production
> 2) another block provides the skinning and presentation layers
>
>Currently, it is already done like this, but the change of the skin
>(this is how the second block is currently called) must be done by hand:
>there is no cocoon machinery in place to make this possible.
>
>So, let us assume the machinery is now in place:
>
>forrest itself becomes a block, but in order to function, it needs
>access to the stylesheets contained in the skin, which, in order to
>simplify decoupling, we want to implement as another block.
>
>Result:
>
> forrest.cob/BLOCK-INF/block.info
>
>is something like
>
> <block>
> <metadata>
> <name>Forrest</name>
> <organization>ASF</organization>
> ...
> </metadata>
> <dependencies>
> <block behavior="http://xml.apache.org/forrest/skin/1.0"
>prefix="skin"/>
> </dependencies>
> <sitemap location="sitemap.xmap"/>
> </block>
>
>
It looks a lot like a Phoenix block .xinfo file. Couldn't the same
syntax be used ? I'm don't know much about Phoenix services so this may
be a silly question, but what could be the relationship between a Cocoon
block and a Phoenix service ?
>while:
>
> skin.cob/BLOCK-INF/block.info
>
>is something like
>
> <block>
> <metadata>
> <name>Xmas Skin</name>
> ...
> </metadata>
> <behaviors>
> <behavior uri="http://xml.apache.org/forrest/skin/1.0"/>
> </behaviors>
> </block>
>
>Now: suppose you have your naked cocoon running in your favorite servlet
>container, and you want to deploy forrest.cob, here is a possible
>sequence of actions on an hypotetical web interface on top of Cocoon
>(a-la Tomcat Manager)
>
> 1) upload the forrest.cob to Cocoon
> 2) Cocoon scans /BLOCK-INF/, reads block.info and finds out that
>Forrest depends on a block which the given role
> 3) then it connects to the uber "Cocoon Block Librarian" web service
>(hosted somewhere around *.apache.org) and asks for the list of blocks
>that exhibit that required behavior.
> 4) the librarian returns a list of those blocks, so the users chooses,
>or the manager allows the user to deploy its own block that implements
>the required behavior.
>
Ok, here's the need for remote code. Although a catalog is good to help
resolving dependencies and discover existing implementations, I'm still
not sure about auto-deployment of downloaded code on production systems.
> 5) Cocoon checks that all dependencies are met, then unpacks the blocks
> 6) Since 'forrest.cob' exposes a sitemap, the deployment manager asks
>the deploying user where he/she wants to *mount* that block in the
>managed URI space.
>
It seems to me block mounting is in fact the configuration of a "root"
Processor component (the interface implemented by the sitemap) that
performs first-level dispatching between mounted blocks. This allows to
keep unchanged the architecture that exists today.
Now I don't think all blocks should be mounted on an
externally-available URI : some blocks will provide only services to
other blocks and no external service. The sitemap for such blocks is
likely to contain only internal-only="true" pipelines, but then why
should we have to mount them on an external URI ?
> 7) If no collisions in the URI spaces are found, the blocks are made
>available for servicing. [note: the skin block doesn't exposes a sitemap
>so it's not mounted on the URI space]
>
>A big issue: resource dereferencing
>-----------------------------------
>
>Security concerns aside, the above scenario shows one major issue:
>blocks are managed, deployed and mounted by the container. There is (and
>there should not be) a way for a block to directly access another block
>because this would ruin IoC.
>
>So, one block doesn't know where the blocks it depends on are located,
>both on disk *and* on the URI space as well.
>
>The proposed solution is to use block-specific protocols to identify the
>dereferenced resources.
>
>For example, the forrest.cob/sitemap.xmap file could contain a global
>matcher which works like this:
>
> <map:match pattern="**/*.html">
> <map:aggregate element="site">
> <map:part src="cocoon:/{1}/book-{1}/{2}.xml"/>
> <map:part src="cocoon:/{1}/tab-{1}/{2}.xml"/>
> <map:part src="cocoon:/body-{1}/{2}.xml" label="content"/>
> </map:aggregate>
> <map:transform src="block:skin:/stylesheets/site2xhtml.xslt"/>
> <map:serialize/>
> </map:match>
>
>please note the
>
> block:skin:/stylesheets/site2xhtml.xslt
>
IMHO, this example goes strongly against the benefits that blocks want
to bring. The functionnality brought by the 'skin' block is... skinning.
It's not an XSL stylesheet at a particular location. What if someone has
written the killer skin for his site, but this skin requires a
multi-stage pipeline that cannot be represented by a single stylesheet ?
The contract of a block should be services identified by their URI, and
not files at well-known locations (even if these 'files' are in fact
produced by a pipeline).
So what about something like :
...
</map:aggregate>
<map:call resource="block:skin:/site2xhtml"/>
</map:match>
This call "jumps" to a service provided by the block and its URI is part
of the block's contract. We don't care (because we don't have to) if the
service is implemented by an XSL or by the next-generation transformer.
What the "jump" does is feed a pipeline in the block with the result of
the current pipeline. The whole pipeline is terminated in the called block.
But just as a pipeline can serialize or not depending on if it's an
internal request or not (see SitemapSource), the same service could be
used as a transformation. We could then write something like :
...
</map:aggregate>
<map:transform type="pipeline" src="block:skin:/site2xhtml"/>
<map:transform type="urlencoder"/>
<map:serialize/>
</map:match>
By considering blocks as pipeline services, we really achieve true
polymorphism for blocks, because we totally abstract the way their
contracts are implemented.
[note that all the above isn't in fact block-specific and can be made
today inside a single sitemap]
>which indicates
>
> block -> use the block protocol
> skin -> use the 'skin' prefix to lookup the block behavior URI and thus
>the block which implements it for this block (the block manager knows
>this)
> /stylesheets/site2xhtml.xslt -> since the 'skin' block doesn't expose a
>sitemap, give me the file located in that position of the internal block
>file space (except /BLOCK-INF/ which is protected)
>
>[in case the block exposes a sitemap, the block: protocol connects to
>the URI space exposed by the sitemap... before you start suggesting a
>block-raw: protocol to get access to that, think twice because, to me,
>it smells like FS a lot!]
>
>Dereferencing navigation
>------------------------
>
>Not only a sitemap needs to connect to the resources contained in the
>blocks on which the block depends on, but the resulting pages as well.
>
>In fact, suppose you have a block that exposes a web service and another
>one that exposes a web application that wraps that web service. For
>sure, the generated web page will have to have a URI to connect to that
>service, since it's the client's browser that makes the call (unless we
>want to virtualize everything thru the sitemaps, but I wouldn't suggest
>it).
>
>So, a possible solution is to use the "block:" protocol in the pages as
>well and have a URI-mapping transformer right before the serialization
>stage.
>
>For example, things like
>
><form action="block:web-service:/post">...</form>
>
>is trasnformed into
>
><form action="/servizio-web/post"/>...</form>
>
> - 0 -
>
>Some design decision taken
>--------------------------
>
>
>o) NO BEHAVIOR VALIDATION:
>
>I thought a lot about it but I think that having 'behavior description
>languages' (such as the WSDL-equivalent for blocks) is going to be
>terribly complicated, expensive to implement and hard to use and
>enforce, even for simple blocks which don't expose a sitemap and are
>just repositories for informations.
>
>For this reason, there is no validation taking place: if a block
>implements a particular behavior and exposes it thru its descriptor
>file, Cocoon automatically assume it implements the behavior correctly.
>
>In the future, we might think of adding a behavior description layer to
>enforce a little more validation, but I fear the complexity (for
>example) of validating stylesheets against a particular required
>behavior.
>
>IMO, only human try/fail and patching will allow interoperability.
>
>
Agree. Let's keep validation away for now and see in the future if it's
really usefull and if/how it can be implemented.
>o) VERSIONING AS PART OF THE BEHAVIOR URI
>
>The behavior URI *MUST* terminate with a /x.y that indicates the
>major.minor version of the behavior that a block implements.
>
>On dependencies, each block must be able to specify the 'ranges' of
>versioning that it is known to work with. For example
>
> <block behavior="http://xml.apache.org/forrest/skin/1.x"
>prefix="skin"/>
>
>But I haven't really thought about the patterns that could be used for
>this.
>
>Please, help on this.
>
>
Once again, have you looked at Phoenix blocks ? The version of a block
isn't in its name but as a separate attribute, and IIRC there are some
features to check for version compatibility.
>o) CROSS-BLOCK SECURITY
>
>Even I don't think anybody is stupid enough to use a single Cocoon
>instance to run a full ISP and ask for sandboxing of the single blocks,
>cross-block security is a big concern, expecially since you might be
>deploying components on the fly in a binary format.
>
>So, first thing is to protect the /BLOCK-INF/ directory.
>
>The second thing is to wrap each block with its own classloader,
>connected to the block dependency map, so that each class discovery is
>done only on the class space of the dependent blocks.
>
>[NOTE: this doesn't prevent people from using blocks as trojans, but we
>won't host blocks which don't come with the source code so we solve that
>problem].
>
>
>o) COCOON MANAGER SECURITY
>
>The cocoon manager might be a block itself that connects to specific
>cocoon internals and provides a web interface for it. So, it can be
>removed or disabled when put on production.
>
>Also, the feature of automatic discovery of blocks thru the 'cocoon
>block library' can be turned off or substituted with its own (even the
>'cocoon block library' could be a block, so you could have your own
>block library on your system instead of connecting to the apache one).
>
>
>o) OPTIONAL COP
>
>The block.info file makes it *optional* to expose behaviors or to depend
>on them. This allows the COP model to nicely downgrade to the good old
>single-archive WAR paradigm for those who don't care about block
>polymorphism.
>
>
This point is really important : people shouldn't have to package a COB
and deploy it just to write a few pipelines. If a Processor
implementation is used to mount blocks, this problem disappears as the
current architecture is kept.
>Possible Problems
>-----------------
>
>1) classloading performance:
>
>since classloading will become more complicated, it will be slower, but
>this will impact only the startup performance not the runtime
>performance so no real issues here.
>
>
Why will it be slower ? Because there's an additional classloader in the
hierarchy ? As you say, this shouldn't be an issue.
>2) possible reduced portability of Cocoon:
>
>some servlet containers don't like servlets to come up with their own
>classloaders. In those environments a block-enabled Cocoon might simply
>not work. This doens't mean that Cocoon won't work, but that blocks
>can't be deployed.
>
>NOTE: the next servlet API might fix that by requiring a better
>classloading behavior by the containers.
>
>
What about the note you wrote for the servlet JSR group ?
>3) difficult block interoperability
>
>without a way to automatically validate if a block implements a behavior
>correctly, the type of that component is inherently weak and might lead
>to problems that might become hard to fix.
>
>The block manager *must* be able to *clone* a block and let you modify
>one clone without disturbine the other. [but these are implementation
>details and we'll see in the future how serious this problem becomes. in
>fact, sitemap pipelines aren't validated as well but nobody had enough
>itch to scratch this]
>
>4) difficult transition
>
>When we have blocks, it's easy to imagine that will exist pure-code
>blocks that wrap around libraries and provide only sitemap components
>(think FOP, POI, Batik and so on).
>
>In that case, a 'naked Cocoon' becomes "de facto" back incompatible
>because some sitemap components which are now included by default in
>Cocoon) might not be present anymore, unless you wrap your code in
>blocks and you depend explicitly on those blocks that expose that
>specific behavior.
>
>So, some working is required.
>
>
Is this really an issue ? People that want to use FOP or Batik without
blocks can still put these blocks libs into the good old WEB-INF/lib to
have the behaviour we have today.
>This might force us to call a block-enabled Cocoon: Cocoon 3.0
>
>
Or 2.2 if the architecture is backwards compatible, which seems to be
possible.
> - o -
>
>Conclusions
>-----------
>
>I think I have exposed a detailed plan on how to implement blocks and
>solve a number of issues we are having:
>
> 1) allow users to 'compose' Cocoon only with those modules they need
> 2) allow users to easily deploy their stuff on cocoon
> 3) allow users to easily reuse web applications components without
>sacrificing coherence
> 4) allow users to be helped by Cocoon to 'fill the gaps' and be
>suggested on what components is best required and feed it automatically
>(apt-get like)
> 5) allow the Cocoon communities to clearly separate concerns between
>the core and the application-level stuff (a-la Zope)
> 6) allows, for the first time in the history of the web, to use
>polymorphism and COP at a web application level.
>
>That's all folks.
>
>Fire your comments and try to tear it appart: I'm pretty confident this
>is really a big thing for Cocoon!
>
>
Sure this is a big thing ! Here are some additional random thoughts :
How to "discover" available blocks to automatically update the structure
of a portal site ?
Will it be possible to have several blocks fulfilling the same contract
in a single Cocoon instance ? For example, a site could use different
skins depending on the user agent or depending on the location of the
client (intranet / internet). This could be handled by the root
Processor that handles block mounting.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Separation to Phoenix and Avalon 5 [was Re: [RT] Cocoon Blocks]
Posted by Stefano Mazzocchi <st...@apache.org>.
Gerhard Froehlich wrote:
>
> Hi Stefano,
> can you give a clear separation to Phoenix and Avalon 5?
Sorry, I can't really parse the question.
What do you mean?
--
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
Separation to Phoenix and Avalon 5 [was Re: [RT] Cocoon Blocks]
Posted by Gerhard Froehlich <g-...@gmx.de>.
Hi Stefano,
can you give a clear separation to Phoenix and Avalon 5?
Greets
Gerhard
--
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
Weblogging at: http://radio.weblogs.com/0107791/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
"J.Pietschmann" wrote:
>
> Stefano Mazzocchi wrote:
> > Good point.
> >
> > +1 for block.xinfo
> >
> Hmm. Beyond .xml, .xsl, . xhtml and .fo there ought to
> be .xconf, .xmap, .xtarget (yuck!) and now .xinfo
> extensions associated with the XML edit mode.
> It's getting out of hand.
> What's wrong with sitemap.xml and blockinfo.xml?
Hmmm, that's a pretty good point, I might say.
> Rationale
> - there is only one web application description file
> in a context, and Sun choose web.xml.
> - there is usually only one build description file
> in a context, and Ant uses build.xml. Even though
> multiple build description files could be put into
> the same directory, the usual scope is a "project",
> and "projects" tend to have their own directory
> subtree.
> - there is only one sitemap in one context. Even though
> multiple sitemaps could be put into the same
> directory, subsitemaps tend to have their own
> directory subtree. The situation is quite similar
> to the Ant build description files.
> - there should only be one block info in one context
> (the block). Unless I got something very wrong, the
> situation is quite to the web.xml situation.
> The .xconf is ok:
> - there can be more than one configuration file in
> one context (cocoon, logkit, fop)
> - multiple .xcconf files may be in the same directory
> - cocoon.xconf is more informative than cocoon.xml,
> and easier to handle that cocoon-config.xml
> Caveat: the extension doesn't say anything about the
> XML schema used, cocoon.xconf likely needs an other
> DTD than logkit.xconf.
You say that the extension doesn't say anything about the XML Schema
used. Well, this is not really the case. Examples are
.xsd
.xslt
.xsl
.svg
.xmap
Now, the point is: having extension-triggered behavior is a *huge*
design mistake that some operating systems do (windows, first of all,
but also some UNIX desktop do the same mistake): the name of the file
should *not* indicate anything about the *nature* of the file. It should
be stored either inside (as for UNIX scripts with #!/bin/sh) or
elsewhere (as in MacOS, somewhere on in the file system FAT)
XML files have the ability to identify themselves precisely, so, in
theory, we should *not* need any special extensions for XML (or just use
.xml to indicate that xml is the syntax used).
Unfortunately, we don't live in a perfect world.
So, I agree that well-formed XML files should *not* include any special
extensions.... but valid XML files, which have such a special semantics
that special editing tools might be required for them, should.
Using this simple design pattern, I agree that 'block.xinfo' doesn't
really need an extension different from .xml
--
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
Re: [RT] Cocoon Blocks
Posted by Nicola Ken Barozzi <ni...@apache.org>.
J.Pietschmann wrote:
...
> BTW the .xtarget files from forrest are ectually
> external entities, not even XML (yuck! again).
That's why I didn't use .xml
The sucky name had to match the sucky hack ;-)
> Entities suck. Isn't there a way to use <ant>
> for structuring the build description?
There is, and in fact the beta 2 of Centipede does just that.
But this also makes the build slower and uses more memory.
I have submitted a patch to Ant to support <import file="filename"/>,
and with the help of others it's becoming more and more polished :-)
So yes, the entities will go away :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Nicola Ken Barozzi wrote:
> I started using name.dtd.extension so I got (instead of the yucked
> .xtarget ;-P) file.target.xml
>
> But some users didn't like it, so I just kept file.xml
Wise. If you edit an XML file, it will likely stay an
XML file, but it's content might have change so that
it no longer matches the DTD. Including some hints on
what DTD/schema is used into the file name may be
misleading after a while. And there is the pain of
renaming files under source code control...
BTW the .xtarget files from forrest are ectually
external entities, not even XML (yuck! again).
Entities suck. Isn't there a way to use <ant>
for structuring the build description?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Koen Pellegrims wrote:
> Score: insightful
>
> ... and I agree... It gets very tedious to associate these extensions with
> XML editing-mode in XML Spy, and vi and JBuilder and... (catch my drift...)
> and there is no real added value in creating these new extensions...
I started using name.dtd.extension so I got (instead of the yucked
.xtarget ;-P) file.target.xml
But some users didn't like it, so I just kept file.xml
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Cocoon Blocks
Posted by Koen Pellegrims <ko...@pandora.be>.
Score: insightful
... and I agree... It gets very tedious to associate these extensions with
XML editing-mode in XML Spy, and vi and JBuilder and... (catch my drift...)
and there is no real added value in creating these new extensions...
K.
-----Oorspronkelijk bericht-----
Van: J.Pietschmann [mailto:j3322ptm@yahoo.de]
Verzonden: dinsdag 2 juli 2002 21:05
Aan: cocoon-dev@xml.apache.org
Onderwerp: Re: [RT] Cocoon Blocks
Stefano Mazzocchi wrote:
> Good point.
>
> +1 for block.xinfo
>
Hmm. Beyond .xml, .xsl, . xhtml and .fo there ought to
be .xconf, .xmap, .xtarget (yuck!) and now .xinfo
extensions associated with the XML edit mode.
It's getting out of hand.
What's wrong with sitemap.xml and blockinfo.xml?
Rationale
- there is only one web application description file
in a context, and Sun choose web.xml.
- there is usually only one build description file
in a context, and Ant uses build.xml. Even though
multiple build description files could be put into
the same directory, the usual scope is a "project",
and "projects" tend to have their own directory
subtree.
- there is only one sitemap in one context. Even though
multiple sitemaps could be put into the same
directory, subsitemaps tend to have their own
directory subtree. The situation is quite similar
to the Ant build description files.
- there should only be one block info in one context
(the block). Unless I got something very wrong, the
situation is quite to the web.xml situation.
The .xconf is ok:
- there can be more than one configuration file in
one context (cocoon, logkit, fop)
- multiple .xcconf files may be in the same directory
- cocoon.xconf is more informative than cocoon.xml,
and easier to handle that cocoon-config.xml
Caveat: the extension doesn't say anything about the
XML schema used, cocoon.xconf likely needs an other
DTD than logkit.xconf.
HTH
J.Pietschmann
---------------------------------------------------------------------
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: [RT] Cocoon Blocks
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremy Quinn wrote:
> FYI. In <slash-edit/> I get the user to keep both their 'publishing'
> sitemap and their 'editing' sitemap in the same folder so that they can
> both access the same resources.
Well, it was meant in this sense
- there are contexts where there is exactly one file
with a given name by definition, like web.xml.
- there are contexts where there is *usually* only
one file with a certain semantics in a directory
related to the context. Ant's build.xml is usually
in the project subtree root directory. This does not
mean that there aren't alternative build descriptions
(build.xml, build-jdk1.4.xml,...), or that someone
chooses to put the build files for all subprojects
into a build/ directory. This doesn't really matter
because build.xml is the default only and different
names can be used.
In the same sense, there can be differenly named
sitemap files used. In fact, there is no real default
hardcoded into Cocoon for sitemap files, the name must
be always explicitely specified.
Does this help?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by Jeremy Quinn <sh...@mac.com>.
On Tuesday, July 2, 2002, at 08:04 PM, J.Pietschmann wrote:
> - there is only one sitemap in one context. Even though
> multiple sitemaps could be put into the same
> directory, subsitemaps tend to have their own
> directory subtree. The situation is quite similar
> to the Ant build description files.
>
FYI. In <slash-edit/> I get the user to keep both their
'publishing' sitemap and their 'editing' sitemap in the same
folder so that they can both access the same resources.
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Stefano Mazzocchi wrote:
> Good point.
>
> +1 for block.xinfo
>
Hmm. Beyond .xml, .xsl, . xhtml and .fo there ought to
be .xconf, .xmap, .xtarget (yuck!) and now .xinfo
extensions associated with the XML edit mode.
It's getting out of hand.
What's wrong with sitemap.xml and blockinfo.xml?
Rationale
- there is only one web application description file
in a context, and Sun choose web.xml.
- there is usually only one build description file
in a context, and Ant uses build.xml. Even though
multiple build description files could be put into
the same directory, the usual scope is a "project",
and "projects" tend to have their own directory
subtree.
- there is only one sitemap in one context. Even though
multiple sitemaps could be put into the same
directory, subsitemaps tend to have their own
directory subtree. The situation is quite similar
to the Ant build description files.
- there should only be one block info in one context
(the block). Unless I got something very wrong, the
situation is quite to the web.xml situation.
The .xconf is ok:
- there can be more than one configuration file in
one context (cocoon, logkit, fop)
- multiple .xcconf files may be in the same directory
- cocoon.xconf is more informative than cocoon.xml,
and easier to handle that cocoon-config.xml
Caveat: the extension doesn't say anything about the
XML schema used, cocoon.xconf likely needs an other
DTD than logkit.xconf.
HTH
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
"J.Pietschmann" wrote:
>
> > /BLOCK-INF/block.info
>
> Can you please name it block.xml, or at least block.xinfo,
> or perhaps blockinfo.xml. The extension .info is already
> reserved in Emacs.
Good point.
+1 for block.xinfo
--
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
Re: [RT] Cocoon Blocks
Posted by "J.Pietschmann" <j3...@yahoo.de>.
> /BLOCK-INF/block.info
Can you please name it block.xml, or at least block.xinfo,
or perhaps blockinfo.xml. The extension .info is already
reserved in Emacs.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
Tony Collen wrote:
>
> Stefano Mazzocchi wrote:
>
> <snip/>
>
> >Fire your comments and try to tear it appart: I'm pretty confident this
> >is really a big thing for Cocoon!
> >
>
> Pardon my ignorance, but what is the origin of the term "block"? From
> what I read, its just a module, or a plugin... how about calling it a
> plugin or a module? :) Seriously though, there was a mention of "new
> terminology" over on the big thread on Cocoon-Users, so perhaps calling
> block plugins or modules would be a little more descriptive? Just some
> thoughts. I look forward to wrapping my head around whatever they're
> called :)
Good point.
Blocks come from the microelectronic world where 'chuncks of logic' are
called blocks, just like there are blocks in the city and so on.
The alternative was to use 'brick' as in good old Lego sense.
I don't like plugin, because a plugin is something that you plug-in to
increase the functionality of a basic application. Example: Photoshop is
functional even without plugins, a naked Cocoon wouldn't do anything
without blocks.
Component is already taken from the avalon world and it's too
software-oriented (look at COM, DCOM, CORBA, COP and friends)
Module is admittedly a good suggestion.
Anyway, "block", like anything else in the RT is to be considered a
suggestion and I'm not married with anything there. So if there is
agreement we can change even the name.
--
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
Re: [RT] Cocoon Blocks
Posted by Tony Collen <tc...@hist.umn.edu>.
Stefano Mazzocchi wrote:
<snip/>
>Fire your comments and try to tear it appart: I'm pretty confident this
>is really a big thing for Cocoon!
>
Pardon my ignorance, but what is the origin of the term "block"? From
what I read, its just a module, or a plugin... how about calling it a
plugin or a module? :) Seriously though, there was a mention of "new
terminology" over on the big thread on Cocoon-Users, so perhaps calling
block plugins or modules would be a little more descriptive? Just some
thoughts. I look forward to wrapping my head around whatever they're
called :)
Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Blocks
Posted by Jeremy Quinn <sh...@mac.com>.
On Friday, June 28, 2002, at 06:04 PM, Stefano Mazzocchi wrote:
> Fire your comments and try to tear it appart: I'm pretty confident this
> is really a big thing for Cocoon!
>
Followed by loud applaud from the gallery, calls of 'Bravo'! 'Bravo'!
Many thanks to Stefano, Giacomo et al. for their perseverance.
I need some time to assimilate this .....
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org