cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] A Unified Environment Model?
Date Wed, 02 Mar 2005 23:30:22 GMT
Peter Hunsberger wrote:
> On Wed, 02 Mar 2005 20:51:13 +0100, Daniel Fagerstrom
> <danielf@nada.kth.se> wrote:
>>Peter Hunsberger wrote:
>>>On Wed, 02 Mar 2005 18:14:56 +0100, Daniel Fagerstrom
>>><danielf@nada.kth.se> wrote:
>>>>Peter Hunsberger wrote:
>>>>>On Tue, 01 Mar 2005 11:33:32 +0100, Daniel Fagerstrom
>>>>><danielf@nada.kth.se> wrote:
<snip/>
>>>>It was designed for DB applications, it contains some kind of
>>>>transaction processing with rolbacks. I'm not questioning that something
>>>>like input/output modules can be usefull. My main point is that I find
>>>>them over enginered and have to much features for the kind of needs we
>>>>IMHO have today.
>>>Not sure what you're referring to here.  The base output modules seem
>>>pretty straight forward though there seem versions with features I can
>>>see no need for...
>>Take a look at the interface,
>>http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/java/org/apache/cocoon/components/modules/output/OutputModule.java?view=markup,
>>it contains a commit and a rollback method and all methods take runtime
>>configuration objects. It might have been usefull for the database
>>applications they where designed for,
>>but I wonder if they are used much for such applications anymore.
> 
> Yuck.  Don't know.  At the very least we could make two versions of
> the interface and have the simpler version (without the
> rollback/commit) as the normal base...

Yes, we should keep back compability.

>>In the original message in this thread I discussed a unified script
>>object model. Several people have proposed that such a model should be
>>like FOM but built from modules. For this specific use case I find the
>>current input/output modules unecessary complicated.
>
> Sure, the interface isn't  100%, but thhe concept seems pretty much correct?

At a high level the concept is OK. It is usefull to be able to plug in 
maps that can be used in the sitemap and in other places, but the devil 
is in the details.

What we want to achieve is a pluggable script object model (OM) that can 
be used in sitemap, flow and templates. Carsten proposed that it should 
be extendable with input modules and Vadim that it should consist only 
of input modules (the references can be found in my first message in 
this thread). The configuration could look like:

<object-model>
    <mount input-module="request" path="cocoon.request"/>
    <mount input-module="session" path="cocoon.session"/>
    <mount input-module="skin" path="cocoon.skin"/>
    <!-- etc -->
</object-model>

This looks nice, but there are some complications. If we want to use the 
  OM in flow it must be writeable also and we must implement output 
modules that correspond to most of the input modules. Then to make 
things even worse you must use an output module if you want to update 
cocoon.session.foo but an input module if you want to update 
cocoon.session.foo.bar (take a look at the notify method in the 
XModuleSource for a concrete example).

Also the fact that the object access is devided in an output module that 
uses a trasaction scheme and an input module, makes it hard to use it 
with some external code that does a read and update operation.

Then some of the modules take an JXPath as name instead of just a name, 
but it might not be a problem. The JXPath modules also has the 
disturbing behaviour that they use JXPath.getValue instead of 
JXPath.getNode, which means that you get the text content of a DOM 
instead of the actual object.

               --- o0o ---

So the innocent looking i/o modules give us a quite a number of problems 
if we want to build an OM from them.

So what do I propose instead? If we think of it the only thing we need 
is access to objects (and preferably script (SL) and expression language 
(EL) friendly objects). Then it is the task for the EL or SL to do the 
accessing. If the object is read or write able or booth will be seen 
from its get and/or set methods or whatever the reflection engine in the 
EL or SL supports.

So instead of i/o modules it would be enough with "modules", (but we 
should really find a better name). And the interface could look like:

interface Module {
   String ROLE = Module.class.getName();

   Object getObject(Map objectModel);
}

thats all. So much simpler than i/o modules and we get better behaviour 
and SoC at the same time.

WDYT?

               --- o0o ---

<snip/>
>>>From your
>>description I got the impression that you got XML output that you wanted
>>to put in a request attribute. For that, using the XModuleSource to
>>write to an request-attr output module seemed to be an reasonable
>>assumption about why you used an output module at all. But from your
>>description I fail to figure out from where you use your output module.
> 
> You've got it more-or-less correct, but we build a buffered SAX
> stream, not a DOM.  We don't really use a request-attr, but it's
> simpler to explain things in those terms then using proprietary module
> descriptions (even if they are just wrappers around existing Cocoon
> functionality) .For this discussion I should have been more precise
> since it appears you're digging into the guts of what's really
> needed...

Yes, for the moment my main interest is in making the enviroment 
handling in sitemap, flow and templates more coherent. But I'm also 
interested in making it easier to put together sitemap "web services", 
and your use case seemed to be related to that. But I'm not going to do 
anything in this area right now so we can take that discussion at some 
later time.

/Daniel

Mime
View raw message