You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Pötz <re...@gmx.net> on 2003/07/03 12:40:23 UTC
[Flow] Status
As promised here a summary of the current status.
So if somebody wants to take an issue feel free to change
http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow.
If you know of any issues that can't be found on this list or
you think that the priority should be changed please let us know!
Issues solved recently
----------------------
- basic implementation of the FOM
--> done
- get e.g. request parameter "xyz" using
cocoon.request.xyz
--> done
- implement getComponent( id )
--> done
- implement releaseComponent( component )
--> done
- implement load( script )
--> done
Issues to be solved until beta1 (14th)
--------------------------------------
- sendPage( "internalOnlyPipeline", bizData )
--> Sylvain will take a look into it this weekend
- discussion: Do we allow actions to wrap flow function calls
--> started
- BUG when requesting flow pages with JMeter (occurs only if
FOM is used see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105714319527551&w=2
- Implementation of the continuations object
see http://wiki.cocoondev.org/Wiki.jsp?page=FOM_Continuation
--> open
- all flow examples have to use the FOM
--> open
- move FOM to main trunk and make it the default flow
implementation
--> open
- move Petstore to main trunk (and use FOM)
--> open
- move JXForms to main trunk (and use FOM)
--> open
- Linotype has to use FOM
--> open
- move the JXTemplateGenerator to main trunk (and use FOM)
--> open
- votings
--> Reinhard (I'll start them ASAP I'm only waiting for Sylvains RT
;-)
- test continuations expiration
There has been a mail that there are some problems with it.
--> open
Issues to be solved until release
---------------------------------
- legacy.js
provide access to input modules and actions using
loadLegacyFunctions()
(IMO: not absolutly necessary for the 14th but for
release)
--> open
- reorganize the docs and give the flow a more prominent
position
--> open
Issues to be solved until release (nice to have)
------------------------------------------------
- raise exception if component is unreleased
(not absolutly necessary for the 14th!)
--> open
Issues for Cocoon 2.1.1 (or so)
-------------------------------
- synch rhino-continuations with Rhino\\
(GR)''The current Rhino version is an old development one.
Porting the continuation engine to the last version it's not
an easy task, but should be pretty high priority oon the list.
See
[http://marc.theaimsgroup.com/?t=105637688900023&r=1&w=2&n=13]''\\
--> GR, CO
- automagical lookup and release of stateful components
in flows with continuations support
function myFlow() {
var c = cocoon.getComponent( "blabla" );
c.doSomething();
sendPageAndWait(...):
c.doSomethingElse();
sendPage();
}
Reinhard
RE: [Flow] Status
Posted by Reinhard Pötz <re...@gmx.net>.
We make progress - thanks to Christopher and Sylvain!
See http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow for more
details.
Cheers,
Reinhard
RE: [Flow] Status
Posted by Reinhard Pötz <re...@gmx.net>.
From: Jeremy Quinn
> BTW. I went through that Wiki page changing ' until <date/>' to '
> before <date/>' as this made more sense to me in English, I
> hope I have
> not altered your intended meaning .....
Thank you - as I'm not a native English speaker I welcome all
improvements of my writings.
Cheers,
Reinhard
Re: [Flow] Status
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Friday, July 4, 2003, at 02:54 PM, reinhard_poetz@gmx.net wrote:
>> Jeremy Quinn wrote:
>>
>>>
>>> On Thursday, July 3, 2003, at 11:40 AM, Reinhard Ptz wrote:
>>>
>>>>
>>>> As promised here a summary of the current status.
>>>> So if somebody wants to take an issue feel free to change
>>>> http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow.
>>>>
>>>>
>>>
>>> Many thanks for your summary.
>>>
>>> Does anyone object to me adding my recent RT on how parameters are
>>> passed to FlowScript functions to this list? (I would not like it to
>>> block anything, but I would like it to be considered).
>>>
>>> http://marc.theaimsgroup.com/?t=105622202800004&r=1&w=2
>>>
>>> Basically, we have named parameters in the SiteMap, but loose that
>>> naming when the parameters arrive at the function, relying instead on
>>> the *order* of the parameters in the Sitemap. Named parameters should
>>> not be order-dependant IMHO.
>>>
>>> I find this most unpleasant!
>>
>>
>> I totally agree with you !
>
> Added to the Wiki! page.
Thanks Guys!
BTW. I went through that Wiki page changing ' until <date/>' to '
before <date/>' as this made more sense to me in English, I hope I have
not altered your intended meaning .....
regards Jeremy
Re: [Flow] Status
Posted by re...@gmx.net.
> Jeremy Quinn wrote:
>
> >
> > On Thursday, July 3, 2003, at 11:40 AM, Reinhard Pötz wrote:
> >
> >>
> >> As promised here a summary of the current status.
> >> So if somebody wants to take an issue feel free to change
> >> http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow.
> >>
> >>
> >
> > Many thanks for your summary.
> >
> > Does anyone object to me adding my recent RT on how parameters are
> > passed to FlowScript functions to this list? (I would not like it to
> > block anything, but I would like it to be considered).
> >
> > http://marc.theaimsgroup.com/?t=105622202800004&r=1&w=2
> >
> > Basically, we have named parameters in the SiteMap, but loose that
> > naming when the parameters arrive at the function, relying instead on
> > the *order* of the parameters in the Sitemap. Named parameters should
> > not be order-dependant IMHO.
> >
> > I find this most unpleasant!
>
>
> I totally agree with you !
Added to the Wiki! page.
Cheers,
Reinhard
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!
Re: [Flow] Status
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Jeremy Quinn wrote:
>
> On Thursday, July 3, 2003, at 11:40 AM, Reinhard Pötz wrote:
>
>>
>> As promised here a summary of the current status.
>> So if somebody wants to take an issue feel free to change
>> http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow.
>>
>>
>
> Many thanks for your summary.
>
> Does anyone object to me adding my recent RT on how parameters are
> passed to FlowScript functions to this list? (I would not like it to
> block anything, but I would like it to be considered).
>
> http://marc.theaimsgroup.com/?t=105622202800004&r=1&w=2
>
> Basically, we have named parameters in the SiteMap, but loose that
> naming when the parameters arrive at the function, relying instead on
> the *order* of the parameters in the Sitemap. Named parameters should
> not be order-dependant IMHO.
>
> I find this most unpleasant!
I totally agree with you !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Flow] Status
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, July 3, 2003, at 11:40 AM, Reinhard Pötz wrote:
>
> As promised here a summary of the current status.
> So if somebody wants to take an issue feel free to change
> http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow.
>
>
Many thanks for your summary.
Does anyone object to me adding my recent RT on how parameters are
passed to FlowScript functions to this list? (I would not like it to
block anything, but I would like it to be considered).
http://marc.theaimsgroup.com/?t=105622202800004&r=1&w=2
Basically, we have named parameters in the SiteMap, but loose that
naming when the parameters arrive at the function, relying instead on
the *order* of the parameters in the Sitemap. Named parameters should
not be order-dependant IMHO.
I find this most unpleasant!
I reduce the problem on my own projects by only having one function
where the order of parameters is assumed .....
<map:match pattern="*/*/*">
<map:call function="main">
<map:parameter name="action" value="{1}"/>
<map:parameter name="type" value="{2}"/>
<map:parameter name="id" value="{3}"/>
<map:parameter name="uri" value="{0}"/>
</map:call>
</map:match>
function main(action) {
// these arguments must be kept in sync with the SiteMap params
var args = {
action : arguments[0],
type : arguments[1],
id : arguments[2],
uri : arguments[3],
klass : Beans[arguments[1].toUpperCase()]
};
if (user == null) {
if (!login(args)) {
sendPage("screen/util/loginFailure");
return;
}
}
invoke([args]);
}
function invoke(args) {
func = this[args[0].action];
if (func != undefined) {
func.apply(this,args);
} else {
sendPage("screen/util/actionNotExists");
}
}
// this function does not need to be kept in sync with the order of
params in the sitemap
function mySpecificAction (args) {
doSomethingWith( args.type );
}
This IMHO is only a temporary solution.
What do you think?
regards Jeremy