[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,
>but
> a service that is necessary.
Absolutely.
> 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.
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
>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.
I agree with this iterative approach. Yes.
> 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.
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
systems?
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.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
