cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Componentizing Cocoon Applications
Date Tue, 05 Feb 2002 17:02:52 GMT
[Berin, could you please word-wrap at 72 columns, which is the safest
number for mail readers? thanks]

Berin Loritsch wrote:

> > In order to grow architecturally, I strongly believe that cocoon must
> > allow (not force, allow!) the componentization of the applications it is
> > capable of running.
> To this end, we have to concider what interface lines to draw.  For instance,
> the contract for a skinning system (as I threw one together for a company I
> freelance for) is that the source schema has to be the same.  I also found
> that all supporting elements like graphics and CSS stylesheets required their
> own URI space (otherwise client caching mixes and matches the previous skin's
> elements with the new skin's elements).
> So instead of writing a big select statement, or even a statement like
> <transform src="stylesheets/{skin}/docbook2xhtml.xsl"/>,
> We can start looking at application specific abstractions.
> For instance, we can call a web application like this:
> <mount application="webmail" uri="webmail">
>    <standard schema="DOCTYPE book PUBLIC //DocBook//4.1//EN//US"/>
> </mount>
> <mount application="authenticate" uri="/">
>    <standard schema="DOCTYPE book PUBLIC //DocBook//4.1//EN//US"/>
> </mount>
> or something like that.  To allow a Component application to be used, we must
> identify the schema contracts we have.  That means that "webmail" and "authenticate"
> must both implement the "DocBook" interface.  That allows for the parent
> application to apply whatever styling it wants.  If the "standard" element had
> the HTML schema, then the application/component would use whatever stylesheet it
> had for the docbook to html transformation.  That way, the webapps can be used in
> an embedded fashion or directly.

You have proposed this a number of times, but I still fail to see how
this could work in practice and scale.

The biggest problem I see with your 'schema-driven' contracting (even if
it would reduce the number of conctracts, thus reduce design failures)
is its intrinsic namespace unfriendlyness. (or, at least, I perceive it
as such).

> Honestly, the issue of skinning or theming a site is relatively simple to fix.
> The issue of componentizing application parts to embed pieces of logic is another
> matter altogether.

Exactly! your solution works in simple cases where you have one2one
connections between concerns and schemas represent those contracts. I
fear this is just a very special case of the situations that I want
Cocoon to be able to handle.
> We can expect to see two different use cases:  full webapps that merely contain
> all the logic in one uri space, and smaller web components that can be used to
> build the webapps.
> For instance, the "authenticator" role can be a simple wrapper arround the Servlet
> Forms based authentication, or it can be a whole new implementation.  There are
> certain behavioral contracts it must observe.  The first would be that successful
> authentications allow program logic to continue, while unsuccessful authentications
> must be handled according to policy--i.e. shutting a client IP address out for
> a few minutes after three unsuccessful attempts.
> Since the application itself doesn't care about how authentication is handled, but
> merely needs to know if the user is authenticated, Schecoon can offer the programming
> component abstraction.  Something like this can be fairly powerful:
> -------------------
> MyWebApp applyAspect Authentication {
>      protected["admin","user"] {
>          // do stuff
>      }
> }
> This "aspect oriented" view of the system will allow the application to ensure the
> authentication is taken care of by the Authentication aspect defined as a cocoon.
> The aspect allows you to embed the program locic inside of the protected domain.
> That way, we have the module documented that it must be authenticated--but we leave
> it to the main system to determine what Authentication aspect we apply to the system.

Yes, I share your vision on this.
> Authentication is something that is not necessarily an application in and of itself,
> a service that is necessary.

> Another aspect that can be applied is one of menu hierarchy.  For instance, you may
> not want to have the entire menu hierarchy available at the front page, instead forcing
> the user to delve in deeper.  Furthermore, a menu can be different based on the role
> of the user.  For instance, a whole administration system for a site should not be
> available to the average joe.
> Therefore we have traditional Components, programming Aspects, Composition COmponents,
> and presentation components.  Each model has its own view of the system, and provides
> certain benefit.
> 1) Traditional Avalon components can provide necessary mechanisms to abstract out certain
>     program logic such as obtaining a reference to the User object, or manipulating application
>     data.  They can be accessed via the Schecoon macro language.
> 2) Application Aspects (those that satisfy cross-cutting concerns) can be applied in
a fashion
>     similar to the decorator pattern (i.e. as you embed pieces inside others, they take
>     the functionality of the container).  Those aspects are weaved at run-time by the
> 3) Composition Components take care of adding pieces such as menu options, side-bar things.
>     In other words, the Composition Components can be a powerful tool towards a true
>     This is better than simple aggregation, because the Composition can be changed from
>     to sub-app.  Furthermore, it provides a way for a cocoon application to add it's
>     information to the Composition.
> 4) Presentation Components are the easiest to take care of because their interface is
>     schema used for the site.  In fact, this is the concern that is best represented
by Cocoon
>     today.
> Use cases for 1 and 4 are available today with Avalon framework and Cocoon framework.
 It is
> the use cases for 2 and 3 that we need to find a good model for.  Hopefully this works

I don't find myself resonating with your vision, but I like very much
the depth of reasoning behind it.

What you write worries me a little since it triggers an important
question: can we design a meaningful component system for Cocoon webapps
*before* we are done with the flowmap language?

I have no valid answer. :(
> Perhaps we should describe how we would implement three simple systems, as that is a
> that is useful to find the abstractions that work accross the systems.  They should have
> similarities, but diverse enough to find the useful abstractions.

I agree with this iterative approach. Yes.
> Since I do not do well with algebraic representations of a system (Component B uses Interface
> and it is easy to get lost, we should describe the systems we intend to tackle in this
> discussion.  Below are three that I think will work well:
> 1) Simple marketing info gatherer.  The web site (built with Cocoon
1) has a
>     section where we gather a name and email address in exchange for a whitepaper.  I
think this
>     should be a simple use case to help us get going.  The whitepaper is sent to the
email address
>     to verify that it is correct.
> 2) Approval system.  I have worked on many web applications that have some sort of approval
>     process.  The list of tasks for approval change based on the role of the user and
the status
>     of the tasks.  For instance, a vendor must submit a new product request to a retailer.
>     retailer must approve it, reject it, or schedule a face to face meeting before making
>     final call.  Each request can have multiple line items, and the retailer must have
the ability
>     to reject specific line items before accepting the rest of the proposal.
> 3) Simple webmail system.  The user must be able to retrieve, view, delete, respond to,
>     write new mail.
> These three provide sufficiently different needs, while finding some overlap.  Perhaps
there is
> some way we can provide useful abstractions for all the needs, but maybe there are some
that are
> just to application specific.  This will help us focus our efforts so we can describe
how we
> would represent each system in whatever syntax we need available.

Ok, guys, here is a call for you: how would you *like* to have a system
in order to be able to reuse the above functionalities in different

C'mon, you can define your own markup, your own semantics and your own
programming language.

It's a good time to shape up the future of the web!

Let's be creative! :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message