cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] Cocoon web applications
Date Tue, 02 Oct 2001 14:56:01 GMT
There is a lot to discuss, and I will try to rim the fat as I go along.  First,
let me say that having you back, Stefano, is great!  With a little iron sharpening
iron, we will have an excellent tool.

Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
> >
> > I am working on a way to make the ExcaliburComponentManager more resource
> > friendly, and really help.  There are some issues to work out, but as that
> > is an Avalon Excalibur optimization, I would prefer to discuss those details
> > on the Avalon developer's list.
> Ok, I'll resubscribe to that list (haven't done so yet).

So far it's in my head, and I haven't had the time to put it out there.  I have
a couple of proposals in my head right now.  Let me know when you subscribe to
Avalon's list, and I will put them out there (spoiler: it is resource management,
self-healing configuration files, and component tracking [for debug purposes]).

> > Automatic discovery and deployment of Cocoon webapps requires
> > that we allow our URI space to be at the mercy of your deployment tool.
> This is where I disagree.
> I never used the word "automatic" because what I described (not even
> proposed, just thrown out as a RT to bootstrap a discussion) is a system
> that allows you to install web applications in a manner which is
> (presumably) more friendly than the rough and undesigned way we do today
> that follows the implicit assumptions that Servlet API make that one WAR
> file = one web application.

Ok.  I can agree with that statement.  Keep in mind that for Cocoon
app installation you have to modify both the unarchived war and the
archived war file.  The reason is that SOME servlet containers ignore
the original war file once it is deployed.  SOME servlet containers
overwrite the contents of the directory with the contents of the war
file.  And still OTHERS act like the second scenario until the unarchived
directory is modified.

Don't you just love it when there is no standard?

> > It is the same flaw in WAR files.
> Again, I disagree: the only flaw I see in WAR files is the implicit
> one2one assumption I stated above and the fact that deployment behavior
> is mostly left to the "mercy of your servlet container" (to quote you).
> I'm not describing a solution that copies over these bad assumptions,
> but one solution that takes the good out of the war file concept
> (mostly, the ability to install a package, just as you install software
> on your machine, instead of having to place a bunch of files here and
> there and mofify a ton of configurations just to make it start, not
> talking about coherence between the different webapps installed in the
> same system)

Ok.  I have some ideas on the requirements of such a system.  For one thing,
the hierarchical CM approach will have to be used.

> > Yet another issue arrizing from the URI space issue is where
> > to locate all your images and resources.  I prefer to have one URI for each
> > resource, wether it be image or stylesheet.  I can't reference an image at
> > "/images/foo.jpg" because my webapp or cocoonapp may not be installed at
> > the root context.  There really is no way of automatically rewritting the
> > location to reference the context root.  What I end up doing is writting
> > a rule in my sitemap that makes "images/foo.jpg" read the same resource
> > no matter what directory it is called from--effectively poluting my URI
> > space.
> I've always been an avid proponent of the complete remounting facility
> of subsitemaps that lead to the assumptions that all URIs are relative
> to the current sitemap and absolute locations were not possible.

Yes, but one issue is that stylesheets which are clearly in the webapp
context cannot be accessed by a subsitemap if it requires parent directory
access.  This is not optimal.  As to your proposal below, there is a lot
to like.  Lets see if we can come up with a killer.

> While the ability to perform internal redirection makes is possible to
> do what you describe above, I came to agree that this is *not* a good
> thing and does not improve any concern separation nor makes the
> architecture more elegant.
> As you imply, rather the opposite.
> Expecially thinking about batch processing, such remapped resources
> would end up being copied all over the place with a clear inelegance,
> redundancy and memory consumption.

Just look at Avalon's documentation build process to prove that.

> I'm happy to reconsider the ability to mount absolute URIs in sitemaps.
> (of course, absolute is used here in sense of global cocoon context, not
> absolute compared to the entire web site space)

That is what I am referring to.  As of Servlet 2.3 and much debate, the
official stance on where "/resource" maps you is to the web server root,
not the context root.  Instead, the context root is much more difficult
to reach.  Perhaps we can improve the HTML serializer to automagically
correct context root resources.

> > Another side affect of the sitemap is that you cannot refer to resources in
> > a parent sitemap.  The whole concept is centered arround the resources being
> > in the same directory as the sitemap, or below.  I find this frustrating,
> > as I am forced to duplicate resources in my directory hierarchy just so the
> > entire site can have the same look and feel.
> Careful, this is an entirely different story. While I agree that having
> the ability to access absolute Cocoon URIs is a good thing, I still
> believe that something like cocoon:../images/logo is *bad* because it
> removes the ability to remount the subsitemap.

Let me expound.  I like to use a dierectory structure like this:


The problem is when I want a consistent look and feel in my ${}
area.  I cannot access the /stylesheets that are accessible via the
context--but not via the sitemap.  This requires me to copy the
/stylesheets to the ${}.

> So, while the three other URIs (absolute and the two equivalent local)
> maintain the same state independent on their relative position, the
> "parent referring" one does not.
> This is why it should *not* be available, unless we want to sacrifice
> control over webapp remounting and give it to the user. Something I'd
> rather *not* do, but not because I don't trust users' ability to manager
> their URI space, but because they can become so complex that breaking
> transparent remounting at the architectural level places more concerns
> on the URI space maintainer and for sure he'll have enough to take care
> of.

Hopefully I explained the scenario better further up.  Resource is a very
generic term, and does not always refer to graphics.

> > Clearly, Cocoon needs to focus on some key resource resolution issues to
> > make it work properly.  Part of the issues come from resolving the names.
> > Perhaps views are our ticket to standard look and feel.  However the site
> > maintainer needs the perogative of adjusting the look and feel of the site
> > without affecting the logic of the site.
> Of course.
> I just had an idea: could avalon-like component behavioral dependancies
> for cocoon webapps make this possible?

Actually I was thinking along these lines.  (Great minds really do think

> I explain further: think of cocoon webapps as avalon components. Your
> image gallery webapp and your webmail webapp being instances of
> behavioral descriptions for webapps (sort of "interfaces" for web
> applications) and both require the instance of another webapp which
> includes the stylesheets they need to complete their job.
> So, the contract is that, in order to work, these webapps *require* the
> existance of the stylesheet webapp and they require to know how to
> access it.
> One solution is absolute positioning: the stylesheet-containing webapp,
> must be mounted in a specific place. But, this is ugly and might create
> collisions, expecially if different versions of the webapp must be
> installed (one webapp requires one version and another requires
> another).
> The other solution is to use the same avalon component discovery
> mechanisms: if the package instance of the behavioral interface
> "Gallery" requires one package instance intalled of the behavioral
> interface "Style", it might use something like
>  cocoon://Style/stylesheet/images2html.xslt
> which allows three different behaviors:
>  cocoon:/images/logo -> absolute positioning
>  coocon:images/logo -> relative positioning
>  coocon://Look&Feel/images/logo -> role-based positioning
> that, IMO, satisfy all needs and make the entire thing *extremely*
> elegant.

I know what you are saying, but I think we can make it a bit better.
In the proposal I had back in July (link in another email), I was
thinking about resource naming.  That way, no matter what sitemap
or URI map a resource was, it could be found.  This was as a result
of trying to implement the subsitemap approach with sub applications.

I ran into the problem with sitemaps at that point where I could not
access my stylesheets.  I figured if I could name a view resource,
I could use that resource in every sub application.  The FlowMap would
be used for form progressions, and itself be considered a resource.

Because Cocoon is an XML framework, in order for this approach to work,
you have to define the interfaces.  There are definite roles that I
have already identified.  Some of the solutions come from concepts in
SOAP, and some of the solutions come from concepts in JNDI, but here goes.

For sub applications to work, you must have them work to a specific schema.
(this concept is from SOAP).  For instance, your resource must return
the results in DocBook format so that the parent knows how to apply views.
This is the interface of your "component".  Second, there are roles that
are identified in the sitemap and the flow/uri map concepts:

Views: Take a known schema and transform it into a final product (HTML,
       PDF, XML, etc.).  It is assumed that a View completes the pipeline
       all the way to a Serializer.

Resources: Take any source and transform it into a known schema.  It is
           assumed that the resource starts the pipeline from Generator.
           There are specializations of this type.

AdatableResource: A specialization of Resource where the output schema
                  can be specified by the parent.  I.e. If the parent
                  doesn't know the inbox schema, the Adaptable resource
                  will convert it to the docuement schema.

StreamResources: Take any source and goes completely through serialization.
                 This is basically an alternate for Readers, although it
                 can also be used for generated reports.

FlowResources: A mounted flowmap that performs all the logic necessary for
               a complex form.  It handles paging, etc.  It is a type of
               compound resource in that it pools several simple resources
               together, and returns the one we are concerned with at the

URIMapResources: A compound resource that maps URIs to specific simple

SitemapResource: A compound resource that is a sub sitemap.  Sitemaps are
                 completely self contained, so it is near impossible to
                 override their results.

A sub application can specify resource adaptors for it's native XML generators,
for instance you might have a document schema and a schema for an inbox.
The If the parent has a View that recognizes the inbox schema, then it will
directly use that schema.  If not, the sub application will specify a default

Hopefully this is enough to get us started.

> Agreed, do you think that my proposed avalon-like component solution for
> webapps might help in this regard?


> In short, you are asking for more solid and wiser contracts between web
> applications and I believe that an absolute URI space accessing is
> already a solid contract, but the proposed role-based addressing is a
> killer since it allows strong contracts and still complete flexibility
> and scalability.

Yep. Well defined contracts reduce cognitive dissonence.  Too many contracts
increase cognitive dissonence.

In other words, I want our new contracts to be built on existing contracts
and known principals so that it doesn't take as long for someone to come
up to speed.

> > > Currently, development of cocoon webapps is rough and not engineered: is
> > > mostly left to the user ability to manage the process.
> >
> > I concur with this statement.  Hopefully my tutorial sheds some light on
> > an approach that is workable for more than just my crew and I.
> Which is great and will make Cocoon must more used, but still, I think
> that good documentation should not *patch* an architectural design
> limitation, but sheds some light on both the users (to make them work in
> the best scenario) and the developers (to make it possible for users to
> be guided by the software first *and* the documentation later, not the
> other way around).


> > > In the future, I'd love to make it possible to design the system in such
> > > a way that concerns are well kept separate even during the two stages,
> > > development and production, for example, performing sitemap
> > > interpretation during developement (since no high load is required, but
> > > faster responsiveness at structure changes) while performing sitemap
> > > compilation on deployment. Same thing for compiled XML.
> >
> > +1
> This is, IMO, a big thing. Currently Cocoon is damn powerful but not
> very useable. My goal for the future is to keep the power (or even
> increase it, if new ideas emerge) and increase the usability at the same
> level of its power, without sacrificing nothing that we already
> achieved.

It's a tall order, but it can be acheived.

> > I made another proposal that would be I think a better approach than the
> > sitemap concept as a whole.  Basically, it is breaking the sitemap into
> > pieces that are required for the management of the resources.  It keeps
> > the graphic designers in charge of their resources, Developers in charge
> > of their resources, etc.  It was a few months ago (I think around March/April).

I was wrong--it was July.

> > I proposed it to Giacomo as I did not want to distract from the focus on
> > C2 release at the time.  I will see if I can dig up the proposal in my
> > archives.
> Yes, I've seen that and I concur that the sitemap forces concerns to
> overlap.
> I'll be very happy to continue this thread and extend it to what we need
> to do to make it easier to use cocoon from a user's perspective and to
> allow more complete separation of concerns.


To unsubscribe, e-mail:
For additional commands, email:

View raw message