<snip/>On Wed, 02 Mar 2005 20:51:13 +0100, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:Peter Hunsberger wrote:On Wed, 02 Mar 2005 18:14:56 +0100, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:Peter Hunsberger wrote:On Tue, 01 Mar 2005 11:33:32 +0100, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
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
