cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Higginbotham" <>
Subject RE: [RT] JSR170, Slide and AOP
Date Thu, 17 Apr 2003 15:28:06 GMT

Hi! In the past I submitted a proposal for a revised architecture for
Slide, from the perspective of an architect who is trying to use Slide
as a CMS kernel in a webapp (webdav being nice but not a requirement for
my needs). Here is the MARC link:

Followup discussions are shown at the bottom and clarify a few issues,

>From your email, I think we are targeting the same thing, but I might
need some clarification on a few things.. Basically, you are speaking of
AOP, which effectively can be implemented as an interceptor pattern for
the purposes of this discussion. Now, you said:

> So are there alternatives? Yes, there are! The Slide API. 
> What make the Slide API different?
> Slide API
> =========
> The Slide API have for every aspect a separate helper class, 
> or component. For example, if you want to lock a file, you 
> can use the following pseudo code:
>  locktoken =  new NodeLock(lockSubject, lockDate);  
> lockhelper.lock(slideToken, lockToken);
> Here we have a totally separation of model and logic. The 
> client comunicates with component over the model. You don't 
> have any logic in the model. This design allows a better 
> scaling, because if you add a aspect, you simpliy add another 
> component. And also the fact that you don't have a model 
> within the component helps. So most components can be written 
> threadsafe, and you need only one instance.
> And this is Aspect Orientated Programming for me.
> I also made these faults in the past, and then I must learn 
> it the hard way, but anyway this is only my opinion.

What you speak of is the server side of the world - adding new aspects,
or interceptors, to enable new things to be added to the kernel. So,
let's not confuse this with the client side of the world. In my
proposal, I speak of 2 levels of usages for the Slide API - a
lower-level CMS framework, which allows for distinct levels of usage -
versioning or no versioning, locking or no locking, etc. This would
allow a user of this API to determine how they want to use the framework
(mostly done via the Domain.xml file now). This may mean that any
combination of needs can be handled by the configuration of this layer
and related aspects. 

One may interact with this low-level API, or use the higher-level API.
This API would do more interesting things like allow one to browse,
fetch, and update content without knowing if certain steps need to be
taken to ensure the content is versioned, how to lock a file properly
including its related actions (per deltav specs). This is what the
WebDAV servlet would use to implement its semantics, and where most
applications would communicate. My main goal was to get a transport
agnostic way to talk with the kernel, but in the process I found that
this also allows you to have a lower-level set of Lego blocks, while the
higher-level API could be used or modified by an application as desired
to accomplish larger tasks (Lego assemblies like a wall, building,

Once these layers are in place, you can do interesting things like write
a nice web-based CMS application, and standalone Swing
knowledge-management application, a Swing client that can use Webdav or
SOAP or whatever to talk to a Slide kernel. You could also accomplish
what you speak about with Avalon integration and handle any other
protocols or needs you may have. 


View raw message