Re: Long running requests and timeouts...resolved...

[Andrzej Jan Taramina]

Just FYI to those that were following this thread, this was a Cocoon (2.1.5) 
issue that caused this, not Tomcat.

Turns out that the Cocoon 2.1.5 ResourceReader sets some response headers 
willy nilly. 

If you have another component that uses a resolver to access a pipeline that 
uses the reader (eg. using the cocoon: pseudo protocol, in our case it was a 
custom PDF concatenation serializer that called out to a sub-pipeline to get 
a separator page pdf), then the reader sets the Content-Length http reponse 
header in the original response object.  If the originating 
component/pipeline generates output that is longer than what the reader 
grabbed, then it gets truncated.  Not sure why Cocoon doesn't create a new 
response object when you try to resolve a local "cocoon:/" resource, but it 
doesn't.

Creating a customized ResourceReader with all response header setting 
commented out resolved the issue for me.

Andrzej


> I have a situation where some requests that get sent to Tomcat are very long
> running (basically batch operations).  I've been testing with a request that
> takes just over 7 minutes to process and returns and XML document as a
> response.
> 
> The problem I'm having is that the response gets truncated.  It's always
> truncated at a consistent spot.  It always sends back exactly 3207 characters
> in the response body and this is consistent using Firefox or a commons-
> httpClient based script.
> 
> Shorter running requests don't truncate anything, regardless of how long the
> response might be.
> 
> I'm running Tomcat 5.0.28 and my Connector in the Tomcat server.xml file looks
> like:
> 
> maxThreads="150" 
> minSpareThreads="25" 
> maxSpareThreads="75"
>enableLookups="false" 
> redirectPort="8443" 
> acceptCount="100"
>debug="0" 
> disableUploadTimeout="true"
>  tcpNoDelay="true"
> connectionLinger="-1"
> connectionTimeout="600"
> connectionUploadTimeout="600"
> keepAlive="true"
> maxKeepAliveRequests="-1"
>  serverSocketTimeout="0"/>
> 
> I've tried all sorts of timeout values in the aboveincluding zero values,
> but the behaviour is consistent. Long running invocations truncate the
> response body to 3207 characters.  I've also tried changing the client side
> timeout values, but again, to no avail.
> 
> I'm kinda stumped as to what might cause this, especially given the very
> consistent response body length that is always returned.  Almost seems like
> some strange buffering issue that is timer-related.
> 
> Any ideas?


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [GUMP][PATCH] fix a bunch of typos for jars in Cocoon repo

[Carsten Ziegeler]

Fixed.
Thanks!
Carsten
Stefan Bodewig wrote:
Should all be trivial changes
Cheers
Stefan
--- gump.xml.orig	Wed Jan 26 17:43:16 2005
+++ gump.xml	Wed Jan 26 17:47:09 2005
@@ -1340,7 +1340,7 @@
 
   Delivery context library
 
-
+
 
   
 
@@ -1369,7 +1369,7 @@
 
   Chaperon is a project that helps to convert structured text to XML
 
-
+
 
   
 
@@ -1378,7 +1378,7 @@
 
   iText is a library that allows you to generate PDF files on the fly
 
-
+
 
   
 
@@ -1431,7 +1431,7 @@
 
   
 org.outerj.daisy.htmlcleaner
-
+
 
   
   

[GUMP][PATCH] fix a bunch of typos for jars in Cocoon repo

[Stefan Bodewig]

Should all be trivial changes

Cheers

Stefan

--- gump.xml.orig   Wed Jan 26 17:43:16 2005
+++ gump.xmlWed Jan 26 17:47:09 2005
@@ -1340,7 +1340,7 @@
 
   Delivery context library
 
-
+
 
   
 
@@ -1369,7 +1369,7 @@
 
   Chaperon is a project that helps to convert structured text to XML
 
-
+
 
   
 
@@ -1378,7 +1378,7 @@
 
   iText is a library that allows you to generate PDF files on the fly
 
-
+
 
   
 
@@ -1431,7 +1431,7 @@
 
   
 org.outerj.daisy.htmlcleaner
-
+
 
   
   

Re: Object parameters, Was: sitemap, jx and flow design

[Sylvain Wallez]

Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
BURGHARD Éric wrote:
 
   
   
 
I have never disputed that things might be clumsy now, I just think 
we should focus on getting the flowscript way better, instead of 
adding things that makes the sitemap more of a programming language, 
by handling a more diverse set of datatypes then strings.

This one is absolutely same issue you are discussing here:
  http://issues.apache.org/bugzilla/show_bug.cgi?id=9916
IMHO, it is worth to discuss the issue of passing object parameters by 
itself, without mixing flow or jx into it, as a bonus we might get 
resolution for a 2.5 years old feature request.

As for implementation, probably extending Parameters with 
getParameterAsObject, setParameter(String, Object) should be enough.

And changes to VariableResolver so that it returns an object if it only 
contains an input module expression.

We can add getParameterAsObject() to o.a.c.sitemap.SitemapParameters 
that was created to add getStatementLocation().

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Object parameters, Was: sitemap, jx and flow design

[Peter Hunsberger]

On Wed, 26 Jan 2005 08:09:45 -0500, Vadim Gritsenko
<[EMAIL PROTECTED]> wrote:
> Daniel Fagerstrom wrote:
> > BURGHARD Éric wrote:
> >
> >>  
> >>
> >>
> >>  
> >>
> > I have never disputed that things might be clumsy now, I just think we
> > should focus on getting the flowscript way better, instead of adding
> > things that makes the sitemap more of a programming language, by
> > handling a more diverse set of datatypes then strings.
> 
> This one is absolutely same issue you are discussing here:
> 
>   http://issues.apache.org/bugzilla/show_bug.cgi?id=9916
> 
> IMHO, it is worth to discuss the issue of passing object parameters by itself,
> without mixing flow or jx into it, as a bonus we might get resolution for a 
> 2.5
> years old feature request.
> 
> As for implementation, probably extending Parameters with 
> getParameterAsObject,
> setParameter(String, Object) should be enough.
 
Wow, the very first Cocoon related bugzilla entry I ever voted on.  

Big +1 for fixing this the right way!

-- 
Peter Hunsberger

Re: [RT] Management Prototype?

[Ralph Goers]

Carsten Ziegeler wrote:
Ok, it seems that most of us like this idea - great.
Now, all we need is a volunter!! Anyone? - I can help with everything 
not directly related to JMX itself - if required.

Carsten
Well shoot. I can help, but I don't have a lot of time to devote at the 
moment.  I think the first item is to make a list of all the data that 
should be collected and the operations that should be performed.  Then 
they should be prioritized and worked on in that order.

It would be nice if there was a wrapper for JMX. We ended up building 
our own. JMX is fairly raw.

Ralph

DO NOT REPLY [Bug 32263] - [PATCH] contribution lucene block

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32263





--- Additional Comments From [EMAIL PROTECTED]  2005-01-26 15:33 ---
(From update of attachment 14107)
for cocoon 2.2 


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [RT] Management Prototype?

[Ralph Goers]

Carsten Ziegeler wrote:
I think one area were Cocoon really lacks in functionality is 
administration. We briefly discussed this topic some months ago.

WDYT about implementing a prototype with JMX? Don't know how this 
could look like or what it can do, but perhaps someone with JMX 
knowledge has some cool ideas, she is willing to test implement into 
2.2. Based on this prototype we could decide if it's worth going down 
this road or if we should search for a different solution.

I know that there are a lot of pros and cons for/against JMX - the 
discussion on the geronimo list is a good example of this. But it 
seems that every project is using JMX, so imho we shouldn't "invent" 
something different.

Carsten
JMX is the right way to go.  This is definitely something I would want 
to be involved in.  I've worked on some of the JMX stuff in our products 
and it isn't as easy as it should be.

Ralph

Re: sitemap, jx and flow design

[Stefano Mazzocchi]

Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
Now for the instructions (jx:forEach etc) we have the question if 
they should be choosed:

1. Programatically: There is an abstract base class with common 
template generator functionality. To implement e.g. JXTG this base 
class is extended. And the extended class enumerates the instructions 
that should be used and also choose parsing strategy etc.

2. Configuration: Instructions or set of instructions are made 
components and connected to the template generator in the configuration.

3. Within the template language: There are special instructions in 
some common base template language that allow the user to include 
sets of (Java written) instructions.

I would prefer the configuration way find the programatic way ok and 
be against the within the template language way.
WDYT?

This really looks like just an implementation detail... I would think 
that the configuration way makes it easier (psycologically) for people 
to add their own instructions than the other two. #1 is cleaner than 
#3 and less avalonish than #2.

I'm not thrilled with the idea of people adding their own keywords to 
the template language... just like the sitemap, it should be possible 
but not easy, so that people would feel discouradged to do it. So 
probably #1 would be my choice.

Sitemap currently is configured with an XML file which describes all 
sitemap keywords (sitemap-language.xml), and we do not hear about folks 
messing with it. So I'd say #2 is good too, as long as configuration is 
a reference to a configuration file which is tucked into cocoon.jar - 
same as for the sitemap.
Good point. I stand corrected.
--
Stefano.

Re: sitemap, jx and flow design (was: servicemanager and jxtg)

[Stefano Mazzocchi]

BURGHARD Éric wrote:
Stefano Mazzocchi wrote:

My girlfriend tells me that sometimes it seems like I argue for the sake
of arguing.., that I would take the other side no matter what... and
that in a single conversation I might argue about why something is black
and then argue about the same thing is white once I change the other
person's opinion.
I know I do that... and the reason why I do that is that I force people
to convince themselves before convincing me. There is no such thing as
being right or wrong especially if we don't understand what we
really want in the first place.

Thanks to you and daniel, i changed my mind during theses threads. I never
thought about the real goal of jx : to be a simple template language, SoC
and IoC compliant. So, i was the first to request a servicemanager
access :-), It's certainly due to my misunderstanding of the whole process,
but i think that jx role didn't appear clearly in the current
implementation (ie effectively far from preserving the former properties).
After beeing convinced by your explanations, i happily jumped on the other
side (vote -1 for my own request). No problem about that.

I think that as long as cocoon grows incrementally and organically,
there is no problem in any approach and that usage will tell us if
something was a good idea or a bad one.
So, to cut it short: it really doesn't matter what you are saying but
*how much you are willing to suffer to get it across* :-)
More than anything, I act as a filter. A pain in your butt. I play death
in a design chess game... where the community is what wins.
So, it doesn't really matter what you do or propose, but how and how
open is your mind when you do that. The sofware result will be shaped by
reality and usage anyway, and it will never be perfect because
perfection is never in living things (and open developped software is a
living organism) if not in their own existance.

I really approve this kind of approach.
Cocoon is really convenient for doing complex things but it should be
convenient for simple things too (stateless templating as you said) to be
able to attract less involved developpers (It take us near one year of
intensive web application developpement around cocoon to be able to discuss
with you).
Dom in sitemap parameters is the kind of little addition (user point of
view) that could simplify some simple use cases with jx as well as with
flow. It gives a kind of access to the servicemanager via input modules
(one of the first thing you learn with cocoon) without knowing a thing on
avalon component lifecycle or existing java classes. You don't have to
implement any input module access in jx, it didn't compromise any existing
things either.
If you want to enforce some properties on jx (restrict the kind of objects,
deprecate $session, ...) you could do it after this little addition anyway.
(i'm sure these restrictions could help to give a better vision to new
users of what the sitemap, flow and jx are supposed to be and to do).
I don't feel strong enough for implementing such thing :-(, but i feel that
with the help of the the ObjectHelper and by implemeting a new method that
return object instead of object.tostring() in inputmodule (naive view) it
should be easy to pass object from sitemapcontroler to jxtg.
Don't hesitate (everybody) to point me to the right direction, i will be
happy to contribute if i estimate that my project will not suffering from
my involvement here.
You know, Éric, the difference between open development and closed 
development is that the final argument about what gets or doesn't get 
done is the magic "show me the damn code".

Oh, don't get me wrong, I committed many of the same sins: the adaptive 
cache and real blocks are both major designs that I never stepped up to 
the plate to implement.

As for you, the itch was not enough for such a big scratch. I'm also 
happy about it... our blocks are becoming more and more separated, the 
community is incrementally moving toward the need for more integration 
and their complex dependency chains is not making the itch strong enough 
for people to think about scratching.

It will all come together, eventually, and by doing it incrementally, 
the entropy generated will be low.

Daniel, on the other hand, puts his fingers where his mouth is: code 
gets done, items pushes, architectures cleaned.

My role is to make sure that he doesn't go off the tangent and changes 
just for the sake of elegance... which is against entropy management, if 
 ain't broke don't fix it, yadda yadda you know, the usual stuff.. 
and fast turns into bikeshedding.

I agree with you that having the ability to pass a nested data structure 
(dom or nested collections) from the sitemap to the template system 
would be useful and not more harmful than what we already have in place.

But I don't need it personally so I won't work on it.
Daniel doesn't need it and doesn't even like it, so it won't come from 
him, but I think he wouldn't vote -1 in

Re: FOM & FAPI (wasRe: FOM & input modules)

[Sylvain Wallez]

Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Torsten Curdt wrote:
So I think we should clearly separate the FOM (the JS wrapper of 
the OM) from the FAPI, the flowscript API which gathers 
flowscript-related utility functions by attaching them for a new 
"flowscript" object.

We would therefore have:
- cocoon.request, cocoon.context, cocoon.mymodule, etc.
- flowscript.sendPageAndWait(), flowscript.getComponent(), 
flowscript.redirect(), etc.

sounds good to me ...one tiny thing though: I'd prefer the name 
"flow" ...so

 flow.sendPageAndWait(),
 flow.getComponent(),
 flow.redirect()

Why not cocoon.flow? Do we really need another entry-point?

Because everything cocoon.xxx should be OM or IM (or only IM, as you 
suggested), and be the same everywhere. Having different properties 
attached to the cocoon object is what currently confuses people. At 
least this is my understanding.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: FOM & FAPI (wasRe: FOM & input modules)

[Stefano Mazzocchi]

Torsten Curdt wrote:
 flow.sendPageAndWait(),
 flow.getComponent(),
 flow.redirect()
With javaflow the whole "script" naming scheme does not really fit 
...even if you get a script-like behaviour with the compiling 
classloader ...IMO

WDYT?


You're falling in the same trap again ;-)
Why should the flowscript API and javaflow API be the same? In 
javaflow, you have access to Avalon-related data such as the service 
manager and therefore don't need flow{script}.getComponent().

Well, ok... the getComponent() will not be necessary
(that was stupid ..I should have removed that line)
...but I am not proposing the same API - just the
same naming scheme where possible.
IMHO for the user it would be nice to see that the
methodnames in flowscript and javaflow are very similiar.
...although the APIs can be different I would like to
see the API being as close as possible.
I tend to agree with that.
--
Stefano.

Re: FOM & FAPI (wasRe: FOM & input modules)

[Stefano Mazzocchi]

Sylvain Wallez wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Hmm, the question is: how can a pluggable object model work - or how 
can it be extended? What about using...input modules for exactly 
this? We create a way of "mounting" input modules into the object 
model, like this:

  


And then you can simple access the info by ${cocoon.skin.something}.


I like it. Object model and input modules are just different names for 
similar things: accessing environmental data. Also, it's better to 
attach IMs to the cocoon object rather than as root variables, as it 
avoids name clashes with template variables.

Something we have to be careful of, though, is that properties of the 
cocoon object comes both from the OM (request, response, context) and 
modules, and that it should be forbidden to have IMs having the same 
name as OM keys.

I also would like to insist on the fact that FOM (flow object model) 
is nothing more than OM (object model) that we have everywhere in 
Cocoon, but rewrapped as JS objects. So we should better concentrate 
on the OM itself and let its JS counterpart follow its evolutions.

Thinking further (while sleeping!), it seems to me that over time we 
have abused the cocoon object in flowscript by making it an entry point 
not only to the OM, but also to some flowscript-specific utilities, e.g. 
getComponent(), processPipelineTo(), makeWebContinuation(), and of 
course cocoon.sendPageAndWait()

And this causes a lot of confusion, as we use the same "cocoon" name in 
other places (jxtg) with only the OM meaning.

So I think we should clearly separate the FOM (the JS wrapper of the OM) 
from the FAPI, the flowscript API which gathers flowscript-related 
utility functions by attaching them for a new "flowscript" object.

We would therefore have:
- cocoon.request, cocoon.context, cocoon.mymodule, etc.
- flowscript.sendPageAndWait(), flowscript.getComponent(), 
flowscript.redirect(), etc.

Of course, if we choose to go that way, we must keep the current 
functions on the cocoon object for back compatibility but clearly mark 
them as deprecated.

IMO, that separation would clarify things a lot, by clearly defining a 
single object model, be it in Java, flowscript, jxtg, etc.

WDYT?
Makes perfect sense.
But I think that cocoon.getComponent() would make more sense than 
flowscript.getComponent() and also cocoon.request should be just 'request'.

I'm aware this is back compatibility nightmare... but consider it 
brainstorming.
--
Stefano.

Re: Images not cached by IE if using ImageReader without expires parameter

[Vadim Gritsenko]

Adam Ratcliffe wrote:
I've just resolved an issue I had with images loaded by a javascript 
preloader not being cached by Internet Explorer, the images
are produced in a Cocoon pipeline that uses the ImageReader.
 
The problem is with the 'Vary' response header that is set by the reader 
if the 'expires' parameter is not provided. IE will not cache
responses containing this header unless its field value is the 
'User-Agent' field, for more detail see:
http://lists.over.net/pipermail/mod_gzip/2002-December/006826.html
 
Looking at the ResourceReader source and the associated bug report, 
setting the 'Vary' header was intended to prevent IE from
caching the resource when the 'expires' parameter was provided with a 
value of 0.  The way the code is implemented the header
will also be set when the expires parameter is not provided.
 
Should the default behaviour of the ResourceReader be to provide 
non-cachable content?
Don't think so. Please provide a patch via bugzilla.
PS And switch to plain text email, html on mail lists is evil.
Vadim

DO NOT REPLY [Bug 32263] - [PATCH] contribution lucene block

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32263





--- Additional Comments From [EMAIL PROTECTED]  2005-01-26 15:02 ---
Created an attachment (id=14107)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14107&action=view)
Lucene Block 1.1 


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: FOM & FAPI (wasRe: FOM & input modules)

[Vadim Gritsenko]

Sylvain Wallez wrote:
Torsten Curdt wrote:
So I think we should clearly separate the FOM (the JS wrapper of the 
OM) from the FAPI, the flowscript API which gathers 
flowscript-related utility functions by attaching them for a new 
"flowscript" object.

We would therefore have:
- cocoon.request, cocoon.context, cocoon.mymodule, etc.
- flowscript.sendPageAndWait(), flowscript.getComponent(), 
flowscript.redirect(), etc.

sounds good to me ...one tiny thing though: I'd prefer the name "flow" 
...so

 flow.sendPageAndWait(),
 flow.getComponent(),
 flow.redirect()
Why not cocoon.flow? Do we really need another entry-point?

With javaflow the whole "script" naming scheme does not really fit 
...even if you get a script-like behaviour with the compiling 
classloader ...IMO

You're falling in the same trap again ;-)
Why should the flowscript API and javaflow API be the same?
As Torsten already said, they should be (if not the same but) close, and +1 
to that.
Vadim

Re: FOM & input modules

[Vadim Gritsenko]

Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Hmm, the question is: how can a pluggable object model work - or how 
can it be extended? What about using...input modules for exactly this? 
We create a way of "mounting" input modules into the object model, 
like this:

  


And then you can simple access the info by ${cocoon.skin.something}.

I like it. Object model and input modules are just different names for 
similar things: accessing environmental data. Also, it's better to 
attach IMs to the cocoon object rather than as root variables, as it 
avoids name clashes with template variables.

Something we have to be careful of, though, is that properties of the 
cocoon object comes both from the OM (request, response, context) and 
modules, and that it should be forbidden to have IMs having the same 
name as OM keys.
... unless cocoon.request, response, context are implemented as corresponding 
input modules ... then everything under "cocoon." becomes an input module ;-)

Vadim

DO NOT REPLY [Bug 9916] - Support passing of object parameters into sitemap components

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=9916


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|javax.xml.transform.Transfor|Support passing of object
   |mer accepts object  |parameters into sitemap
   |parameters and cocoon   |components
   |prevents to use it  |




--- Additional Comments From [EMAIL PROTECTED]  2005-01-26 14:16 ---
Changed summary.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: sitemap, jx and flow design

[Vadim Gritsenko]

Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
Now for the instructions (jx:forEach etc) we have the question if they 
should be choosed:

1. Programatically: There is an abstract base class with common 
template generator functionality. To implement e.g. JXTG this base 
class is extended. And the extended class enumerates the instructions 
that should be used and also choose parsing strategy etc.

2. Configuration: Instructions or set of instructions are made 
components and connected to the template generator in the configuration.

3. Within the template language: There are special instructions in 
some common base template language that allow the user to include sets 
of (Java written) instructions.

I would prefer the configuration way find the programatic way ok and 
be against the within the template language way.
WDYT?

This really looks like just an implementation detail... I would think 
that the configuration way makes it easier (psycologically) for people 
to add their own instructions than the other two. #1 is cleaner than #3 
and less avalonish than #2.

I'm not thrilled with the idea of people adding their own keywords to 
the template language... just like the sitemap, it should be possible 
but not easy, so that people would feel discouradged to do it. So 
probably #1 would be my choice.
Sitemap currently is configured with an XML file which describes all sitemap 
keywords (sitemap-language.xml), and we do not hear about folks messing with it. 
So I'd say #2 is good too, as long as configuration is a reference to a 
configuration file which is tucked into cocoon.jar - same as for the sitemap.

Vadim

Object parameters, Was: sitemap, jx and flow design

[Vadim Gritsenko]

Daniel Fagerstrom wrote:
BURGHARD Éric wrote:
 
   
   
 
I have never disputed that things might be clumsy now, I just think we 
should focus on getting the flowscript way better, instead of adding 
things that makes the sitemap more of a programming language, by 
handling a more diverse set of datatypes then strings.
This one is absolutely same issue you are discussing here:
  http://issues.apache.org/bugzilla/show_bug.cgi?id=9916
IMHO, it is worth to discuss the issue of passing object parameters by itself, 
without mixing flow or jx into it, as a bonus we might get resolution for a 2.5 
years old feature request.

As for implementation, probably extending Parameters with getParameterAsObject, 
setParameter(String, Object) should be enough.

Vadim

Images not cached by IE if using ImageReader without expires parameter

[Adam Ratcliffe]

I've just resolved 
an issue I had with images loaded by a _javascript_ preloader not being cached by 
Internet Explorer, the images
are produced in a 
Cocoon pipeline that uses the ImageReader.
 
The problem is with 
the 'Vary' response header that is set by the reader if the 'expires' parameter 
is not provided. IE will not cache
responses containing 
this header unless its field value is the 'User-Agent' field, for more detail 
see:
http://lists.over.net/pipermail/mod_gzip/2002-December/006826.html
 
Looking at the 
ResourceReader source and the associated bug report, setting the 'Vary' header 
was intended to prevent IE from
caching the resource 
when the 'expires' parameter was provided with a value of 0.  The way the 
code is implemented the header
will also be set 
when the expires parameter is not provided.
 
Should the default 
behaviour of the ResourceReader be to provide non-cachable 
content?
 
Cheers
Adam

Re: [RT] Management Prototype?

[Carsten Ziegeler]

Carsten Ziegeler wrote:
I think one area were Cocoon really lacks in functionality is 
administration. We briefly discussed this topic some months ago.

WDYT about implementing a prototype with JMX? Don't know how this could 
look like or what it can do, but perhaps someone with JMX knowledge has 
some cool ideas, she is willing to test implement into 2.2. Based on 
this prototype we could decide if it's worth going down this road or if 
we should search for a different solution.

I know that there are a lot of pros and cons for/against JMX - the 
discussion on the geronimo list is a good example of this. But it seems 
that every project is using JMX, so imho we shouldn't "invent" something 
different.

Ok, it seems that most of us like this idea - great.
Now, all we need is a volunter!! Anyone? - I can help with everything 
not directly related to JMX itself - if required.

Carsten

Re: [RT] Management Prototype?

[Nicola Ken Barozzi]

Carsten Ziegeler wrote:
...
I know that there are a lot of pros and cons for/against JMX - the 
discussion on the geronimo list is a good example of this. But it seems 
that every project is using JMX, so imho we shouldn't "invent" something 
different.
Java 5 is using JMX to expose itself for monitoring. At this point IMO 
there is no real justification for anything other than JMX for management.

+0 (good idea, no time for help)
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: sitemap, jx and flow design (was: servicemanager and jxtg)

[BURGHARD Éric]

Stefano Mazzocchi wrote:

> 
> My girlfriend tells me that sometimes it seems like I argue for the sake
> of arguing.., that I would take the other side no matter what... and
> that in a single conversation I might argue about why something is black
> and then argue about the same thing is white once I change the other
> person's opinion.
> 
> I know I do that... and the reason why I do that is that I force people
> to convince themselves before convincing me. There is no such thing as
> being right or wrong especially if we don't understand what we
> really want in the first place.
>

Thanks to you and daniel, i changed my mind during theses threads. I never
thought about the real goal of jx : to be a simple template language, SoC
and IoC compliant. So, i was the first to request a servicemanager
access :-), It's certainly due to my misunderstanding of the whole process,
but i think that jx role didn't appear clearly in the current
implementation (ie effectively far from preserving the former properties).

After beeing convinced by your explanations, i happily jumped on the other
side (vote -1 for my own request). No problem about that.

> I think that as long as cocoon grows incrementally and organically,
> there is no problem in any approach and that usage will tell us if
> something was a good idea or a bad one.
> 
> So, to cut it short: it really doesn't matter what you are saying but
> *how much you are willing to suffer to get it across* :-)
> 
> More than anything, I act as a filter. A pain in your butt. I play death
> in a design chess game... where the community is what wins.
> 
> So, it doesn't really matter what you do or propose, but how and how
> open is your mind when you do that. The sofware result will be shaped by
> reality and usage anyway, and it will never be perfect because
> perfection is never in living things (and open developped software is a
> living organism) if not in their own existance.
> 

I really approve this kind of approach.

Cocoon is really convenient for doing complex things but it should be
convenient for simple things too (stateless templating as you said) to be
able to attract less involved developpers (It take us near one year of
intensive web application developpement around cocoon to be able to discuss
with you).

Dom in sitemap parameters is the kind of little addition (user point of
view) that could simplify some simple use cases with jx as well as with
flow. It gives a kind of access to the servicemanager via input modules
(one of the first thing you learn with cocoon) without knowing a thing on
avalon component lifecycle or existing java classes. You don't have to
implement any input module access in jx, it didn't compromise any existing
things either.

If you want to enforce some properties on jx (restrict the kind of objects,
deprecate $session, ...) you could do it after this little addition anyway.
(i'm sure these restrictions could help to give a better vision to new
users of what the sitemap, flow and jx are supposed to be and to do).

I don't feel strong enough for implementing such thing :-(, but i feel that
with the help of the the ObjectHelper and by implemeting a new method that
return object instead of object.tostring() in inputmodule (naive view) it
should be easy to pass object from sitemapcontroler to jxtg.

Don't hesitate (everybody) to point me to the right direction, i will be
happy to contribute if i estimate that my project will not suffering from
my involvement here.

Regards.

Éric.

Re: [RT] Management Prototype?

[Ugo Cei]

Il giorno 26/gen/05, alle 10:33, Reinhard Poetz ha scritto:
+0 (I think it makes sense trying it, but I can't help)
+0. Same as above.
  Ugo
--
Ugo Cei - http://agylen.com/blojsom/blog/


smime.p7s
Description: S/MIME cryptographic signature

Re: sitemap, jx and flow design (was: servicemanager and jxtg)

[Daniel Fagerstrom]

Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote: 

Seem to me like we have switched opinion with each other ;)
You know, over the last few years I have written tons of RTs 
describing more or less cool pipeline constructions for simplifying 
webapp development. And you have after more or less convincing 
argumentation stated: "thou shall use flow" and concluded with your 
obligatory -1.

My current interest is polishing the basic building blocks for 
building webapps: JXTG, flow, CForms and maybe some more stuff so 
that it becomes as coherent and "smooth" as possible and in some 
cases less monolithic.

Having such a gool I am more interested in seeing the usual "I don't 
want to use flow because of X" for something that seem close to the 
concern area for flow, as a good reason for discussing how to polish 
flow so that it fullfills its task better.

Maybe handling data types other than strings; DOM, Java Beans, SQL 
rowsets etc in the sitemap is an excelent idea. But my gut feeling, 
after having spend considerable time thinking about building webapps 
with sitemap constructions, is that it doesn't stop there, we need 
some other sitemap constructions to make it really useful. And as 
said I feel more for polishing the flowscript way, than being part of 
developing alternative solutions. But you don't need my blessing for 
discussing and developing such things if you feel a need for it.

My girlfriend tells me that sometimes it seems like I argue for the 
sake of arguing.., that I would take the other side no matter what... 
and that in a single conversation I might argue about why something is 
black and then argue about the same thing is white once I change the 
other person's opinion.
I could have guesed that, and I'm sory to say, you are severely 
mistaken, and so are your girlfriend ... its green.

I know I do that... and the reason why I do that is that I force 
people to convince themselves before convincing me.
And now you are trying to convice yourself that it has a higher goal 
than just the fun of arguing ;) Anyway it gets us more viewers, people 
just love to hate soap operas.

There is no such thing as being right or wrong especially if we 
don't understand what we really want in the first place.
A professor in law once told me: The important thing is not being right, 
the important thing is getting right.

By sharing a common vision we as a community can "getting right", by 
diffusing our energy in bikesheding and developing half baked solutions 
within various paradigms ... You know, there might be other beasts in 
the jungle who are lean and mean and eager to take our niche.

A common vision is about things we all can stand up and speak proudly 
about: "Modern Cocoon is about the power trio", "real blocks", "SoC".

I think that as long as cocoon grows incrementally and organically, 
there is no problem in any approach and that usage will tell us if 
something was a good idea or a bad one.
I agree with that, but we also need to prune the bad ideas. Todays life 
is not only shaped by incremental development but also by catastrophes 
and mass extermination.

So, to cut it short: it really doesn't matter what you are saying but 
*how much you are willing to suffer to get it across* :-)
I'm prepared to take the pain of persistently seeing where our vision 
leads us.

More than anything, I act as a filter. A pain in your butt. I play 
death in a design chess game... where the community is what wins.
Or get overtaken by another community ;)
So, it doesn't really matter what you do or propose, but how and how 
open is your mind when you do that. The sofware result will be shaped 
by reality and usage anyway,
And reality and usage will be influenced by powerfull ideas, if we take 
the pain to make them real.

and it will never be perfect because perfection is never in living 
things (and open developped software is a living organism) if not in 
their own existance.
It will not be perfect, but the strive for perfectness is a powerfull 
source for keeping the entropy outside our system. Unfortunally it might 
be an even stronger force for keeping us "bikeshedding" ;)

/Daniel

Re: FOM & FAPI (wasRe: FOM & input modules)

[Torsten Curdt]

 flow.sendPageAndWait(),
 flow.getComponent(),
 flow.redirect()
With javaflow the whole "script" naming scheme does not really fit 
...even if you get a script-like behaviour with the compiling 
classloader ...IMO

WDYT?

You're falling in the same trap again ;-)
Why should the flowscript API and javaflow API be the same? In javaflow, 
you have access to Avalon-related data such as the service manager and 
therefore don't need flow{script}.getComponent().
Well, ok... the getComponent() will not be necessary
(that was stupid ..I should have removed that line)
...but I am not proposing the same API - just the
same naming scheme where possible.
IMHO for the user it would be nice to see that the
methodnames in flowscript and javaflow are very similiar.
...although the APIs can be different I would like to
see the API being as close as possible.
cheers
--
Torsten

Cocoon-2.1.X Tests Failure 01/26/05

[Vadim Gritsenko]

Automated Cocoon Unit tests failed!

Full log file if this unit test run is available here:
http://nagoya.apache.org/~vadim/cocoon-test-log-20050126.log

Last messages from the log file:
==
  [foreach] reader-mime-type.xml:39: Starting 
http://localhost:1///samples/test/reader-mime-type/test20.html
  [foreach] reader-mime-type.xml:41: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:39: Finished 
http://localhost:1///samples/test/reader-mime-type/test20.html (107ms)
  [foreach] reader-mime-type.xml:44: Starting 
http://localhost:1///samples/test/reader-mime-type/test20.html
  [foreach] reader-mime-type.xml:46: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:44: Finished 
http://localhost:1///samples/test/reader-mime-type/test20.html (36ms)
  [foreach] reader-mime-type.xml:50: Starting 
http://localhost:1///samples/test/reader-mime-type/test30.html
  [foreach] reader-mime-type.xml:52: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:50: Finished 
http://localhost:1///samples/test/reader-mime-type/test30.html (469ms)
  [foreach] reader-mime-type.xml:55: Starting 
http://localhost:1///samples/test/reader-mime-type/test30.html
  [foreach] reader-mime-type.xml:57: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:55: Finished 
http://localhost:1///samples/test/reader-mime-type/test30.html (86ms)
  [foreach] reader-mime-type.xml:61: Starting 
http://localhost:1///samples/test/reader-mime-type/test40.html
  [foreach] reader-mime-type.xml:63: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:61: Finished 
http://localhost:1///samples/test/reader-mime-type/test40.html (20ms)
  [foreach] reader-mime-type.xml:66: Starting 
http://localhost:1///samples/test/reader-mime-type/test40.html
  [foreach] reader-mime-type.xml:68: Running test [Header: Content-type = 
text/html ... done (1ms)
  [foreach] reader-mime-type.xml:66: Finished 
http://localhost:1///samples/test/reader-mime-type/test40.html (27ms)
  [foreach] reader-mime-type.xml:72: Starting 
http://localhost:1///samples/test/reader-mime-type/test50.html
  [foreach] reader-mime-type.xml:74: Running test [Header: Content-type = 
text/html  Failure: 
file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:74:
  message doesn't match because header 'content-type' is not present
  [foreach] ... done (7ms)
  [foreach] reader-mime-type.xml:72: Finished 
http://localhost:1///samples/test/reader-mime-type/test50.html (46ms)
BUILD FAILED
file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72:
 Task at 
file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72:
  failed
Total time: 26 seconds

Last messages from the server console:
==
[EMAIL PROTECTED]: Startup sequence initiated from main() method
[EMAIL PROTECTED]: Loaded properties from 
[/disk/raid0/home/vadim/svn/cocoon-2.1.X/server.properties]
[EMAIL PROTECTED]: Initiating startup sequence...
[EMAIL PROTECTED]: Server socket opened successfully in 10 ms.
[EMAIL PROTECTED]: Database [index=0, id=0, 
db=file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db/cocoondb,
 alias=] opened sucessfully in 1554 ms.
[EMAIL PROTECTED]: Startup sequence completed in 1618 ms.
[EMAIL PROTECTED]: 2005-01-26 01:28:51.29 HSQLDB server 1.7.3 is online
[EMAIL PROTECTED]: To close normally, connect and execute SHUTDOWN SQL
[EMAIL PROTECTED]: From command line, use [Ctrl]+[C] to abort abruptly
- The database 'db' root directory has been set to 
/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db. Keep in mind 
that if a war upgrade will take place the database will be lost.
- Database points to 
/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db
- [main] '/db/system/SysSymbols' Set object system_SysConfig
- [main] '/db/system/SysConfig' Set document database.xml
- [main] '/db/system/SysSymbols' Set object meta_Metas
- [main] '/db/system/SysSymbols' Set object meta_Metas_system_SysConfig
- Database 'db' successfully opened
- Xindice server successfully started
parameter = @PARAMETER@  replaceme = replaceme-abc
parameter = @PARAMETER@  replaceme = replaceme-123
- VM shutting down with the disk store for cocoon-ehcache-1 still active. The 
disk store is persistent. Calling dispose...
- Database 'db' successfully closed
- Scheduler Cocoon_$_Wed_Jan_26_01:28:40_PST_2005 paused.
- Scheduler Cocoon_$_Wed_Jan_26_01:2

Re: [RT] Management Prototype?

[Reinhard Poetz]

Carsten Ziegeler wrote:
I think one area were Cocoon really lacks in functionality is 
administration. We briefly discussed this topic some months ago.

WDYT about implementing a prototype with JMX? Don't know how this could 
look like or what it can do, but perhaps someone with JMX knowledge has 
some cool ideas, she is willing to test implement into 2.2. Based on 
this prototype we could decide if it's worth going down this road or if 
we should search for a different solution.

I know that there are a lot of pros and cons for/against JMX - the 
discussion on the geronimo list is a good example of this. But it seems 
that every project is using JMX, so imho we shouldn't "invent" something 
different.

Carsten
+0 (I think it makes sense trying it, but I can't help)
--
Reinhard

Re: [RT] Management Prototype?

[Sylvain Wallez]

Carsten Ziegeler wrote:
I think one area were Cocoon really lacks in functionality is 
administration. We briefly discussed this topic some months ago.

WDYT about implementing a prototype with JMX? Don't know how this 
could look like or what it can do, but perhaps someone with JMX 
knowledge has some cool ideas, she is willing to test implement into 
2.2. Based on this prototype we could decide if it's worth going down 
this road or if we should search for a different solution.

I know that there are a lot of pros and cons for/against JMX - the 
discussion on the geronimo list is a good example of this. But it 
seems that every project is using JMX, so imho we shouldn't "invent" 
something different.

+1.
I was thinking exactly the same recently and started (lazily) looking at 
how we could create wrapper MBeans for components in the core service 
manager.

There are also more and more cool JMX management consoles, and we 
definitely shouldn't need to invent our own.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

[RT] Management Prototype?

[Carsten Ziegeler]

I think one area were Cocoon really lacks in functionality is 
administration. We briefly discussed this topic some months ago.

WDYT about implementing a prototype with JMX? Don't know how this could 
look like or what it can do, but perhaps someone with JMX knowledge has 
some cool ideas, she is willing to test implement into 2.2. Based on 
this prototype we could decide if it's worth going down this road or if 
we should search for a different solution.

I know that there are a lot of pros and cons for/against JMX - the 
discussion on the geronimo list is a good example of this. But it seems 
that every project is using JMX, so imho we shouldn't "invent" something 
different.

Carsten

Re: FOM & FAPI (wasRe: FOM & input modules)

[Sylvain Wallez]

Torsten Curdt wrote:
So I think we should clearly separate the FOM (the JS wrapper of the 
OM) from the FAPI, the flowscript API which gathers 
flowscript-related utility functions by attaching them for a new 
"flowscript" object.

We would therefore have:
- cocoon.request, cocoon.context, cocoon.mymodule, etc.
- flowscript.sendPageAndWait(), flowscript.getComponent(), 
flowscript.redirect(), etc.

sounds good to me ...one tiny thing though: I'd prefer the name "flow" 
...so

 flow.sendPageAndWait(),
 flow.getComponent(),
 flow.redirect()
With javaflow the whole "script" naming scheme does not really fit 
...even if you get a script-like behaviour with the compiling 
classloader ...IMO

WDYT?

You're falling in the same trap again ;-)
Why should the flowscript API and javaflow API be the same? In javaflow, 
you have access to Avalon-related data such as the service manager and 
therefore don't need flow{script}.getComponent().

So the FSAPI (flowscript API) should be defined separately from the 
JFAPI (javaflow API), even if they share some concepts and/or function 
names related to the fact that they both manage flow, such as 
sendPageAndWait().

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: FOM & FAPI (wasRe: FOM & input modules)

[Reinhard Poetz]

Torsten Curdt wrote:
So I think we should clearly separate the FOM (the JS wrapper of the 
OM) from the FAPI, the flowscript API which gathers flowscript-related 
utility functions by attaching them for a new "flowscript" object.

We would therefore have:
- cocoon.request, cocoon.context, cocoon.mymodule, etc.
- flowscript.sendPageAndWait(), flowscript.getComponent(), 
flowscript.redirect(), etc.

sounds good to me ...one tiny thing though:
I'd prefer the name "flow" ...so
 flow.sendPageAndWait(),
 flow.getComponent(),
 flow.redirect()
With javaflow the whole "script" naming scheme does not
really fit ...even if you get a script-like behaviour
with the compiling classloader ...IMO
WDYT?
I agree
--
Reinhard

Re: sitemap, jx and flow design (was: servicemanager and jxtg)

[BURGHARD Éric]

Reinhard Poetz wrote:

> Two days ago, I wrote about my usecase for chained input modules. Daniel
> answered, that in his opinion this looks like voodoo and suggested to have
> a global action that is executed for every request. Wouldn't this be the
> solution for passing objects to the view layer either?
> Currently JXTG gives access to the session, the request and the
> application context. So using them as container is possible today. The
> drawback: The contract isn't defined very well because in your template
> you have to to something like this:
> 
> ${cocoon.request.getAttribute('xyz')}
> 
> A weak contract IMO.
> 
> Having a strong contract like
> 
> 
> object="{$cocoon.request.getAttribute('userprofile')}"/>
> 
> 
> could help us to make templates more side-effect free because then we
> could forbid the direct access of the request and the session from within
> templates:
> 
> 
>{$userprofile.getName()}
> 
> 
> We could even go a step further and enforce explicit variable declaration:
> 
> 
>
>{$userprofile.getName()}
> 
> 
> Unfortunatly those templates wouldn't still be side-effect free, because
> nobody prevents me from doing
> 
> {$userprofile.getRole().setName('newRoleName')}
>

Yeah, and that's why IoC and SoC are already broken in jx. But as i use to
say if you want to break SoC and IoC you could do it whatever the
implementation. Even a simple  break IoC
because the view request something to the controler.

At least if you restrict the kind of object you could pass via the sitemap
parameters you could prevent side effects on workflow objects (session,
request, userprofile) without beeing force to deprecate java calls which
seems to be usefull for some java.util.

> 
>> And as said I feel
>> more for polishing the flowscript way, than being part of developing
>> alternative solutions.
> 
> Maybe you can comment on my response all the same :-)
> 

WDYT ?

Re: FOM & FAPI (wasRe: FOM & input modules)

[Torsten Curdt]

So I think we should clearly separate the FOM (the JS wrapper of the OM) 
from the FAPI, the flowscript API which gathers flowscript-related 
utility functions by attaching them for a new "flowscript" object.

We would therefore have:
- cocoon.request, cocoon.context, cocoon.mymodule, etc.
- flowscript.sendPageAndWait(), flowscript.getComponent(), 
flowscript.redirect(), etc.
sounds good to me ...one tiny thing though:
I'd prefer the name "flow" ...so
 flow.sendPageAndWait(),
 flow.getComponent(),
 flow.redirect()
With javaflow the whole "script" naming scheme does not
really fit ...even if you get a script-like behaviour
with the compiling classloader ...IMO
WDYT?
cheers
--
Torsten

Re: FOM & FAPI (wasRe: FOM & input modules)

[Carsten Ziegeler]

Sylvain Wallez wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Hmm, the question is: how can a pluggable object model work - or how 
can it be extended? What about using...input modules for exactly 
this? We create a way of "mounting" input modules into the object 
model, like this:

  


And then you can simple access the info by ${cocoon.skin.something}.


I like it. Object model and input modules are just different names for 
similar things: accessing environmental data. Also, it's better to 
attach IMs to the cocoon object rather than as root variables, as it 
avoids name clashes with template variables.

Something we have to be careful of, though, is that properties of the 
cocoon object comes both from the OM (request, response, context) and 
modules, and that it should be forbidden to have IMs having the same 
name as OM keys.

I also would like to insist on the fact that FOM (flow object model) 
is nothing more than OM (object model) that we have everywhere in 
Cocoon, but rewrapped as JS objects. So we should better concentrate 
on the OM itself and let its JS counterpart follow its evolutions.

Thinking further (while sleeping!), it seems to me that over time we 
have abused the cocoon object in flowscript by making it an entry point 
not only to the OM, but also to some flowscript-specific utilities, e.g. 
getComponent(), processPipelineTo(), makeWebContinuation(), and of 
course cocoon.sendPageAndWait()

And this causes a lot of confusion, as we use the same "cocoon" name in 
other places (jxtg) with only the OM meaning.

So I think we should clearly separate the FOM (the JS wrapper of the OM) 
from the FAPI, the flowscript API which gathers flowscript-related 
utility functions by attaching them for a new "flowscript" object.

We would therefore have:
- cocoon.request, cocoon.context, cocoon.mymodule, etc.
- flowscript.sendPageAndWait(), flowscript.getComponent(), 
flowscript.redirect(), etc.

Of course, if we choose to go that way, we must keep the current 
functions on the cocoon object for back compatibility but clearly mark 
them as deprecated.

IMO, that separation would clarify things a lot, by clearly defining a 
single object model, be it in Java, flowscript, jxtg, etc.

WDYT?
Sounds good to me - and we should define the OM (= Java API) and later 
wrap it for JS.

Carsten

FOM & FAPI (wasRe: FOM & input modules)

[Sylvain Wallez]

Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Hmm, the question is: how can a pluggable object model work - or how 
can it be extended? What about using...input modules for exactly 
this? We create a way of "mounting" input modules into the object 
model, like this:

  


And then you can simple access the info by ${cocoon.skin.something}.

I like it. Object model and input modules are just different names for 
similar things: accessing environmental data. Also, it's better to 
attach IMs to the cocoon object rather than as root variables, as it 
avoids name clashes with template variables.

Something we have to be careful of, though, is that properties of the 
cocoon object comes both from the OM (request, response, context) and 
modules, and that it should be forbidden to have IMs having the same 
name as OM keys.

I also would like to insist on the fact that FOM (flow object model) 
is nothing more than OM (object model) that we have everywhere in 
Cocoon, but rewrapped as JS objects. So we should better concentrate 
on the OM itself and let its JS counterpart follow its evolutions.

Thinking further (while sleeping!), it seems to me that over time we 
have abused the cocoon object in flowscript by making it an entry point 
not only to the OM, but also to some flowscript-specific utilities, e.g. 
getComponent(), processPipelineTo(), makeWebContinuation(), and of 
course cocoon.sendPageAndWait()

And this causes a lot of confusion, as we use the same "cocoon" name in 
other places (jxtg) with only the OM meaning.

So I think we should clearly separate the FOM (the JS wrapper of the OM) 
from the FAPI, the flowscript API which gathers flowscript-related 
utility functions by attaching them for a new "flowscript" object.

We would therefore have:
- cocoon.request, cocoon.context, cocoon.mymodule, etc.
- flowscript.sendPageAndWait(), flowscript.getComponent(), 
flowscript.redirect(), etc.

Of course, if we choose to go that way, we must keep the current 
functions on the cocoon object for back compatibility but clearly mark 
them as deprecated.

IMO, that separation would clarify things a lot, by clearly defining a 
single object model, be it in Java, flowscript, jxtg, etc.

WDYT?
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }