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 blessi
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 rel
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 Noels
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 eas
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
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
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
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, there do
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.3&content-type=text/plain
In order to communicate with XMLFormTransformer and to handle
re
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.3&content-type=text/plain
In order to communicate with XMLFormTransformer and to handle
restarting continuations, this
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
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 m
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
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 like it much, as AFAIU it w
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
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 pre
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.
>>
>
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"?
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
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
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 in
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
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 diff
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 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 alway
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
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 var
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 alwa
> > 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 bet
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 alway
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 getContin
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 if
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 th
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 si
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
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 no
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 is
On Monday, March 17, 2003, at 08:02 PM, Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
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");
cocoon.lo
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
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 m
Christopher Oliver 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 ?
That would work.
Excellent! I've grepped sources, seen those awful
((Environment)resolver) type casts, and
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
com
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-dev&m=104673257019781&w=2
This seems eas
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-dev&m=104673257019781&w=2
This seems easy to fix. But I personally d
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-dev&m=104673257019781&w=2
This seems easy to fix. But I personally don't understand the
"obje
44 matches
Mail list logo
