Christopher Oliver wrote:
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/xmlForm.js?rev=1.3content-type=text/plain
In order to communicate with XMLFormTransformer and to handle
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
snip/
Only because of the design of XMLForm: it stores the form view in
the object model and several of the methods of
org.apache.cocoon.component.xmlform.Form require the object model as
a parameter.
Ah, ok.
Regardless of the flow,
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
It's already not easy to separate! I can think of how to resolve
issue 1 (dedicated FlowObjectModelHelper: ugly, but works)
yuck!
So, what do we do? Carsten, may I have your blessing for adding helper
methods to ObjectModelHelper? I can even
Hi All!
Jumping into this thread a bit late...
On Tue, Mar 18, 2003 at 10:31:03AM -0800, Christopher Oliver wrote:
You're not abusing sessions. cocoon.createSession() exists exactly for
the purpose you mention. Nobody is suggesting that we remove it. What at
least I was
On 14/03/2003 19:18 Christopher Oliver wrote:
Here's a summary of some of the recent issues with the Flow for discussion:
Completely unrelated to the technical discussion which is way above my
head, I found a nice weblog discussing graphical depictions of flow -
with a well-known and not too
On 19/03/2003 23:42 Steven Noels wrote:
Completely unrelated to the technical discussion which is way above my
head, I found a nice weblog discussing graphical depictions of flow -
with a well-known and not too easy example:
Some further linking: http://www.jjg.net/ia/visvocab/
/Steven
--
Hi Marcus,
Those are very good questions. And I don't know the answer. See my
response to Vadim about scopes and compiling scripts. We need to
partition the scripts by application somehow.
What defines an application in Cocoon. For example, does each get a
separate class loader? Is there a
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
It's already not easy to separate! I can think of how to resolve
issue 1 (dedicated FlowObjectModelHelper: ugly, but works)
yuck!
So, what do we do? Carsten, may I have your blessing for adding helper
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
1) do we really need the session object? the flow is in fact
deprecating the use of sessions for storing stateful data. I would
love to *force* people to think into this way by not making the
session available to them. We can always add it later
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
I don't think this will make it difficult to separate it : the object
model is a Map which can hold any kind of objects, and
instrospection-based accessors such as JXPath don't care about the
actual class of objects.
1) Helper functions like
Ugo Cei wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
1) do we really need the session object? the flow is in fact
deprecating the use of sessions for storing stateful data. I would
love to *force* people to think into this way by not making the
session available to them. We can
I am somehow aware that I am abusing sessions here, and that there
is a better way, but it's not that easy to follow, probably. If you
can show it to me, I'd be glad to abandon sessions, but if you take
them away right now, I'm going to be in trouble ;-).
Great, integration between
Ugo Cei wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
1) do we really need the session object? the flow is in fact
deprecating the use of sessions for storing stateful data. I would
love to *force* people to think into this way by not making the
session available to them. We can
Sylvain Wallez wrote:
Ugo Cei wrote:
This is something that I don't fully understand : when you call
cocoon.createSession(), global variables of the various scripts of a
given sitemap are shared through the session. This means, AFAIU, that
each user has then its own independent set of global
Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Ugo Cei wrote:
Sylvain Wallez wrote:
I'm using the flow and I'm using sessions too. The applications I'm
currently developing with the flow are composed of many independent
flows, each with its own entry point. Consider the case of an
Ugo Cei wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
1) do we really need the session object? the flow is in fact
deprecating the use of sessions for storing stateful data. I would
love to *force* people to think into this way by not making the
session available to them. We can
Upayavira wrote:
I am somehow aware that I am abusing sessions here, and that there
is a better way, but it's not that easy to follow, probably. If you
can show it to me, I'd be glad to abandon sessions, but if you take
them away right now, I'm going to be in trouble ;-).
Great, integration
Stefano Mazzocchi wrote:
Great, integration between different not-all-flowable parts is a *real*
need for sessions in the FOM.
So +1 to add it.
Anybody against it?
Stefano.
-1 for this reason. As mentioned in other mails, direct access to the
session isn't needed in Ugo's case.
+1 for a
Pier Fumagalli wrote:
On 17/3/03 20:02, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, I would go for
global - contains global log methods, no properties
global doesn't have a meaning in IDL, therefore I created the Script
object, which will contain also the reference to the function called
Christopher Oliver wrote:
Stefano Mazzocchi wrote:
Great, integration between different not-all-flowable parts is a
*real* need for sessions in the FOM.
So +1 to add it.
Anybody against it?
Stefano.
-1 for this reason. As mentioned in other mails, direct access to the
session isn't needed
Christopher Oliver wrote:
Pier Fumagalli wrote:
On 17/3/03 20:02, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, I would go for
global - contains global log methods, no properties
global doesn't have a meaning in IDL, therefore I created the Script
object, which will contain also the
Stefano Mazzocchi wrote:
Another possibility is to only expose the session at the Java level
(not JavaScript) forcing new JavaScript objects that need access to it
to be written in Java. This might prevent abuse.
Hmmm, if you don't get a hook to the ObjectModel, how can you get a java
session
On 18/3/03 19:06, Christopher Oliver [EMAIL PROTECTED] wrote:
global doesn't have a meaning in IDL, therefore I created the Script
object, which will contain also the reference to the function called from
the sitemap...
How about calling the class of this object just Flow? That's what it
On 18/3/03 21:29, Christopher Oliver [EMAIL PROTECTED] wrote:
Stefano Mazzocchi wrote:
Another possibility is to only expose the session at the Java level
(not JavaScript) forcing new JavaScript objects that need access to it
to be written in Java. This might prevent abuse.
Hmmm, if you
Pier Fumagalli wrote:
On 18/3/03 21:29, Christopher Oliver [EMAIL PROTECTED] wrote:
Stefano Mazzocchi wrote:
Another possibility is to only expose the session at the Java level
(not JavaScript) forcing new JavaScript objects that need access to it
to be written in Java. This might
Sylvain Wallez wrote:
Pier Fumagalli wrote:
On 18/3/03 21:29, Christopher Oliver [EMAIL PROTECTED] wrote:
Stefano Mazzocchi wrote:
Another possibility is to only expose the session at the Java level
(not JavaScript) forcing new JavaScript objects that need access to it
to be written in
On 18/3/03 23:00, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
But I have the impression i didn't understand what Pier was implying
because I'm sure he would not propose to force people to write that much
java gluecode just for everyday FOM usage.
Pier, can you elaborate more on what you
Pier Fumagalli wrote:
On 18/3/03 23:00, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
But I have the impression i didn't understand what Pier was implying
because I'm sure he would not propose to force people to write that much
java gluecode just for everyday FOM usage.
Pier, can you elaborate more
Christopher Oliver wrote:
Sylvain Wallez wrote:
I like your approach _MUCH_BETTER_... I think we should consider it
for most
of the stuff we make visible to the flow, rather than passing the
real Java
instances to Rhino (obviously removing the construction part when
needed)...
Mmmh, I don't
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/xmlForm.js?rev=1.3content-type=text/plain
In order to communicate with XMLFormTransformer and to handle
restarting continuations, this
Sylvain Wallez wrote:
What I suggested in the mail linked above is to use the object model,
already used as a communication means between the environment and other
components to communicate flow results. This suggestion comes both from
the fact that the object model is the natural way for the
On Monday, March 17, 2003, at 08:02 PM, Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
snip/
So, I would go for
global - contains global log methods, no properties
Why log methods? I don't understand what is so special about them, that
they need to be global?
cocoon.log.info(blah);
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
What I suggested in the mail linked above is to use the object model,
already used as a communication means between the environment and
other components to communicate flow results. This suggestion comes
both from the fact that the object model
Christopher Oliver wrote:
Sylvain Wallez wrote:
A short explanation about the object model. Cocoon abstracts its
runtime environment through the Environment interface. An Environment
object gives access to a number of things that are relevant to the
pipeline/sitemap engine only and should not
On 17/3/03 20:02, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I share your attach-a-method-to-an-object concern, which certainly
comes from our heavy Java background.
I'm sure it does, but after playing pretty hard with javascript for
DHTML, I can tell you that the hardest thing for me to
On 17/3/03 20:02, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, I would go for
global - contains global log methods, no properties
global doesn't have a meaning in IDL, therefore I created the Script
object, which will contain also the reference to the function called from
the sitemap...
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
So we need two more values in the object model Map : one for the
value dictionary, and one for the continuation.
How does it sound ?
I love it, but, as Carsten correctly pointed out, this will make it
harder to separate
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
Here's a summary of some of the recent issues with the Flow for
discussion:
1) Storing the flow context object and continuation in environment
attributes:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104673257019781w=2
This seems easy
Sylvain Wallez wrote:
A short explanation about the object model. Cocoon abstracts its
runtime environment through the Environment interface. An Environment
object gives access to a number of things that are relevant to the
pipeline/sitemap engine only and should not be visible from other
Christopher Oliver wrote:
Sylvain Wallez wrote:
snip/
So we need two more values in the object model Map : one for the
value dictionary, and one for the continuation.
How does it sound ?
That would work.
Excellent! I've grepped sources, seen those awful
((Environment)resolver) type
Vadim Gritsenko wrote:
Excellent! I've grepped sources, seen those awful
((Environment)resolver) type casts, and I think that we have to get rid
of this ASAP.
We need to remove the type casts. Yes!
Practical proposal:
* Add flow-continuation to the objectModel, and getter method to
Christopher Oliver wrote:
Here's a summary of some of the recent issues with the Flow for discussion:
1) Storing the flow context object and continuation in environment
attributes:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104673257019781w=2
This seems easy to fix. But I personally
Here's a summary of some of the recent issues with the Flow for discussion:
1) Storing the flow context object and continuation in environment
attributes:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104673257019781w=2
This seems easy to fix. But I personally don't understand the
43 matches
Mail list logo
