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:
object-model
mount
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:
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.
-
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
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,
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,
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
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
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
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
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
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
snip/
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
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
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
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
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
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'
Daniel Fagerstrom wrote:
BURGHARD Éric wrote:
generate type=jx src=..
!-- pass authentication dom to jx --
parameter name=auth dom={session-context:authentication}/
/generate
I have never disputed that things might be clumsy now, I just think we
should focus on getting the flowscript way
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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=9916.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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:
object-model
mount
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,
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
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:
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
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
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
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
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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32263.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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
On Wed, 26 Jan 2005 08:09:45 -0500, Vadim Gritsenko
[EMAIL PROTECTED] wrote:
Daniel Fagerstrom wrote:
BURGHARD Éric wrote:
generate type=jx src=..
!-- pass authentication dom to jx --
parameter name=auth dom={session-context:authentication}/
/generate
I have never disputed
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
BURGHARD Éric wrote:
generate type=jx src=..
!-- pass authentication dom to jx --
parameter name=auth dom={session-context:authentication}/
/generate
I have never disputed that things might be clumsy now, I just think
we should focus on
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 @@
description
Delivery context library
/description
-home nested=ib/optional/
+home nested=lib/optional/
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 @@
description
Delivery context library
/description
-home nested=ib/optional/
+
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
36 matches
Mail list logo
