Stefano Mazzocchi wrote:
> Cocoon is currently a publishing framework, meaning that is somewhat
> more powerful for stateless resources than for stateful ones.
And these days, stateless resources are in the minority. People expect more
from a site than they did back in 1999.
> I strongly believe that Ovidiu's work on Schecoon will (sooner or later)
> bring balance to this picture, allowing Cocoon to be as powerful with
> stateful resources than it is today with stateless ones.
I am looking forward to that.
> This considered, the concept of 'cocoon application' is to be extended
> to include all possible sums of stateful and stateless resource serving.
>
> These RT are based on the assumption that the above is true and try to
> address the future needs for cocoon application design, programming,
> debugging, refactoring, maintenance, installation and deployment.
I have some views as well, and I will be happy to join in here.
> Well, to be honest, today Cocoon runs 'one' application, or, in some
> circumstances, a disorganic collection of independent applications
> sharing the same URI space.
:) That is why there exists the concept of multiple webapps in the Servlet
Spec. Of course, we know that Cocoon can be a memory hog--and it is more
efficient to have one uberapplication control all subapplications.
> This reminds me of the trend that appeared on software system: the first
> systems were monolithic monotasking environments, then started to appear
> multitasking environments, preemptive multitasking (IoC anyone?) and
> more recently, component based environments and distributed component
> based environments.
Well, preemptive multitasking != IoC, but services and daemons were the
closest thing (enabled by preemptive multitasking).
> 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.
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.
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.
Authentication is something that is not necessarily an application in and of itself,
but
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 on
the functionality of the container). Those aspects are weaved at run-time by the
system.
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
portal.
This is better than simple aggregation, because the Composition can be changed
from sub-app
to sub-app. Furthermore, it provides a way for a cocoon application to add it's
own
information to the Composition.
4) Presentation Components are the easiest to take care of because their interface is
the
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
well.
Perhaps we should describe how we would implement three simple systems, as that is a
number
that is useful to find the abstractions that work accross the systems. They should
have some
similarities, but diverse enough to find the useful abstractions.
Since I do not do well with algebraic representations of a system (Component B uses
Interface A...)
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 Infoplanning.com 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. The
retailer must approve it, reject it, or schedule a face to face meeting before
making the
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, and
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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
