You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christopher Oliver <re...@verizon.net> on 2003/03/14 19:18:09 UTC
Discussion of Flow Issues
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
"objectModel". Can someone explain how to properly use it? But I think
there is a more fundamental design question here: namely, how should the
flow script communicate with generators, transformers, etc?
2) Concerns with exposing the componentManager:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104687345726726&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104687863701233&w=2
I personally do not know what the proper solution here is. Can someone
explain the proper use of component managers and make a suggestion on
how to solve this?
3) Duplication of functionality between VelocityGenerator and
FlowVelocityGenerator:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104673257019781&w=2
This is clearly bad, I agree. I think these could be merged back
together - the old behavior would apply if the flow context object isn't
available. But this probably depends somewhat on the answer to (1).
4) JavaScript Database API has no business being in the flow
We all agree on this. But we need someplace to put useful JavaScript
stuff - as part of optional "blocks" or something like that.
In my own use of the flow, I've also noticed the following bugs:
- Script reloading is partially broken. Sometimes scripts don't
reload properly. This is normal when you are in a continuation - the
continuation contains a compiled copy of the script and doesn't see the
new reloaded one. But it happens occasionally even in top level calls.
- With certain Exceptions the script file names and line numbers are
not reported
- Cocoon.load() doesn't work
I also noticed that it isn't fun to debug Velocity templates. If the
generated xml has errors, the XML parser reports the line number of the
generated xml document, which isn't preserved anywhere. In that case it
would be nice if the Velocity generator saved the generated xml document
somewhere, or at least logged it.
Thoughts?
Regards,
Chris
Re: Discussion of Flow Issues
Posted by Steven Noels <st...@outerthought.org>.
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>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Flow Issues
Posted by Steven Noels <st...@outerthought.org>.
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 easy example:
http://www.boxesandarrows.com/archives/yahoo_mail_simplicity_holds_up_over_time.php
If we ever need inspiration for that Flow editor in Cocoon 11.0 ... ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Flow Issues
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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 be visible from other
>> components to avoid uncontrolled access to data managed by the
>> pipeline/sitemap engine. These include for example the response
>> outpoutstream, the current context prefix (changed by <map:mount>), etc.
>>
>> To provide those parts of the Environment that are safe to be used by
>> other components and required by them to do their job, the
>> Environment provides a so-called object model
>> (Environment.getObjectModel()), which is a Map of named objects,
>> mainly Request and Response. This Map is passed to every sitemap
>> component during the call to setup().
>
>
> What objects besides the Request, Response, Session and Context are in
> the "object model"? The flow script doesn't use the Response (and if
> you use XMLForm, it doesn't use the Request either). The Session isn't
> needed because when you use flow scripts you can store your
> application state in JavaScript progam variables instead of as session
> attributes. So what's left?
Nothing, you listed them all :-)
>> 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
>> environment to communicate public information to other components,
>> and from the fact that we can consider flow data as some additional
>> data available in the sitemap when called from a flow script.
>>
>> 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. But as above, now what other objects are in the
> object model and what are they used for?
>
>>
>> I'm not sure this "FOM" thing has been defined compared to the
>> Environment's object model. My POV is that the FOM is the set of
>> objects that are visible as global variables in a flow script.
>>
>> This must include :
>> - the Environment's object model (but not the Environment itself),
>> - Avalon-related objects that Java components (as opposed to
>> JavaScript) obtain through the Avalon lifecycle interfaces. These are
>> the Logger, the (Avalon) Context, and the ComponentManager. I don't
>> know if there's a need for a Configuration.
>
>
> I don't understand this. Can you explain what "Avalon-related" objects
> are?
Avalon-related objects are those that are made available to components
by the Avalon framework through the various lifecycle interface. These
are a Logger (LogEnabled interface), an Avalon context (Contextualizable
interface), a ComponentManager (Composable interface) and a
Configuration (Configurable interface), although this last one doesn't
really makes sense for the flow.
<snip/>
>>>
>>> So, I would like to propose to remove Global or empty it and move
>>> everything over to the Cocoon object.
>>>
>>> This means that instead of doing stuff like:
>>>
>>> sendPage(...)
>>>
>>> I propose to do
>>>
>>> cocoon.sendPage()
>>>
>>> which outlines the fact that it's not the flow that sends the page,
>>> but it's cocoon that does (control is given back to the sitemap
>>> before sending the page).
>>
>
> Agree. But for the second reason: I think sendPage() is really an
> operation of the "cocoon".
Cool. Seems like we're rapidly converging towards a consensus :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Christopher Oliver <re...@verizon.net>.
Vadim Gritsenko wrote:
> Christopher Oliver wrote:
>
>> Vadim Gritsenko wrote:
>>
>>>
>>> Here you will have to explain to me why: Why whould you want to pass
>>> *only* this "bean"?
>>
>>
>>
>> Because that is the "contract" between the flowscript and the
>> presentation layer.
>
>
>
> In Cocoon apps, presentation layer is usually XSL (and CSS) stylesheets.
> XSP pages or velocity templates should be used as data generation layer.
> In addition to these, there are ways to generate data out of XML:DB,
> CVS, simple XML files, directories, and remote sources; and ways to
> generate data using Transformers (not everybody likes XSPs), whole bunch
> of them.
What I refered to as the "presentation layer" includes generators as well.
>>
>>
>>
>> Because when using the flow you maintain the application state in
>> JavaScript program variables.
>
>
>
> And javascript program variables can be stored as object in session:
> WebContinuation w =
> session.getAttribute("org.apache.cocoon.flow.WebContinuation");
Yes, that's true but the flowscript author doesn't need to know about or
explicitly manage the session. He just calls
cocoon.createSession();
and stores data in javascript variables.
>
> Essentially same is done for session-fw and xscript.
>
>
>>> And also, how you will access session-fw data if you won't pass
>>> session object? Same for xscript data and request/session/context
>>> objects?
>>
>>
>>
>> Not sure what you mean here. Can you explain?
>
>
>
> There is session-fw, originally part of the Cocoon Portal; if you want
> to use flow with portal you better have access to this session objects
> in "flow presentation layer". XScript is a logicsheet which is somewhat
> similar to session-fw, but with access to data from XSP, not from
> Transformers. Recenlty addition has been proposed to allow access to the
> session-fw from the XSPs too (session-fw logicsheet).
>
I did find this in the archives:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103149427903698&w=2
The author was having problems using flow with the Portal. I don't fully
understand the problem he experienced though.
Regards,
Chris
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 17/03/2003 20.31:
> Vadim Gritsenko wrote:
>
...
>> The only thing which is missing is flow continuation and bean (new
>> kids), but these are provided by jpath logicsheet. And I can't built
>> them into core XSP because people want to separate flow into the block.
>
> Between a hack-based flow implementation driven by the need to factor
> flow out and a clean flow implementation with no possibility to factor
> it out, I would vote for the second.
But in the above case in the worst scenario we would have that XSPs
depend on the flow module being present.
> If the flow, in order to fit nicely in the cocoon picture, needs to
> accomodate changes in the internal architecture, it meanst that is
> should not be optional.
>
> on the other hand, if we can find an elegant solution to keep them
> separate I'm all for it, but elegant integration is, IMO, more important
> than potential separation.
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
> Umm... XSPs should be compared to JSPs, and yes, we already have set of
> built-in objects (see any XSP java source file, or see XSPGenerator.java):
>
> /* Built-in parameters available for use */
> // context - org.apache.cocoon.environment.Context
> // request - org.apache.cocoon.environment.Request
> // response - org.apache.cocoon.environment.Response
> // parameters - parameters defined in the sitemap
> // objectModel- java.util.Map
> // resolver - org.apache.cocoon.environment.SourceResolver
>
> The only thing which is missing is flow continuation and bean (new
> kids), but these are provided by jpath logicsheet. And I can't built
> them into core XSP because people want to separate flow into the block.
Between a hack-based flow implementation driven by the need to factor
flow out and a clean flow implementation with no possibility to factor
it out, I would vote for the second.
If the flow, in order to fit nicely in the cocoon picture, needs to
accomodate changes in the internal architecture, it meanst that is
should not be optional.
on the other hand, if we can find an elegant solution to keep them
separate I'm all for it, but elegant integration is, IMO, more important
than potential separation.
Stefano.
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Vadim Gritsenko <va...@verizon.net>.
Christopher Oliver wrote:
> Vadim Gritsenko wrote:
>
>> You may discourage usage of these objects for the sake of perfectness
>> of the MVC in the documentation but I don't think you should insist
>> on disabling access to them (like in FlowVelocityGenerator).
>>
>> Fair?
>
>
> I think you're right.
>
> JSTL seems to take the approach of exposing session, request, and
> application properties as "implicit objects" in its expression language.
>
> "The JSTL expression language defines a set of implicit objects"
<snip/>
> So, do you think the same can be done with the elements of the object
> model?
Umm... XSPs should be compared to JSPs, and yes, we already have set of
built-in objects (see any XSP java source file, or see XSPGenerator.java):
/* Built-in parameters available for use */
// context - org.apache.cocoon.environment.Context
// request - org.apache.cocoon.environment.Request
// response - org.apache.cocoon.environment.Response
// parameters - parameters defined in the sitemap
// objectModel- java.util.Map
// resolver - org.apache.cocoon.environment.SourceResolver
The only thing which is missing is flow continuation and bean (new
kids), but these are provided by jpath logicsheet. And I can't built
them into core XSP because people want to separate flow into the block.
> * pageScope - a Map that maps page-scoped attribute names to their
> values
> * requestScope - a Map that maps request-scoped attribute names to
> their values
> * sessionScope - a Map that maps session-scoped attribute names to
> their values
> * applicationScope - a Map that maps application-scoped attribute
> names to their values
Sidenote: If you want scoped XML variables in XSP, take a look at xscript.
Vadim
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Christopher Oliver <re...@verizon.net>.
Vadim Gritsenko wrote:
> Christopher Oliver wrote:
> You may discourage usage of these objects for the sake of perfectness of
> the MVC in the documentation but I don't think you should insist on
> disabling access to them (like in FlowVelocityGenerator).
>
> Fair?
>
>
> Vadim
>
>
I think you're right.
JSTL seems to take the approach of exposing session, request, and
application properties as "implicit objects" in its expression language.
"The JSTL expression language defines a set of implicit objects:
* pageContext - the PageContext object
* pageScope - a Map that maps page-scoped attribute names to their
values
* requestScope - a Map that maps request-scoped attribute names to
their values
* sessionScope - a Map that maps session-scoped attribute names to
their values
* applicationScope - a Map that maps application-scoped attribute
names to their values
* param - a Map that maps parameter names to a single String
parameter value (obtained by calling ServletRequest.getParameter(String))
* paramValues - a Map that maps parameter names to a String[ ] of
all values for that parameter (obtained by calling
ServletRequest.getParameterValues(String))
* header - a Map that maps header names to a single String header
value (obtained by calling ServletRequest.getheader(String))
* headerValues - a Map that maps header names to a String[ ] of all
values for that parameter (obtained by calling
ServletRequest.getHeaders(String))
* cookie - a Map that maps cookie names to a single Cookie
(obtained by calling HttpServletRequest.getCookie(String))
* initParam - a Map that maps a parameter names to a single String
parameter value (obtained by calling
ServletRequest.getInitParameter(String))
When an expression references one of these objects by name, the
appropriate object is returned instead of the corresponding attribute.
For example: ${pageContext} returns the PageContext object, even if
there is an existing pageContext attribute containing some other value."
So, do you think the same can be done with the elements of the object model?
Regards,
Chris
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Vadim Gritsenko <va...@verizon.net>.
Christopher Oliver wrote:
> Vadim Gritsenko wrote:
>
>> Christopher Oliver wrote:
>>
>>> That's not the case. All are equally crippled ;) For example, when
>>> using Xsp, the idea is that the only logic sheet you will ever use
>>> is the jpath logic sheet. This does not give you direct access to
>>> session, request, or context but only to the bean object. Likewise
>>> with XMLForm, you only have access to the bean itself.
>>
>>
>>
>> HUH?
>> /me extremely puzzled
>>
>
> Sorry, I'm not doing a better job explaining...
No, I understood what you said, I'm puzzled by the decision taken.
> Since you responded to it I guess you did read this:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103128978404439&w=2
I'll bookmark it :)
> I'm not saying anything different. To quote Ovidiu:
>
> "The above explains how MVC could be really achieved in Cocoon with the
> control flow layer. Note that there is no direct communication between
> Model and View, everything is directed by the Controller by passing to
> View a context object constructed from Model data. In a perfect world,
Usually, there is a problem with something "perfect" - it ends up dead ;-)
(i.e.: ideal is not achievable)
I've not thought a lot about
"flow-bean-only-controlled-data-generation", but from the short glance I
see that some of the existing Cocoon parts won't be easily integrated
with this approach. Thus, it's logical to assume that one should still
have access to request/session as one had it before.
You may discourage usage of these objects for the sake of perfectness of
the MVC in the documentation but I don't think you should insist on
disabling access to them (like in FlowVelocityGenerator).
Fair?
Vadim
> XSP should have only one logicsheet, the JXPath logicsheet. There
> should be no other things in an XSP page that put logic in the page
> (read View), instead of the Model. If you don't like XSP, and prefer to
> use JSP or Velocity, the JXPath logicsheet equivalents should be
> implemented."
>
> Regards,
>
> Chris
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Christopher Oliver <re...@verizon.net>.
Vadim Gritsenko wrote:
> Christopher Oliver wrote:
>> That's not the case. All are equally crippled ;) For example, when
>> using Xsp, the idea is that the only logic sheet you will ever use is
>> the jpath logic sheet. This does not give you direct access to
>> session, request, or context but only to the bean object. Likewise
>> with XMLForm, you only have access to the bean itself.
>
>
>
> HUH?
> /me extremely puzzled
>
Sorry, I'm not doing a better job explaining...
Since you responded to it I guess you did read this:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103128978404439&w=2
I'm not saying anything different. To quote Ovidiu:
"The above explains how MVC could be really achieved in Cocoon with the
control flow layer. Note that there is no direct communication between
Model and View, everything is directed by the Controller by passing to
View a context object constructed from Model data. In a perfect world,
XSP should have only one logicsheet, the JXPath logicsheet. There
should be no other things in an XSP page that put logic in the page
(read View), instead of the Model. If you don't like XSP, and prefer to
use JSP or Velocity, the JXPath logicsheet equivalents should be
implemented."
Regards,
Chris
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Vadim Gritsenko <va...@verizon.net>.
Christopher Oliver wrote:
> Vadim Gritsenko wrote:
>
>>
>> Here you will have to explain to me why: Why whould you want to pass
>> *only* this "bean"?
>
>
> Because that is the "contract" between the flowscript and the
> presentation layer.
In Cocoon apps, presentation layer is usually XSL (and CSS) stylesheets.
XSP pages or velocity templates should be used as data generation layer.
In addition to these, there are ways to generate data out of XML:DB,
CVS, simple XML files, directories, and remote sources; and ways to
generate data using Transformers (not everybody likes XSPs), whole bunch
of them.
All of these data sources are configured through the sitemap, and have
access to request/response/context/parameters objects. And they do not
have access to the bean, AFAIK. With the exception of couple of places
you mentioned in other email - like jpath logicsheet (why it is named
like this? shouldn't it be flow logicsheet?)
>> And I still have question why don't you put this bean into request
>> attributes? And why have such bean in the first place, why not just
>> use request/session/application attributes?
>
>
> Because when using the flow you maintain the application state in
> JavaScript program variables.
And javascript program variables can be stored as object in session:
WebContinuation w =
session.getAttribute("org.apache.cocoon.flow.WebContinuation");
Essentially same is done for session-fw and xscript.
>> And also, how you will access session-fw data if you won't pass
>> session object? Same for xscript data and request/session/context
>> objects?
>
>
> Not sure what you mean here. Can you explain?
There is session-fw, originally part of the Cocoon Portal; if you want
to use flow with portal you better have access to this session objects
in "flow presentation layer". XScript is a logicsheet which is somewhat
similar to session-fw, but with access to data from XSP, not from
Transformers. Recenlty addition has been proposed to allow access to the
session-fw from the XSPs too (session-fw logicsheet).
>> And last one, why VelocityGenerator must be the only one ... hm ...
>> crippled by the absence of request/session/etc?
>
>
> That's not the case. All are equally crippled ;) For example, when
> using Xsp, the idea is that the only logic sheet you will ever use is
> the jpath logic sheet. This does not give you direct access to
> session, request, or context but only to the bean object. Likewise
> with XMLForm, you only have access to the bean itself.
HUH?
/me extremely puzzled
Anyway, as you said, the limitation on XSP is only recommendation, not
enforcement. Why VelocityGenerator can't follow the suit? Current state
of affairs is anything but uniformity.
Vadim
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Christopher Oliver <re...@verizon.net>.
Vadim Gritsenko wrote:
>
> Here you will have to explain to me why: Why whould you want to pass
> *only* this "bean"?
Because that is the "contract" between the flowscript and the
presentation layer.
>
> And I still have question why don't you put this bean into request
> attributes? And why have such bean in the first place, why not just use
> request/session/application attributes?
Because when using the flow you maintain the application state in
JavaScript program variables.
>
> And also, how you will access session-fw data if you won't pass session
> object? Same for xscript data and request/session/context objects?
Not sure what you mean here. Can you explain?
>
> And last one, why VelocityGenerator must be the only one ... hm ...
> crippled by the absence of request/session/etc?
That's not the case. All are equally crippled ;) For example, when using
Xsp, the idea is that the only logic sheet you will ever use is the
jpath logic sheet. This does not give you direct access to session,
request, or context but only to the bean object. Likewise with XMLForm,
you only have access to the bean itself.
>
> Hope it's not too many questions :)
>
Hope I'm answering some of them :)
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Vadim Gritsenko <va...@verizon.net>.
Christopher Oliver wrote:
> Vadim Gritsenko wrote:
>> It will be easy to add
>>
>> * <dt>flowContinuation (xxxx)</dt>
>> * <dt>flowBean (xxxx)</dt>
>>
>> And these should be valid values, right?
>
>
> Yes, it will be easy. But if that was all there was to it, I wouldn't
> have needed to create FlowVelocityGenerator in the first place. When
> using the flow layer I _only_ want to pass the bean object and
> continuation to the Velocity template, not the request, not the
> response, not the context, and not the parameters.
Here you will have to explain to me why: Why whould you want to pass
*only* this "bean"?
And I still have question why don't you put this bean into request
attributes? And why have such bean in the first place, why not just use
request/session/application attributes?
And also, how you will access session-fw data if you won't pass session
object? Same for xscript data and request/session/context objects?
And last one, why VelocityGenerator must be the only one ... hm ...
crippled by the absence of request/session/etc?
Hope it's not too many questions :)
Vadim
> Actually, what I really want is for the properties of the bean object
> to be properties of the Velocity context. I didn't see an easy way of
> doing that and maintaining backward compatibility. That is why I
> created FlowVelocityGenerator.
>
> Regards,
>
> Chris
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Christopher Oliver <re...@verizon.net>.
Vadim Gritsenko wrote:
> Christopher Oliver wrote:
>
> Right now VelocityGenerator exports (as per javadoc):
>
> * <dt>request (org.apache.cocoon.environment.Request)</dt>
> * <dd>The Cocoon current request</dd>
> *
> * <dt>template (java.lang.String)</dt>
> * <dd>The path of the template file currently being evaluated</dd>
> *
> * <dt>response (org.apache.cocoon.environment.Response)</dt>
> * <dd>The Cocoon response associated with the current request</dd>
> *
> * <dt>context (org.apache.cocoon.environment.Context)</dt>
> * <dd>The Cocoon context associated with the current request</dd>
> *
> * <dt>parameters (org.apache.avalon.framework.parameters.Parameters)</dt>
> * <dd>Any parameters passed to the generator in the pipeline</dd>
>
> It will be easy to add
>
> * <dt>flowContinuation (xxxx)</dt>
> * <dt>flowBean (xxxx)</dt>
>
> And these should be valid values, right?
>
>
Yes, it will be easy. But if that was all there was to it, I wouldn't
have needed to create FlowVelocityGenerator in the first place. When
using the flow layer I _only_ want to pass the bean object and
continuation to the Velocity template, not the request, not the
response, not the context, and not the parameters. Actually, what I
really want is for the properties of the bean object to be properties of
the Velocity context. I didn't see an easy way of doing that and
maintaining backward compatibility. That is why I created
FlowVelocityGenerator.
Regards,
Chris
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Vadim Gritsenko <va...@verizon.net>.
Christopher Oliver wrote:
> Vadim Gritsenko wrote:
>
>> 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 casts, and I think that we have to get
>> rid of this ASAP.
>>
>> Practical proposal:
>>
>> * Add "flow-continuation" to the objectModel, and getter method to
>> the ObjectModelHelper, as a replacement for "kont" environment
>> attribute.
>> * Add "flow-bean" to the objectModel, as a replacement for
>> "bean-dict" environment attribute.
>
>
> Switching to use the object model instead of environment attibutes is
> the easy part.
Ok
> But there's still the question of how to expose those objects to the
> author of the presentation layer.
AFAIK, there is already XSP logicsheet and some JPath transformer which
do access flow continuation.
Flow support can be added to ScriptGenerator and ScriptAction in a same
fashion as it was added to the VelocityGenerator. What other
presentation layers has been left out?
> For example, in the case of Velocity, the names you've chosen (if
> following Sylvain's suggestion: "... publishing the object model to
> the Velocity engine could solve the problem") would be a poor choice,
> because they aren't valid Velocity identifiers.
Right now VelocityGenerator exports (as per javadoc):
* <dt>request (org.apache.cocoon.environment.Request)</dt>
* <dd>The Cocoon current request</dd>
*
* <dt>template (java.lang.String)</dt>
* <dd>The path of the template file currently being evaluated</dd>
*
* <dt>response (org.apache.cocoon.environment.Response)</dt>
* <dd>The Cocoon response associated with the current request</dd>
*
* <dt>context (org.apache.cocoon.environment.Context)</dt>
* <dd>The Cocoon context associated with the current request</dd>
*
* <dt>parameters (org.apache.avalon.framework.parameters.Parameters)</dt>
* <dd>Any parameters passed to the generator in the pipeline</dd>
It will be easy to add
* <dt>flowContinuation (xxxx)</dt>
* <dt>flowBean (xxxx)</dt>
And these should be valid values, right?
Vadim
> Regards,
>
> Chris
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Christopher Oliver <re...@verizon.net>.
Vadim Gritsenko wrote:
> 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 casts, and I think that we have to get rid
> of this ASAP.
>
> Practical proposal:
>
> * Add "flow-continuation" to the objectModel, and getter method to the
> ObjectModelHelper, as a replacement for "kont" environment attribute.
> * Add "flow-bean" to the objectModel, as a replacement for "bean-dict"
> environment attribute.
>
>
Switching to use the object model instead of environment attibutes is
the easy part.
But there's still the question of how to expose those objects to the
author of the presentation layer. For example, in the case of Velocity,
the names you've chosen (if following Sylvain's suggestion: "...
publishing the object model to the Velocity engine could solve the
problem") would be a poor choice, because they aren't valid Velocity
identifiers.
Regards,
Chris
RE: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow Issues
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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 the
> ObjectModelHelper, as a replacement for "kont" environment attribute.
> * Add "flow-bean" to the objectModel, as a replacement for "bean-dict"
> environment attribute.
>
>
I don't have problems adding this to the object model, but we shouldn't
add helpers to the ObjectModelHelper because this would make moving
flow into a block impossible, because of the dependencies.
*If* this is added to the object model, then a FlowObjectModelHelper
class would be a better imho.
Carsten
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of
Flow Issues
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 17/3/03 2:45, "Christopher Oliver" <re...@verizon.net> wrote:
>> This raises a question... Do we want to keep the IDL sources in line with
>> what's in the implementation (as it is right now) or do we want to work on
>> an abstract model in IDL and then implement it?
>>
>> Maybe it would be a good idea to move everything as of the current
>> implementation in a "cocoon.flow.javascript" module, keep that in sync with
>> the implementation, hack around the "cocoon.flow" module, leaning towards a
>> good design, and make those two models converge.
>>
>> How does it sound? Ideas?
>
> Agree. I wrote the original IDL to reflect exactly what was in CVS. We
> should move that somewhere else and start designing the proper interfaces.
Will do that tomorrow (now that daddy's gone back home!)... Better to get
some sleep now before I forget that Cocoon is written in Java... :-)
Pier
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Christopher Oliver <re...@verizon.net>.
Pier Fumagalli wrote:
> On 17/3/03 2:06, "Vadim Gritsenko" <va...@verizon.net> wrote:
>
>
>>Practical proposal:
>>
>>* Add "flow-continuation" to the objectModel, and getter method to the
>>ObjectModelHelper, as a replacement for "kont" environment attribute.
>
>
> Read only properties of the "script" (global) ??? Or rather a function (I'd
> lean towards the first approach)...
In the flow script itself, "kont" is equivalent to the return value of
sendPageAndWait() and "bean-dict" is equivalent to the second argument
of sendPage*():
var k = sendPageAndWait("someURI", bean);
In Xsp:
<jpath:continuation> refers to the same object as "k"
<jpath:value-of select='.'> refers to the same object as "bean"
In Velocity:
$continuation refers to the same object as "k"
$this refers to the same object as "bean"
In XMLForm:
<xf:textbox ref="/"> ref="/" refers to the same object as "bean"
<xf:submit id="next" continuation="forward"/> id will be overwritten
with the same value as k.id
>
>
>>* Add "flow-bean" to the objectModel, as a replacement for "bean-dict"
>>environment attribute.
>
>
> +1 :-)
>
> This raises a question... Do we want to keep the IDL sources in line with
> what's in the implementation (as it is right now) or do we want to work on
> an abstract model in IDL and then implement it?
>
> Maybe it would be a good idea to move everything as of the current
> implementation in a "cocoon.flow.javascript" module, keep that in sync with
> the implementation, hack around the "cocoon.flow" module, leaning towards a
> good design, and make those two models converge.
>
> How does it sound? Ideas?
Agree. I wrote the original IDL to reflect exactly what was in CVS. We
should move that somewhere else and start designing the proper interfaces.
Regards,
Chris
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of
Flow Issues
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 17/3/03 2:39, "Vadim Gritsenko" <va...@verizon.net> wrote:
>
> Change will affect files:
> src\java\org\apache\cocoon\components\flow\AbstractInterpreter.java
> src\blocks\velocity\java\org\apache\cocoon\generation\FlowVelocityGenerator.ja
> va
> src\java\org\apache\cocoon\transformation\JPathTransformer.java
> src\java\org\apache\cocoon\transformation\XMLFormTransformer.java
> src\java\org\apache\cocoon\components\language\markup\xsp\java\jpath.xsl
>
> And it will no affect any .js files, so what have you meant here? I have
> not thought of changing javascript side of things, only how these
> objects are stored / passed in Cocoon.
Hit return too fast... Somehow I was remembering that this:
environment.setAttribute("bean-dict", bizData);
if (continuation != null)
environment.setAttribute("kont", continuation);
currently defined in AbstractInterpreter was actually written in "system.js"
just before calling "cocoon.forwardTo"...
The environment is returned by JSCocoon as a read-only attribute called
"environment"... Ahh... Forgetit....
Pier
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow
Issues
Posted by Vadim Gritsenko <va...@verizon.net>.
Pier Fumagalli wrote:
>On 17/3/03 2:06, "Vadim Gritsenko" <va...@verizon.net> wrote:
>
>
>
>>Practical proposal:
>>
>>* Add "flow-continuation" to the objectModel, and getter method to the
>>ObjectModelHelper, as a replacement for "kont" environment attribute.
>>
>>
>
>Read only properties of the "script" (global) ??? Or rather a function (I'd
>lean towards the first approach)...
>
>
Change will affect files:
src\java\org\apache\cocoon\components\flow\AbstractInterpreter.java
src\blocks\velocity\java\org\apache\cocoon\generation\FlowVelocityGenerator.java
src\java\org\apache\cocoon\transformation\JPathTransformer.java
src\java\org\apache\cocoon\transformation\XMLFormTransformer.java
src\java\org\apache\cocoon\components\language\markup\xsp\java\jpath.xsl
And it will no affect any .js files, so what have you meant here? I have
not thought of changing javascript side of things, only how these
objects are stored / passed in Cocoon.
>>* Add "flow-bean" to the objectModel, as a replacement for "bean-dict"
>>environment attribute.
>>
>>
>
>+1 :-)
>
>
Good.
Vadim
Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of
Flow Issues
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 17/3/03 2:06, "Vadim Gritsenko" <va...@verizon.net> wrote:
> Practical proposal:
>
> * Add "flow-continuation" to the objectModel, and getter method to the
> ObjectModelHelper, as a replacement for "kont" environment attribute.
Read only properties of the "script" (global) ??? Or rather a function (I'd
lean towards the first approach)...
> * Add "flow-bean" to the objectModel, as a replacement for "bean-dict"
> environment attribute.
+1 :-)
This raises a question... Do we want to keep the IDL sources in line with
what's in the implementation (as it is right now) or do we want to work on
an abstract model in IDL and then implement it?
Maybe it would be a good idea to move everything as of the current
implementation in a "cocoon.flow.javascript" module, keep that in sync with
the implementation, hack around the "cocoon.flow" module, leaning towards a
good design, and make those two models converge.
How does it sound? Ideas?
Pier
[PROPOSAL] Continuation in objectModel, Was: Discussion of Flow Issues
Posted by Vadim Gritsenko <va...@verizon.net>.
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 casts, and I think that we have to get rid
of this ASAP.
Practical proposal:
* Add "flow-continuation" to the objectModel, and getter method to the
ObjectModelHelper, as a replacement for "kont" environment attribute.
* Add "flow-bean" to the objectModel, as a replacement for "bean-dict"
environment attribute.
Why request attributes were not used to pass this "bean-dict" object?
Vadim
Re: Discussion of Flow Issues
Posted by Christopher Oliver <re...@verizon.net>.
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
> components to avoid uncontrolled access to data managed by the
> pipeline/sitemap engine. These include for example the response
> outpoutstream, the current context prefix (changed by <map:mount>), etc.
>
> To provide those parts of the Environment that are safe to be used by
> other components and required by them to do their job, the Environment
> provides a so-called object model (Environment.getObjectModel()), which
> is a Map of named objects, mainly Request and Response. This Map is
> passed to every sitemap component during the call to setup().
What objects besides the Request, Response, Session and Context are in
the "object model"? The flow script doesn't use the Response (and if you
use XMLForm, it doesn't use the Request either). The Session isn't
needed because when you use flow scripts you can store your application
state in JavaScript progam variables instead of as session attributes.
So what's left?
> 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 environment
> to communicate public information to other components, and from the fact
> that we can consider flow data as some additional data available in the
> sitemap when called from a flow script.
>
> 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. But as above, now what other objects are in the object
model and what are they used for?
>
> I'm not sure this "FOM" thing has been defined compared to the
> Environment's object model. My POV is that the FOM is the set of objects
> that are visible as global variables in a flow script.
>
> This must include :
> - the Environment's object model (but not the Environment itself),
> - Avalon-related objects that Java components (as opposed to JavaScript)
> obtain through the Avalon lifecycle interfaces. These are the Logger,
> the (Avalon) Context, and the ComponentManager. I don't know if there's
> a need for a Configuration.
I don't understand this. Can you explain what "Avalon-related" objects are?
> - the Redirector, currently available to actions (I consider redirecting
> as a particular case of a view).
Yes.
>>> 4) JavaScript Database API has no business being in the flow
>>>
>>> We all agree on this. But we need someplace to put useful JavaScript
>>> stuff - as part of optional "blocks" or something like that.
>>
>>
>>
>> yes.
>>
>>> In my own use of the flow, I've also noticed the following bugs:
>>>
>>> - Script reloading is partially broken. Sometimes scripts don't
>>> reload properly. This is normal when you are in a continuation - the
>>> continuation contains a compiled copy of the script and doesn't see
>>> the new reloaded one. But it happens occasionally even in top level
>>> calls.
>>> - With certain Exceptions the script file names and line numbers
>>> are not reported
>>> - Cocoon.load() doesn't work
>>
>>
>>
>> I saw some commits of yours on this, is cocoon.load() functional now?
In preparation for refactoring this stuff, I think I've now got script
reloading and Cocoon.load() working.
>>
>> The main objects in the FOM are:
>>
>> 1) Global -> indicates methods that are available without object prefix
>> 2) Cocoon -> cocoon-related methods that are avalilable with the
>> cocoon. object prefix
>>
>> First of all, is there a reason to have both?
>>
>> I find the concept of prefix-less method calls a little weird coming
>> from the java world. they come out of the blue.
>>
>> Also, there is a lot of duplication between the two since they provide
>> the same methods. this is very bad, IMO.
They're not really "prefix-less".
sendPage()
is really the same as
this.sendPage()
where "this" identifies the top-level object.
But you're right, in my opinion, about the duplication. It makes no sense.
>>
>> So, I would like to propose to remove Global or empty it and move
>> everything over to the Cocoon object.
>>
>> This means that instead of doing stuff like:
>>
>> sendPage(...)
>>
>> I propose to do
>>
>> cocoon.sendPage()
>>
>> which outlines the fact that it's not the flow that sends the page,
>> but it's cocoon that does (control is given back to the sitemap before
>> sending the page).
Agree. But for the second reason: I think sendPage() is really an
operation of the "cocoon".
RE: Discussion of Flow Issues
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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
> methods to ObjectModelHelper? I can even make interface out of
> WebContinuation instead of concrete class!
>
Ok, first I will not prevent you from doing so.
It's ok to add the objects to the object model.
But I still don't like adding helper methods to the ObjectModelHelper
as this makes separating flow into a module/block near
impossible or it will be an incompatible change. So I prefer making
an own helper class for flow.
*If* we later on come to the conclusion that it would be better (and
working) to have the helpers in the ObjectModelHelper then we can
move them without any pain.
But again, if I'm the only one being against adding it to the
ObjectModelHelper, well...do whatever you want, but be warned that
I will put this on the table when we separate the flow stuff ;)
Carsten
Re: Discussion of Flow Issues
Posted by Vadim Gritsenko <va...@verizon.net>.
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 make interface out of
WebContinuation instead of concrete class!
Pretty please? :)
Vadim
Re: Discussion of Flow Issues
Posted by Stefano Mazzocchi <st...@apache.org>.
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 getContinuation() in ObjectModelHelper are not
> separatable;
correct.
> 2) FlowVelocityGenerator, it has some clever hack on 130 lines or so
> specifically for the flow bean (see "Hack? I use JXPath to determine the
> properties of the bean object");
right, this has to go.
> 3) jpath logicsheet right now instead of being generic is hardwired to
> the flow too;
right.
> It's already not easy to separate! I can think of how to resolve issue 1
> (dedicated FlowObjectModelHelper: ugly, but works)
yuck!
> and 3 (flow
> logicsheet for flow related stuff; jxpath logicsheet for generic stuff),
> not sure about 2 though. Extra Velocity generator is not nice.
No, it's not.
I'm starting to think that 'flow' is an 'aspect' of our Environment, so
we would need some aspect orientation to take it out :(
We should really post-pone this after 2.1
> -0: Put session there, don't advertise it. Presence of the session
> object might facilitate migration from one approach to another, also
> will allow integration between different parts.
This is a good point.
What do others think?
Stefano.
Re: Discussion of Flow Issues
Posted by Vadim Gritsenko <va...@verizon.net>.
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 the flow.
>>
>> (I'm basing my reasoning on the anti-pattern assumption that if a
>> module separation requires code preprocessing there is something wrong)
>
>
>
> 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 getContinuation() in ObjectModelHelper are not
separatable;
2) FlowVelocityGenerator, it has some clever hack on 130 lines or so
specifically for the flow bean (see "Hack? I use JXPath to determine the
properties of the bean object");
3) jpath logicsheet right now instead of being generic is hardwired to
the flow too;
...
It's already not easy to separate! I can think of how to resolve issue 1
(dedicated FlowObjectModelHelper: ugly, but works) and 3 (flow
logicsheet for flow related stuff; jxpath logicsheet for generic stuff),
not sure about 2 though. Extra Velocity generator is not nice.
<snip/>
>>> - the Redirector, currently available to actions (I consider
>>> redirecting as a particular case of a view).
>>
>>
>> Hmmm, I'm not sure: why would you want a redirector when you have the
>> sendPage() method?
>
>
>
> To send a redirect directly to the client, without going through the
> sitemap. Considering the sendPage() method, a redirect() method would
> be better than a Redirector object.
+1
<snip/>
>> So, I would go for
>>
>> global -> contains global log methods, no properties
>
>
> -1 (see above)
"No" to global, agree.
>> 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 users really
>> push us for it.
>
>
> +1. Moreover, the inadequate use of sessions to store data my
> completely break what the flow is giving us through continuations.
-0: Put session there, don't advertise it. Presence of the session
object might facilitate migration from one approach to another, also
will allow integration between different parts.
Vadim
<snip/>
Re: Discussion of Flow Issues
Posted by Christopher Oliver <re...@verizon.net>.
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 different not-all-flowable parts is a
>>*real* need for sessions in the FOM.
>>
>>So +1 to add it.
>>
>>Anybody against it?
>
>
> I haven't had anything to say in this discussion so far, but somehow this deserves a
> comment...
>
> It would seem a shame to me to include sessions purely for 'inter-flow'
> communication. Given the thorough way you are all thinking about this, it seems a bit
> of a cop-out solution to just add sessions back in.
Why is it a "shame"?
>
> Surely what Ugo needs is the ability to 'modularise' a single flow, in a way that makes
> it managable? Then you've got one flow (which is all I would say a single application
> should have, because there's just one interaction with a user), which removes the
> necessity for sessions (which would be very good), but still allows Ugo to manage a
> number of different routes through that flow, in an easily managable way.
>
> I've no idea how achievable that would be, as I've never played with flow myself, but
> just adding sessions back in seems like a major opportunity missed.
>
Continuations are used when you have a sequence of related pages, in
that case the application state can be stored in local variables within
the Continuation. When you simply have "jumps" to other pages, in the
flow that is modeled by "top-level" function calls. The top-level
functions are still part of the same application and share state,
however. This is handled in the flow by storing the shared state in
javascript global variables, e.g. in Ugo's example:
var user;
function login(username) {
cocoon.createSession();
user = UserManager.getUser(username);
sendPage("User.html", user);
}
function chpasswd(newpasswd) {
user.password = newpasswd;
user.store();
sendPage("User.html", user);
}
Re: Discussion of Flow Issues
Posted by Upayavira <uv...@upaya.co.uk>.
> > 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 different not-all-flowable parts is a
> *real* need for sessions in the FOM.
>
> So +1 to add it.
>
> Anybody against it?
I haven't had anything to say in this discussion so far, but somehow this deserves a
comment...
It would seem a shame to me to include sessions purely for 'inter-flow'
communication. Given the thorough way you are all thinking about this, it seems a bit
of a cop-out solution to just add sessions back in.
Surely what Ugo needs is the ability to 'modularise' a single flow, in a way that makes
it managable? Then you've got one flow (which is all I would say a single application
should have, because there's just one interaction with a user), which removes the
necessity for sessions (which would be very good), but still allows Ugo to manage a
number of different routes through that flow, in an easily managable way.
I've no idea how achievable that would be, as I've never played with flow myself, but
just adding sessions back in seems like a major opportunity missed.
Regards, Upayavira
Re: Discussion of Flow Issues
Posted by Ugo Cei <u....@cbim.it>.
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 variables. Is this
> right ?
Yes, AFAIU.
> But to what are these global variables attached when
> cocoon.createSession() hasn't been called ?
I suppose they are relevant only for the current request, thus a new set
is created with each request.
> Session are always available through the good old
> "request.getSession()". But I'd like to avoid the session to be created
> implicitly by the flow engine since not every application needs it.
>
> Sylvain
Uhm yes, I could always create a session via the request and call
session.setAttribute()/getAttribute() on it. I could avoid global
variables and attach objects that I want to persist across requests to
that session. This means that instead of doing:
var user;
function login(username) {
user = UserManager.getUser(username);
cocoon.createSession();
}
function chpasswd(newpasswd) {
user.password = newpasswd;
user.store();
}
I'd have to write:
function login(username) {
var user = UserManager.getUser(username);
var session = request.getSession(true);
session.setAttribute("user", user);
}
function chpasswd(newpasswd) {
var user = session.getAttribute("user");
user.password = newpasswd;
user.store();
}
I don't know about you, but I prefer the former.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: Discussion of Flow Issues
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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 always add it later if users
>>> really push us for it.
>>
>>
>> +1. Moreover, the inadequate use of sessions to store data my
>> completely break what the flow is giving us through continuations.
>
>
> 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
> e-commerce site. These entry points might be:
>
> - search for an item
> - add item to cart
> - show cart
> - delete item from cart
> - proceed to checkout
>
> I don't think I can combine all of these (and many more) in as single
> flow, held toghether with continuations. But I still have the need to
> have a user session spanning those operations, and I do this with
> per-session global variables in the flow. As you might know, global
> variables in a flowscript are associated with a session when you call
> cocoon.createSession(). In the above example, the cart, or the user's
> profile, would be associated with the session.
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 variables. Is this
right ?
But to what are these global variables attached when
cocoon.createSession() hasn't been called ?
Moreover, shouldn't this createSession() method be named
setSessionScope() or something like that, since it does actually more
than simply creating the session ?
> 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 ;-).
Session are always available through the good old
"request.getSession()". But I'd like to avoid the session to be created
implicitly by the flow engine since not every application needs it.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Discussion of Flow Issues
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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, there doesn't appear to be lot of consistency
>> in the way Cocoon components communicate: sometimes they stash stuff
>> in request parameters, sometimes in the session, sometimes in the
>> object model. In any case there seems to be no explicit contract,
>
>
> I'm all in favor of discussing the introduction of such explicit
> contract and make the system coherent. Do you have something in mind?
We have to define the various scopes of each of these elements :
- context attributes : global to the application (i.e. to all users)
- session attributes : per-user values, common to all requests for a user.
- request attributes : per-request values, common to all internal
requests (i.e. "cocoon:") used to handle an external request
- object model : nearly per-request values, "nearly" meaning for the
current request (be it internal or external) and all descendant internal
requests.
That being said, I don't know if XMLForm should use request or object
model...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Discussion of Flow Issues
Posted by Stefano Mazzocchi <st...@apache.org>.
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
>>> restarting continuations, this script needs access to:
>>>
>>> cocoon.session
>>> cocoon.componentManager
>>> cocoon.environment.objectModel
>>> cocoon.forwardTo()
>>
>>
>>
>> Why do you need direct access to the objectModel?
>>
>
> 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 doesn't appear to be lot of consistency in
> the way Cocoon components communicate: sometimes they stash stuff in
> request parameters, sometimes in the session, sometimes in the object
> model. In any case there seems to be no explicit contract,
I'm all in favor of discussing the introduction of such explicit
contract and make the system coherent. Do you have something in mind?
Stefano.
Re: Discussion of Flow Issues
Posted by Christopher Oliver <re...@verizon.net>.
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 script needs access to:
>>
>> cocoon.session
>> cocoon.componentManager
>> cocoon.environment.objectModel
>> cocoon.forwardTo()
>
>
> Why do you need direct access to the objectModel?
>
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.
Regardless of the flow, there doesn't appear to be lot of consistency in
the way Cocoon components communicate: sometimes they stash stuff in
request parameters, sometimes in the session, sometimes in the object
model. In any case there seems to be no explicit contract,
Re: Discussion of Flow Issues
Posted by Stefano Mazzocchi <st...@apache.org>.
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 like it much, as AFAIU it will require too much often to
>> write some glue code for things that could be written in JS only...
>>
>> Sylvain
>>
>
> Either way is fine with me. It was just a suggestion. You might want to
> look at what I had to do to integrate with XMLForm:
>
> 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 script needs access to:
>
> cocoon.session
> cocoon.componentManager
> cocoon.environment.objectModel
> cocoon.forwardTo()
Why do you need direct access to the objectModel?
My 'script kid' alarm is ringing.
Stefano.
Re: Discussion of Flow Issues
Posted by Christopher Oliver <re...@verizon.net>.
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 will require too much often to
> write some glue code for things that could be written in JS only...
>
> Sylvain
>
Either way is fine with me. It was just a suggestion. You might want to
look at what I had to do to integrate with XMLForm:
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 script needs access to:
cocoon.session
cocoon.componentManager
cocoon.environment.objectModel
cocoon.forwardTo()
Re: Discussion of Flow Issues
Posted by Stefano Mazzocchi <st...@apache.org>.
Pier Fumagalli wrote:
> On 18/3/03 23:00, "Stefano Mazzocchi" <st...@apache.org> 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 wanted to say above? TIA
>
>
> For those object on which we want to tightly control the behavior, for
> example, you want to be able from a flow script to retrieve the "cocoon"
> instance, but not to set it (readonly attribute Cocoon cocoon in IDL).
>
> I'd settle with writing a bunch of "glue-code" for our (work) applications,
> if that allows me to clearly define the boundaries of what flow-script
> writers can have access to: I can write the glue and have much more
> flexibility writing my backend in Java knowing that anyway, my team won't be
> able to mess around with it...
Right. The goal of the FOM is to make public those methods that are
"safe" from an architectural point of view for script kiddies to mess
around with.
The more dangerously abused an internal public method is, the harder
will be for script kiddies to get it from the flow.
This should (hopefully) reduce scripting abuse.
Is anybody against this general approach?
Stefano.
Re: Discussion of Flow Issues
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 18/3/03 23:00, "Stefano Mazzocchi" <st...@apache.org> 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 wanted to say above? TIA
For those object on which we want to tightly control the behavior, for
example, you want to be able from a flow script to retrieve the "cocoon"
instance, but not to set it (readonly attribute Cocoon cocoon in IDL).
I'd settle with writing a bunch of "glue-code" for our (work) applications,
if that allows me to clearly define the boundaries of what flow-script
writers can have access to: I can write the glue and have much more
flexibility writing my backend in Java knowing that anyway, my team won't be
able to mess around with it...
Pier
Re: Discussion of Flow Issues
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Pier Fumagalli wrote:
>
>> On 18/3/03 21:29, "Christopher Oliver" <re...@verizon.net> 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 don't get a hook to the ObjectModel, how can you get a
>>>> java
>>>> session object from the flow?
>>>>
>>>>
>>>
>>> What I meant was instead of this:
>>>
>>> public class JSCocoon extends ScriptableObject {
>>>
>>> public Session jsGet_session() // expose session to JavaScript
>>> {
>>> ...
>>> }
>>> }
>>>
>>>
>>> we could do this:
>>>
>>> public class JSCocoon extends ScriptableObject {
>>>
>>> public Session getSession() { // not available in JavaScript
>>> }
>>>
>>> public static Session getSession(Scriptable scope) {
>>> Scriptable topLevel = getTopLevelScope(scope);
>>> Object obj = getProperty(topLevel, "cocoon");
>>> return ((JSCocoon)obj).getSession();
>>> }
>>> }
>>>
>>>
>>> Then if you need access to a Session you would have to implement a
>>> JavaScript object in Java, for example:
>>>
>>>
>>> class MyObject extends ScriptableObject {
>>>
>>> public String getClassName() {return "MyObject";}
>>>
>>> public void jsFunction_foo() {
>>> // I need the session:
>>> Session session = JSCocoon.getSession(this);
>>> }
>>> }
>>>
>>> Then in javascript you could do this:
>>>
>>> var obj = new MyObject();
>>> cocoon.session; // undefined
>>> obj.foo(); // but foo() uses the session
>>>
>>
>>
>> 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 will require too much often to
> write some glue code for things that could be written in JS only...
I think the above method that Chris suggests is fair for sessions
(making it a *little* hard, but not too much) but I agree with Sylvain
that this is way too much overhead for the remaining part of the FOM.
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 wanted to say above? TIA
Stefano.
Re: Discussion of Flow Issues
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Pier Fumagalli wrote:
>On 18/3/03 21:29, "Christopher Oliver" <re...@verizon.net> 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 don't get a hook to the ObjectModel, how can you get a java
>>>session object from the flow?
>>>
>>>
>>>
>>What I meant was instead of this:
>>
>> public class JSCocoon extends ScriptableObject {
>>
>> public Session jsGet_session() // expose session to JavaScript
>> {
>> ...
>> }
>> }
>>
>>
>>we could do this:
>>
>> public class JSCocoon extends ScriptableObject {
>>
>> public Session getSession() { // not available in JavaScript
>> }
>>
>> public static Session getSession(Scriptable scope) {
>> Scriptable topLevel = getTopLevelScope(scope);
>> Object obj = getProperty(topLevel, "cocoon");
>> return ((JSCocoon)obj).getSession();
>> }
>> }
>>
>>
>>Then if you need access to a Session you would have to implement a
>>JavaScript object in Java, for example:
>>
>>
>> class MyObject extends ScriptableObject {
>>
>> public String getClassName() {return "MyObject";}
>>
>> public void jsFunction_foo() {
>> // I need the session:
>>Session session = JSCocoon.getSession(this);
>> }
>> }
>>
>>Then in javascript you could do this:
>>
>>var obj = new MyObject();
>>cocoon.session; // undefined
>>obj.foo(); // but foo() uses the session
>>
>>
>
>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 will require too much often to
write some glue code for things that could be written in JS only...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Discussion of Flow Issues
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 18/3/03 21:29, "Christopher Oliver" <re...@verizon.net> 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 don't get a hook to the ObjectModel, how can you get a java
>> session object from the flow?
>>
>
> What I meant was instead of this:
>
> public class JSCocoon extends ScriptableObject {
>
> public Session jsGet_session() // expose session to JavaScript
> {
> ...
> }
> }
>
>
> we could do this:
>
> public class JSCocoon extends ScriptableObject {
>
> public Session getSession() { // not available in JavaScript
> }
>
> public static Session getSession(Scriptable scope) {
> Scriptable topLevel = getTopLevelScope(scope);
> Object obj = getProperty(topLevel, "cocoon");
> return ((JSCocoon)obj).getSession();
> }
> }
>
>
> Then if you need access to a Session you would have to implement a
> JavaScript object in Java, for example:
>
>
> class MyObject extends ScriptableObject {
>
> public String getClassName() {return "MyObject";}
>
> public void jsFunction_foo() {
> // I need the session:
> Session session = JSCocoon.getSession(this);
> }
> }
>
> Then in javascript you could do this:
>
> var obj = new MyObject();
> cocoon.session; // undefined
> obj.foo(); // but foo() uses the session
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)...
Pier
Re: Discussion of Flow Issues
Posted by Christopher Oliver <re...@verizon.net>.
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 object from the flow?
>
What I meant was instead of this:
public class JSCocoon extends ScriptableObject {
public Session jsGet_session() // expose session to JavaScript
{
...
}
}
we could do this:
public class JSCocoon extends ScriptableObject {
public Session getSession() { // not available in JavaScript
}
public static Session getSession(Scriptable scope) {
Scriptable topLevel = getTopLevelScope(scope);
Object obj = getProperty(topLevel, "cocoon");
return ((JSCocoon)obj).getSession();
}
}
Then if you need access to a Session you would have to implement a
JavaScript object in Java, for example:
class MyObject extends ScriptableObject {
public String getClassName() {return "MyObject";}
public void jsFunction_foo() {
// I need the session:
Session session = JSCocoon.getSession(this);
}
}
Then in javascript you could do this:
var obj = new MyObject();
cocoon.session; // undefined
obj.foo(); // but foo() uses the session
Re: Discussion of Flow Issues
Posted by Stefano Mazzocchi <st...@apache.org>.
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 Ugo's case.
Ok
> +1 for a different reason: I think direct access to the session will be
> needed for backward compatibility with existing Cocoon components (e.g.
> Portal) that use the session for communication.
I see.
> But this could be
> encapsulated in a higher level JavaScript API that internally manages
> the session (like what I did with XMLForm). What do you think?
Please elaborate more on this. Sounds interesting anyway. I would love
to see the session disappear or, at least, provide a better abstraction
to it.
> 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 object from the flow?
Stefano.
Re: Discussion of Flow Issues
Posted by Christopher Oliver <re...@verizon.net>.
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 different reason: I think direct access to the session will be
needed for backward compatibility with existing Cocoon components (e.g.
Portal) that use the session for communication. But this could be
encapsulated in a higher level JavaScript API that internally manages
the session (like what I did with XMLForm). What do you think? 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.
Regards,
Chris
Re: Discussion of Flow Issues
Posted by Stefano Mazzocchi <st...@apache.org>.
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 always add it later if users really
>>> push us for it.
>>
>>
>>
>> +1. Moreover, the inadequate use of sessions to store data my
>> completely break what the flow is giving us through continuations.
>
>
> 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
> e-commerce site. These entry points might be:
>
> - search for an item
> - add item to cart
> - show cart
> - delete item from cart
> - proceed to checkout
>
> I don't think I can combine all of these (and many more) in as single
> flow, held toghether with continuations. But I still have the need to
> have a user session spanning those operations, and I do this with
> per-session global variables in the flow. As you might know, global
> variables in a flowscript are associated with a session when you call
> cocoon.createSession(). In the above example, the cart, or the user's
> profile, would be associated with the session.
>
> 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 different not-all-flowable parts is a *real*
need for sessions in the FOM.
So +1 to add it.
Anybody against it?
Stefano.
Re: Discussion of Flow Issues
Posted by Christopher Oliver <re...@verizon.net>.
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 relationship to sitemaps?
Regards,
Chris
Marcus Crafter wrote:
> Hi All!
>
> One thing I'd like to discuss a little bit more is the relationship
> between individual flow interpreter instances and sub/sitemaps.
>
> Currently, there's one flow interpreter instance created per
> sitemap. So, when operating within the one sitemap everything is
> fine - however it has some implications for larger applications
> that use subsitemaps, etc.
>
> The following:
>
> <map:flow language="JavaScript">
> <map:script src="context://WEB-INF/flow.js"/>
> </map:flow>
>
> defines some javascript methods that are encapsulated within that
> sitemap. It would be good if we had a nice way to promote the reuse of
> any javascript methods that could be reused in a sub/sitemap (I
> suppose subsitemaps could just include a common script, but
> perhaps there's a more attractive way).
>
> Another area is scope. Global variables managed by
> cocoon.createSession() are currently only available in the sitemap
> they're defined in, essentially making them local to that sitemap.
>
> ie. if flow.js defines:
>
> var currentUser = null;
>
> function login()
> {
> // assuming valid user
>
> // create a session and store user object
> cocoon.createSession();
> currentUser = new User(username);
>
> // continue processing and send page
> }
>
> the currentUser reference is only available in the sitemap the
> flow.js was defined in. This means, subsitemaps have no reference
> to it in any way - something I would like to find a solution for if
> possible.
>
> I think this was one area where Ugo (and I) were using manual session
> manipulation to store cross sitemap data.
>
> Ovidiu and I once talked about the ability to inherit flow data/methods
> in subsitemaps, perhaps that's worth investigating a bit more ?
>
> Solving these implications would allow us to use flow to control
> an application at a higher level than just in one sitemap.
>
> What do you think ?
>
> Cheers,
>
> Marcus
>
Re: Discussion of Flow Issues
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
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 suggesting, is that because of this (that you can store
> "session" state in global JS variables) direct access to the underlying
> Session should not be needed by the average user of the flow.
I see your point mate. The automatic handling of global variables
in flow was one of the big attractions for me to use flow.
One thing I'd like to discuss a little bit more is the relationship
between individual flow interpreter instances and sub/sitemaps.
Currently, there's one flow interpreter instance created per
sitemap. So, when operating within the one sitemap everything is
fine - however it has some implications for larger applications
that use subsitemaps, etc.
The following:
<map:flow language="JavaScript">
<map:script src="context://WEB-INF/flow.js"/>
</map:flow>
defines some javascript methods that are encapsulated within that
sitemap. It would be good if we had a nice way to promote the reuse of
any javascript methods that could be reused in a sub/sitemap (I
suppose subsitemaps could just include a common script, but
perhaps there's a more attractive way).
Another area is scope. Global variables managed by
cocoon.createSession() are currently only available in the sitemap
they're defined in, essentially making them local to that sitemap.
ie. if flow.js defines:
var currentUser = null;
function login()
{
// assuming valid user
// create a session and store user object
cocoon.createSession();
currentUser = new User(username);
// continue processing and send page
}
the currentUser reference is only available in the sitemap the
flow.js was defined in. This means, subsitemaps have no reference
to it in any way - something I would like to find a solution for if
possible.
I think this was one area where Ugo (and I) were using manual session
manipulation to store cross sitemap data.
Ovidiu and I once talked about the ability to inherit flow data/methods
in subsitemaps, perhaps that's worth investigating a bit more ?
Solving these implications would allow us to use flow to control
an application at a higher level than just in one sitemap.
What do you think ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: Discussion of Flow Issues
Posted by Christopher Oliver <re...@verizon.net>.
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 always add it later if users really
>>> push us for it.
>>
>>
>>
>> +1. Moreover, the inadequate use of sessions to store data my
>> completely break what the flow is giving us through continuations.
>
>
> 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
> e-commerce site. These entry points might be:
>
> - search for an item
> - add item to cart
> - show cart
> - delete item from cart
> - proceed to checkout
>
> I don't think I can combine all of these (and many more) in as single
> flow, held toghether with continuations. But I still have the need to
> have a user session spanning those operations, and I do this with
> per-session global variables in the flow. As you might know, global
> variables in a flowscript are associated with a session when you call
> cocoon.createSession(). In the above example, the cart, or the user's
> profile, would be associated with the session.
>
> 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 ;-).
>
>
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 suggesting, is that because of this (that you can store
"session" state in global JS variables) direct access to the underlying
Session should not be needed by the average user of the flow.
Right now you have direct access via cocoon.session and
cocoon.request.getSession().
Regards,
Chris
Re: Discussion of Flow Issues
Posted by Ugo Cei <u....@cbim.it>.
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 users really
>> push us for it.
>
>
> +1. Moreover, the inadequate use of sessions to store data my completely
> break what the flow is giving us through continuations.
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
e-commerce site. These entry points might be:
- search for an item
- add item to cart
- show cart
- delete item from cart
- proceed to checkout
I don't think I can combine all of these (and many more) in as single
flow, held toghether with continuations. But I still have the need to
have a user session spanning those operations, and I do this with
per-session global variables in the flow. As you might know, global
variables in a flowscript are associated with a session when you call
cocoon.createSession(). In the above example, the cart, or the user's
profile, would be associated with the session.
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 ;-).
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: Discussion of Flow Issues
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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 the "natural" way for the
>> environment to communicate public information to other components,
>> and from the fact that we can consider flow data as some additional
>> data available in the sitemap when called from a flow script.
>>
>> 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 the flow.
>
> (I'm basing my reasoning on the anti-pattern assumption that if a
> module separation requires code preprocessing there is something wrong)
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.
So adding flow values to the object model shouldn't be a problem when
they are either manipulated abstractly as described above or simply ignored.
<snip/>
>> I'm not sure this "FOM" thing has been defined compared to the
>> Environment's object model.
>
>
> This was my and Pier's concern: we need to define the FOM with the
> same care we took to define the rest of the contracts with the Cocoon
> system and it was not done until we raised the thing.
>
> Having you and Vadim discussing this with Chris, Pier and me is a very
> good thing because it goes toward that community-driven design I was
> looking for.
Yep. I jumped into this discussion since I felt the need for this
community-driven polishing and also to force me to finally go into this
nice stuff ;-)
>> My POV is that the FOM is the set of objects that are visible as
>> global variables in a flow script.
>>
>> This must include :
>> - the Environment's object model (but not the Environment itself),
>
>
> yes. note also that with javascript we can do very nice syntax-sugar
> things like
>
> cocoon.request.blah
>
> would do the same as a much more verbose
>
> cocoon.getRequest().getParameter("blah")
>
> which would bring us the scriptability and ease-of-use of web
> scripting solutions (which are so popular because very easy to read
> and write) with the solidity of a well-defined OO framework.
Yep. I like that too.
>> - Avalon-related objects that Java components (as opposed to
>> JavaScript) obtain through the Avalon lifecycle interfaces. These are
>> the Logger, the (Avalon) Context, and the ComponentManager.
>
>
> The logger is available, we just need to define how.
>
> I already asked for a direct hook to the component manager.
>
> Why would you need access to the context?
Because it can contain some useful data for the flow or Java classes
called by the flow such as the work directory (makes me think that a
"work:" protocol would be nice) or the environment context (webapp
resources, deployment parameters, etc).
>> I don't know if there's a need for a Configuration.
>
> I would say no. The flow is not a component
I was wondering if there may be some "generic" flow programs that could
be parameterized through a configuration, but this finally smells FS. So
no Configuration.
>> - the Redirector, currently available to actions (I consider
>> redirecting as a particular case of a view).
>
> Hmmm, I'm not sure: why would you want a redirector when you have the
> sendPage() method?
To send a redirect directly to the client, without going through the
sitemap. Considering the sendPage() method, a redirect() method would be
better than a Redirector object.
>> The FOM also provides some methods not related to any of the above
>> objects such as sendPage().
>
> methods that I want to see removed from a global namespace and placed
> into the cocoon object for clarity and cognitive scope.
Me too :-)
<snip/>
> In my mind, this means that not many understand that the 'window'
> object is transparently mapped to the global unnamespaced object....
> but it creates a mess because you could have 'status' defined in your
> scripts as well.
>
> This is why I want a clean unnamespaced object.
>
> I would not mind log methods such as
>
> info("blah");
> error("blah");
> debug("lkj");
>
> but that should be it.
Even these. Let's attach them to a "logger" object : log.debug("blah"),
log.info("foo"), etc.
>> This is mainly a naming and classification problem : how do we
>> organize these objects available to the JS script ? Should all the
>> FOM be defined as global variables, or available as properties of
>> some "classifier" objects, e.g. "cocoon.request",
>> "cocoon.sendPage()", "avalon.logger", "avalon.manager" ? I personnaly
>> would go for the second choice.
>
>
> Totally!
>
> Note, however, that I would like to "hide" the complexities of Avalon
> as much as possible.
>
> So, I would go for
>
> global -> contains global log methods, no properties
-1 (see above)
> cocoon -> cocoon methods + component management methods
CM methods = lookup() and release() ?
> cocoon.request -> access to the request
> cocoon.response -> access to the response
> cocoon.context -> access to the context
Beware : _Avalon_ context, or _environment_ context ?
BTW, I've been thinking for a long time to rename
o.a.c.environment.Context to EnvironmentContext to avoid those naming
conflicts. Isn't the 2.1 a good opportunity to do that ?
> NOTE:
>
> 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 users really
> push us for it.
+1. Moreover, the inadequate use of sessions to store data my completely
break what the flow is giving us through continuations.
> 2) do we need access to the response? setting headers is the only
> thing that comes to mind, but that is potentially abusable, expecially
> on things like cache headers and such. maybe we should leave this out
> as well for now.
+0. Let's not include it for now and see if it's needed later.
> 3) avalon component management should be done thru the 'cocoon'
> object because it's cocoon, in fact, that provides those components to
> you. the fact that they are managed internally by avalon doesn't make
> any difference for joe-flow-user, nor should.
+1. But beware of "context" which is an ambiguous word. But if we
introduce a "work:" protocol and give acess to the environment context,
the Avalon context may be useless.
> What do you think?
Community-driven polishing at work ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Discussion of Flow Issues
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
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");
cocoon.log.error("blah");
cocoon.log.debug("lkj");
make more sense to me, even if they are longer :)
> cocoon -> cocoon methods + component management methods
+1
You would use a 'role' identifier to retrieve them?
> cocoon.request -> access to the request
+1
> cocoon.response -> access to the response
+0
> cocoon.context -> access to the context
+1
>
> NOTE:
>
> 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.
I think that is an interesting idea.
Will cause some confusion, but it is true to the concept of Flow.
> We can always add it later if users really push us for it.
>
> 2) do we need access to the response? setting headers is the only
> thing that comes to mind, but that is potentially abusable, expecially
> on things like cache headers and such. maybe we should leave this out
> as well for now.
I think we need more resolution of the various ongoing discussions
about cleaning up Cocoon's interaction with all aspects of HTTP headers
(in-bound and out-bound) before we can decide to take this out of
Flow's reach.
Ideally, we should be able to take it out.
>
> 3) avalon component management should be done thru the 'cocoon'
> object because it's cocoon, in fact, that provides those components to
> you. the fact that they are managed internally by avalon doesn't make
> any difference for joe-flow-user, nor should.
+1
What management methods do you envisage?
What gets automatically managed?
TBH. I don't understand yet when/why you would access components from
Flow.
> What do you think?
I am glad this is happening this way :)
regards Jeremy
Re: Discussion of Flow Issues
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 17/3/03 20:02, "Stefano Mazzocchi" <st...@apache.org> 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 graps is the
> concept of why everybody uses
>
> alert("blah")
>
> why they use
>
> window.status = "blah"
>
> but never
>
> window.alert("blah");
>
> and
>
> status = "blah";
>
> In my mind, this means that not many understand that the 'window' object
> is transparently mapped to the global unnamespaced object.... but it
> creates a mess because you could have 'status' defined in your scripts
> as well.
>
> This is why I want a clean unnamespaced object.
>
> I would not mind log methods such as
>
> info("blah");
> error("blah");
> debug("lkj");
>
> but that should be it.
Well.. The "global" can also be referred to as "this"... So you can also
write:
alert("alert");
window.alert("window.alert");
this.alert("this.alert");
this.window.alert("this.window.alert");
....
That said, I believe that the best way to define global operations and
attributes is to define them in a so called "script" object, whose instance
is the one you're going to call from the sitemap...
So, "cocoon.sendPage()" becomes "this.cocoon.sendPage()"... JavaScript, as
Java, allows you to strip out the "this."...
Pier
Re: Discussion of Flow Issues
Posted by Stefano Mazzocchi <st...@apache.org>.
Christopher Oliver wrote:
>
> Pier Fumagalli wrote:
>
>> On 17/3/03 20:02, "Stefano Mazzocchi" <st...@apache.org> 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...
>>
>
>
> How about calling the class of this object just "Flow"? That's what it
> seems to represent: its methods (called by the sitemap) define page
> flow, and its properties (global variables) represent the shared
> application state of the pages.
>
> Regards,
>
> Chris
+1
Re: Discussion of Flow Issues
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 18/3/03 19:06, "Christopher Oliver" <re...@verizon.net> 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
> seems to represent: its methods (called by the sitemap) define page
> flow, and its properties (global variables) represent the shared
> application state of the pages.
Well, but you never "write" a "Flow"... You write a "Script" for the flow...
That was my idea when I wrote it though...
Any way you like it guys (I'll just let it be for another few hours to
hopefully make you change your mind, but I'm positive with anything)...
Pier
Re: Discussion of Flow Issues
Posted by Christopher Oliver <re...@verizon.net>.
Pier Fumagalli wrote:
> On 17/3/03 20:02, "Stefano Mazzocchi" <st...@apache.org> 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...
>
How about calling the class of this object just "Flow"? That's what it
seems to represent: its methods (called by the sitemap) define page
flow, and its properties (global variables) represent the shared
application state of the pages.
Regards,
Chris
Re: Discussion of Flow Issues
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 17/3/03 20:02, "Stefano Mazzocchi" <st...@apache.org> 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...
In my mind nothing is "global"... And it's strengthened by the fact that in
JavaScript all the so called "globals" can be also referenced by preceding
them with "this"...
> cocoon -> cocoon methods + component management methods
This is an attribute of "Script", so that it can be referenced (in
JavaScript) from your function using "cocoon.xxxx" or "this.cocoon.xxxx".
> cocoon.request -> access to the request
Yes...
> cocoon.response -> access to the response
Removed as per agreement with Sylvain and your doubts raised further along
in your email...
> cocoon.context -> access to the context
Yes... (I actually had to mangle the name to contxt as "context" seems to be
an IDL keyword).
> What do you think?
Awesome... Now we have to decide what to expose in context and request... I
believe (or just inherit all?)...
Now, your personal IDL stenographer at work reflected the changes in the
sources... Can you guys please check the IDLDoc output to tell me where I
foobared up?
Thanks...
Pier
Re: Discussion of Flow Issues
Posted by Stefano Mazzocchi <st...@apache.org>.
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 environment
> to communicate public information to other components, and from the fact
> that we can consider flow data as some additional data available in the
> sitemap when called from a flow script.
>
> 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 the flow.
(I'm basing my reasoning on the anti-pattern assumption that if a module
separation requires code preprocessing there is something wrong)
>>> 2) Concerns with exposing the componentManager:
>>>
>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104687345726726&w=2
>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104687863701233&w=2
>>>
>>> I personally do not know what the proper solution here is. Can
>>> someone explain the proper use of component managers and make a
>>> suggestion on how to solve this?
>>
>>
>>
>> I think that a way to solve this would be to have a direct FOM hook to
>> the cocoon component manager... but this should not allow people to
>> have access to sitemap components, only to those components defined in
>> roles.
>>
>> But I'm thinking out loud here.
>
>
>
> I'm not sure this "FOM" thing has been defined compared to the
> Environment's object model.
This was my and Pier's concern: we need to define the FOM with the same
care we took to define the rest of the contracts with the Cocoon system
and it was not done until we raised the thing.
Having you and Vadim discussing this with Chris, Pier and me is a very
good thing because it goes toward that community-driven design I was
looking for.
> My POV is that the FOM is the set of objects
> that are visible as global variables in a flow script.
>
> This must include :
> - the Environment's object model (but not the Environment itself),
yes. note also that with javascript we can do very nice syntax-sugar
things like
cocoon.request.blah
would do the same as a much more verbose
cocoon.getRequest().getParameter("blah")
which would bring us the scriptability and ease-of-use of web scripting
solutions (which are so popular because very easy to read and write)
with the solidity of a well-defined OO framework.
> - Avalon-related objects that Java components (as opposed to JavaScript)
> obtain through the Avalon lifecycle interfaces. These are the Logger,
> the (Avalon) Context, and the ComponentManager.
The logger is available, we just need to define how.
I already asked for a direct hook to the component manager.
Why would you need access to the context?
>I don't know if there's a need for a Configuration.
I would say no. The flow is not a component
> - the Redirector, currently available to actions (I consider redirecting
> as a particular case of a view).
Hmmm, I'm not sure: why would you want a redirector when you have the
sendPage() method?
> The FOM also provides some methods not related to any of the above
> objects such as sendPage().
methods that I want to see removed from a global namespace and placed
into the cocoon object for clarity and cognitive scope.
>>> 3) Duplication of functionality between VelocityGenerator and
>>> FlowVelocityGenerator:
>>>
>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104673257019781&w=2
>>>
>>> This is clearly bad, I agree. I think these could be merged back
>>> together - the old behavior would apply if the flow context object
>>> isn't available. But this probably depends somewhat on the answer to
>>> (1).
>>
>>
>>
>> Ok, so you are stating that once we solve 1) we solve 3) as well?
>
>
>
> Could be ;-) If flow data goes through the object model, publishing the
> object model to the Velocity engine could solve the problem.
Great.
[snip]
> 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 graps is the
concept of why everybody uses
alert("blah")
why they use
window.status = "blah"
but never
window.alert("blah");
and
status = "blah";
In my mind, this means that not many understand that the 'window' object
is transparently mapped to the global unnamespaced object.... but it
creates a mess because you could have 'status' defined in your scripts
as well.
This is why I want a clean unnamespaced object.
I would not mind log methods such as
info("blah");
error("blah");
debug("lkj");
but that should be it.
> This is mainly a naming and classification problem : how do we organize
> these objects available to the JS script ? Should all the FOM be defined
> as global variables, or available as properties of some "classifier"
> objects, e.g. "cocoon.request", "cocoon.sendPage()", "avalon.logger",
> "avalon.manager" ? I personnaly would go for the second choice.
Totally!
Note, however, that I would like to "hide" the complexities of Avalon as
much as possible.
So, I would go for
global -> contains global log methods, no properties
cocoon -> cocoon methods + component management methods
cocoon.request -> access to the request
cocoon.response -> access to the response
cocoon.context -> access to the context
NOTE:
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 users really push us
for it.
2) do we need access to the response? setting headers is the only
thing that comes to mind, but that is potentially abusable, expecially
on things like cache headers and such. maybe we should leave this out as
well for now.
3) avalon component management should be done thru the 'cocoon' object
because it's cocoon, in fact, that provides those components to you. the
fact that they are managed internally by avalon doesn't make any
difference for joe-flow-user, nor should.
What do you think?
Re: Discussion of Flow Issues
Posted by Sylvain Wallez <sy...@anyware-tech.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 easy to fix. But I personally don't understand the
>> "objectModel". Can someone explain how to properly use it? But I
>> think there is a more fundamental design question here: namely, how
>> should the flow script communicate with generators, transformers, etc?
>
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
components to avoid uncontrolled access to data managed by the
pipeline/sitemap engine. These include for example the response
outpoutstream, the current context prefix (changed by <map:mount>), etc.
To provide those parts of the Environment that are safe to be used by
other components and required by them to do their job, the Environment
provides a so-called object model (Environment.getObjectModel()), which
is a Map of named objects, mainly Request and Response. This Map is
passed to every sitemap component during the call to setup().
> This is a very good question and I'm not sure I have an answer.
>
> Sylvain, what do you think?
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 environment
to communicate public information to other components, and from the fact
that we can consider flow data as some additional data available in the
sitemap when called from a flow script.
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 ?
>> 2) Concerns with exposing the componentManager:
>>
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104687345726726&w=2
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104687863701233&w=2
>>
>> I personally do not know what the proper solution here is. Can
>> someone explain the proper use of component managers and make a
>> suggestion on how to solve this?
>
>
> I think that a way to solve this would be to have a direct FOM hook to
> the cocoon component manager... but this should not allow people to
> have access to sitemap components, only to those components defined in
> roles.
>
> But I'm thinking out loud here.
I'm not sure this "FOM" thing has been defined compared to the
Environment's object model. My POV is that the FOM is the set of objects
that are visible as global variables in a flow script.
This must include :
- the Environment's object model (but not the Environment itself),
- Avalon-related objects that Java components (as opposed to JavaScript)
obtain through the Avalon lifecycle interfaces. These are the Logger,
the (Avalon) Context, and the ComponentManager. I don't know if there's
a need for a Configuration.
- the Redirector, currently available to actions (I consider redirecting
as a particular case of a view).
The FOM also provides some methods not related to any of the above
objects such as sendPage().
>> 3) Duplication of functionality between VelocityGenerator and
>> FlowVelocityGenerator:
>>
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104673257019781&w=2
>>
>> This is clearly bad, I agree. I think these could be merged back
>> together - the old behavior would apply if the flow context object
>> isn't available. But this probably depends somewhat on the answer to
>> (1).
>
>
> Ok, so you are stating that once we solve 1) we solve 3) as well?
Could be ;-) If flow data goes through the object model, publishing the
object model to the Velocity engine could solve the problem.
>> 4) JavaScript Database API has no business being in the flow
>>
>> We all agree on this. But we need someplace to put useful JavaScript
>> stuff - as part of optional "blocks" or something like that.
>
>
> yes.
>
>> In my own use of the flow, I've also noticed the following bugs:
>>
>> - Script reloading is partially broken. Sometimes scripts don't
>> reload properly. This is normal when you are in a continuation - the
>> continuation contains a compiled copy of the script and doesn't see
>> the new reloaded one. But it happens occasionally even in top level
>> calls.
>> - With certain Exceptions the script file names and line numbers
>> are not reported
>> - Cocoon.load() doesn't work
>
>
> I saw some commits of yours on this, is cocoon.load() functional now?
>
>> I also noticed that it isn't fun to debug Velocity templates. If the
>> generated xml has errors, the XML parser reports the line number of
>> the generated xml document, which isn't preserved anywhere. In that
>> case it would be nice if the Velocity generator saved the generated
>> xml document somewhere, or at least logged it.
>
>
> I think it makes sense.
>
> I also noted a few things looking at the FOM thru the IDL
> documentation: there is a lot of duplication between the Global and
> Cocoon objects and I would like to sort it out.
>
> - o -
>
> The main objects in the FOM are:
>
> 1) Global -> indicates methods that are available without object prefix
> 2) Cocoon -> cocoon-related methods that are avalilable with the
> cocoon. object prefix
>
> First of all, is there a reason to have both?
>
> I find the concept of prefix-less method calls a little weird coming
> from the java world. they come out of the blue.
>
> Also, there is a lot of duplication between the two since they provide
> the same methods. this is very bad, IMO.
>
> So, I would like to propose to remove Global or empty it and move
> everything over to the Cocoon object.
>
> This means that instead of doing stuff like:
>
> sendPage(...)
>
> I propose to do
>
> cocoon.sendPage()
>
> which outlines the fact that it's not the flow that sends the page,
> but it's cocoon that does (control is given back to the sitemap before
> sending the page).
>
> So, no methods come out of the blue.
>
> what do you think?
I share your "attach-a-method-to-an-object" concern, which certainly
comes from our heavy Java background.
This is mainly a naming and classification problem : how do we organize
these objects available to the JS script ? Should all the FOM be defined
as global variables, or available as properties of some "classifier"
objects, e.g. "cocoon.request", "cocoon.sendPage()", "avalon.logger",
"avalon.manager" ? I personnaly would go for the second choice.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Discussion of Flow Issues
Posted by Stefano Mazzocchi <st...@apache.org>.
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 don't understand the
> "objectModel". Can someone explain how to properly use it? But I think
> there is a more fundamental design question here: namely, how should the
> flow script communicate with generators, transformers, etc?
This is a very good question and I'm not sure I have an answer.
Sylvain, what do you think?
> 2) Concerns with exposing the componentManager:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104687345726726&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104687863701233&w=2
>
> I personally do not know what the proper solution here is. Can someone
> explain the proper use of component managers and make a suggestion on
> how to solve this?
I think that a way to solve this would be to have a direct FOM hook to
the cocoon component manager... but this should not allow people to have
access to sitemap components, only to those components defined in roles.
But I'm thinking out loud here.
> 3) Duplication of functionality between VelocityGenerator and
> FlowVelocityGenerator:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104673257019781&w=2
>
> This is clearly bad, I agree. I think these could be merged back
> together - the old behavior would apply if the flow context object isn't
> available. But this probably depends somewhat on the answer to (1).
Ok, so you are stating that once we solve 1) we solve 3) as well?
> 4) JavaScript Database API has no business being in the flow
>
> We all agree on this. But we need someplace to put useful JavaScript
> stuff - as part of optional "blocks" or something like that.
yes.
> In my own use of the flow, I've also noticed the following bugs:
>
> - Script reloading is partially broken. Sometimes scripts don't reload
> properly. This is normal when you are in a continuation - the
> continuation contains a compiled copy of the script and doesn't see the
> new reloaded one. But it happens occasionally even in top level calls.
> - With certain Exceptions the script file names and line numbers are
> not reported
> - Cocoon.load() doesn't work
I saw some commits of yours on this, is cocoon.load() functional now?
> I also noticed that it isn't fun to debug Velocity templates. If the
> generated xml has errors, the XML parser reports the line number of the
> generated xml document, which isn't preserved anywhere. In that case it
> would be nice if the Velocity generator saved the generated xml document
> somewhere, or at least logged it.
I think it makes sense.
I also noted a few things looking at the FOM thru the IDL documentation:
there is a lot of duplication between the Global and Cocoon objects and
I would like to sort it out.
- o -
The main objects in the FOM are:
1) Global -> indicates methods that are available without object prefix
2) Cocoon -> cocoon-related methods that are avalilable with the
cocoon. object prefix
First of all, is there a reason to have both?
I find the concept of prefix-less method calls a little weird coming
from the java world. they come out of the blue.
Also, there is a lot of duplication between the two since they provide
the same methods. this is very bad, IMO.
So, I would like to propose to remove Global or empty it and move
everything over to the Cocoon object.
This means that instead of doing stuff like:
sendPage(...)
I propose to do
cocoon.sendPage()
which outlines the fact that it's not the flow that sends the page, but
it's cocoon that does (control is given back to the sitemap before
sending the page).
So, no methods come out of the blue.
what do you think?
Stefano.