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/09 14:37:00 UTC
[Vote] Cocoon Advanced Control Flow
Digging into the archives I found Stefanos "RTs from linkmaps to
flowmaps"
from 2001-03-05.[1] He wrote "Take a piece of paper, avoid thinking you
are writing an application for the web, so avoid taking into
consideration
technical constraints (like the request/response paradigm, intrinsic
statelessness, low bandwidth, proxying, etc..) and draw a diagram of the
latest application you wrote. What you should outline, at this stage,
is the 'skeleton' of the flow: this should be drawn to give the other
people
in the team the overlall picture of what the application is doing."
Finally after more than 2 years of a lot of work (here again many thanks
to
Ovidiu and Christopher and all the others for their real great efforts)
Stefano's vision became reality and we are ready to vote on the
"Cocoon Advanced Control Flow" and its first implementation based on a
"continuations aware JavaScript" interpreter:
+------------------------------------------------------------------+
| Cocoon Advanced Control Flow (in general) |
+------------------------------------------------------------------+
[A] The "Cocoon Advanced Control Flow" provides a controller that is
linked into the sitemap (as child element of <map:sitemap .../>:
<map:flow language="[yourLanguage]">
<map:script src="script_1"/>
<map:script src="script_2"/>
<map:script src="script_..."/>
<map:script src="script_n"/>
</map:flow>
This reflects that the flow is not a *usual* sitemap resource but
something else.
In order to read the scripts the SourceResolver is used.
[B] Functions provided by scripts can be called within the sitemap
using:
<map:call function="[yourFunction]">
<map:parameter name="x" value="y"/>[2]
</map:call>
There are no special restrictions where you can put
it within <map:pipeline .../> (e.g. put it within action elements)
[C] If a script provides continuations to continue
they are called within the sitemap using:
<map:call continuation="[continuation-id]"/>
Again, there are no restrictions where you can
put it within the sitemap (<map:pipeline .../>)
[D] All flow interpreters[3] are Avalon components and declared
in the cocoon.xonf:
<flow-interpreters default="[yourLanguage]" logger="[yourLogger]">
...
</flow-interpreters>
[E] All interpreters have to implement the Flow Object Model [FOM][4]
as far as possible but *must not* extend it without prior vote.
They also have to support all "FOM-aware" components (e.g.
JXTemplateGenerator/Transformer)
[F] FOM contains following objects:
* cocoon
* request
* response
* session
* cookie
* log
* context
* continuation
Find details on the properties and methods here[4].
[G] The FOM does not grant access to actions and input modules
but the flow interpreter *can* provide support for it but must not
give them the appearence of "first-class-Cocoon-citizens".
+------------------------------------------------------------------+
| JavaScript Interpreter |
+------------------------------------------------------------------+
[H] Our first and currently only[5] interpreter implementation is
a Javascript implementation based on Mozilla Rhino which
has been extended to support continuations.[6]
This JavaScript interpreter completly supports FOM
and provides legacy support for actions and input modules by
loading a "leagacy.js" script. (to be implemented)
[I] This JavaScript implementation is declared in the cocoon.xconf:
<flow-interpreters default="JavaScript" logger="flow">
<component-instance name="JavaScript"
class="org.apache.cocoon.components.flow.javascript.
fom.FOM_JavaScriptInterpreter">
<load-on-startup>resource://org/apache/cocoon/components/
flow/javascript/fom/fom_system.js</load-on-startup>
<reload-scripts>true</reload-scripts>
<check-time>4000</check-time>
<!--<debugger>enabled</debugger> -->
</component-instance>
</flow-interpreters>
[J] Flows and sessions:
(i) A flow script does not create a session automatically.
Accessing the session object (is a property of the cocoon
object) leads to the creation of a session if no session
is available.
(ii) The global scope of a flow only lives as long as the session
which the flow is tied to is active.
So if the session expires or you use another client to
continue a 'waiting' function you only have access to the
local scope within the flow function.
(iii) All scripts within a <map:script>...></> part share the
same global context. If you want to share more objects
you need another scope (request, session, context).
[K] Behaviour of variables within the flow:
All variables within the flow scripts are shared by reference
over continuations.
[L] A continuations manager based on the excalibur-event packages
is responsible for the expiration of continuations. It is
declared in the cocoon.xconf:
<continuations-manager logger="flow" time-to-live="3600000">
<expirations-check type="periodic">
<offset>[timeInMs]</offset>
<period>[timeInMs]</period>
</expirations-check>
</continuations-manager>
[M] Getting and releasing of components has to be done explicitly
by the flow script programmer using:[7]
cocoon.getComponent( id );
cocoon.releaseComponent( component );
I know it's a lot ;-) but I don't want a general vote on such an
important part as the "Cocoon Advanced Control Flow" (many of us
consider it as an equal part to sitemaps).
Thank you for voting/reading so far (13 items ;-)!
Cheers,
Reinhard
o-----------------------------------------------------------------------
--o
[1] "RTs from linkmaps to flowmaps" by Stefano Mazzocchi
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98379467820862&w=2
[2] Jeremy's issue of sorting of the parameters is added to the
todo list. {http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow]
[3] I'm aware of Sylvain's and Marc's proposal on changing
the scope of available controllers. I contacted Sylvain off-list
and the said that they want to come up with a concrete
implementation
of their proposal in the future and this should *not* influence
the release of Cocoon 2.1 as the proposed changes would only have
a small impact on the *public* interfaces.
[4] FOM at Cocoon Wiki! [http://wiki.cocoondev.org/Wiki.jsp?page=FOM]
[5] Our more exactly "only interpreter which is included into Cocoon".
Another implementation (using the commercial ATCT) is described
here: [http://www.freeroller.net/page/alexkrut/20030514] by
Alex Krut
[6] [http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/
rhino1_5R4pre/?cvsroot=rhino]
[7] It is planned to raise a JavaScript exception if a component is not
released before sendPageAndWait is called but not implemented yet!
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: JD Daniels
> Thanks! I think I will go have a look at Hibernate .. that
> looks helpful.... While I wait for FOM to settle down...
stay tuned ... the vote is already running!
Cheers,
Reinhard
Re: Flow Database stuff ( The new FOM? )
Posted by JD Daniels <jd...@datatrio.com>.
Thanks! I think I will go have a look at Hibernate .. that looks helpful....
While I wait for FOM to settle down...
JD
----- Original Message -----
From: "Reinhard Pötz" <re...@gmx.net>
To: "'JD Daniels'" <jd...@datatrio.com>; <de...@cocoon.apache.org>
Sent: Thursday, July 10, 2003 12:34 AM
Subject: RE: Flow Database stuff ( The new FOM? )
>
>
> > -----Original Message-----
> > From: JD Daniels [mailto:jd@datatrio.com]
> > Sent: Thursday, July 10, 2003 11:24 AM
> > To: dev@cocoon.apache.org; reinhard@apache.org
> > Subject: Re: Flow Database stuff ( The new FOM? )
> >
> >
> > I definately plan to write up some stuff on what it took to
> > get me running. I have taken a few clients and used cocoon to
> > solve small, specific issues with alot less hassle and better
> > maintainablity than PHP/PERL has proven to be.
> >
> > I have taken an in house project (An office manger to track
> > our time and project issues) and am developing it with flow.
> > we use it everyday, and alot of time is spent
> > hack-hack-hacking. alot is still in xsp.. just because it is
> > faster to build. Once I get it all usable, I will start
> > writing wiki on where I got stuck (Being new to java)
>
> As mentioned it's a good thing if people with programming experiences
> in other fields start with Cocoon and write documention because
> you have another view on the things than we.
>
> >
> > The issue I am having right now is this one:
> >
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105612521608516&w=2
>
> This issue should be solved by Chris. Please try the latest CVS
> or Cocoon-2.1m3
>
> >
> > After I saw the recent activity on the FOM, I gave it a go,
> > but waaayy over my head for now.
> >
> > Basically.. I have sitemap match a lookup time ticket form,
> > which calls a JXForm (sitemap calls jxform function), then
> > displays the results. ( I used the petstore sample to get me
> > going.) The error happens if someone else logs in from
> > another machine. and does the same action. The first person
> > in gets cannot convert null to an object. Seems that the
> > second user's database connection bumps the first one into
> > nothingness.
>
> See above.
>
> > I tried to implement the change posted to the list, (In the
> > above thread), but I must be mixed up about what has been
> > changed in the cvs, because I got a nullpointer errors
> > loading JXForms.js in my flowscript.
>
> The change posted in this thread was only a workaround but has
> *not* solved the problem at its root!
>
> >
> > So I thought I would try to figure out what the best practice
> > for this would be :)
>
> Please be aware that within the next days some things (flow,
> jxforms/xmlforms) could change which could have impacts on
> your application.
>
> HTH
> Cheers,
> Reinhard
>
>
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
> -----Original Message-----
> From: JD Daniels [mailto:jd@datatrio.com]
> Sent: Thursday, July 10, 2003 11:24 AM
> To: dev@cocoon.apache.org; reinhard@apache.org
> Subject: Re: Flow Database stuff ( The new FOM? )
>
>
> I definately plan to write up some stuff on what it took to
> get me running. I have taken a few clients and used cocoon to
> solve small, specific issues with alot less hassle and better
> maintainablity than PHP/PERL has proven to be.
>
> I have taken an in house project (An office manger to track
> our time and project issues) and am developing it with flow.
> we use it everyday, and alot of time is spent
> hack-hack-hacking. alot is still in xsp.. just because it is
> faster to build. Once I get it all usable, I will start
> writing wiki on where I got stuck (Being new to java)
As mentioned it's a good thing if people with programming experiences
in other fields start with Cocoon and write documention because
you have another view on the things than we.
>
> The issue I am having right now is this one:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105612521608516&w=2
This issue should be solved by Chris. Please try the latest CVS
or Cocoon-2.1m3
>
> After I saw the recent activity on the FOM, I gave it a go,
> but waaayy over my head for now.
>
> Basically.. I have sitemap match a lookup time ticket form,
> which calls a JXForm (sitemap calls jxform function), then
> displays the results. ( I used the petstore sample to get me
> going.) The error happens if someone else logs in from
> another machine. and does the same action. The first person
> in gets cannot convert null to an object. Seems that the
> second user's database connection bumps the first one into
> nothingness.
See above.
> I tried to implement the change posted to the list, (In the
> above thread), but I must be mixed up about what has been
> changed in the cvs, because I got a nullpointer errors
> loading JXForms.js in my flowscript.
The change posted in this thread was only a workaround but has
*not* solved the problem at its root!
>
> So I thought I would try to figure out what the best practice
> for this would be :)
Please be aware that within the next days some things (flow,
jxforms/xmlforms) could change which could have impacts on
your application.
HTH
Cheers,
Reinhard
Re: Flow Database stuff ( The new FOM? )
Posted by JD Daniels <jd...@datatrio.com>.
I definately plan to write up some stuff on what it took to get me running.
I have taken a few clients and used cocoon to solve small, specific issues
with alot less hassle and better maintainablity than PHP/PERL has proven to
be.
I have taken an in house project (An office manger to track our time and
project issues) and am developing it with flow. we use it everyday, and alot
of time is spent hack-hack-hacking. alot is still in xsp.. just because it
is faster to build. Once I get it all usable, I will start writing wiki on
where I got stuck (Being new to java)
The issue I am having right now is this one:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105612521608516&w=2
After I saw the recent activity on the FOM, I gave it a go, but waaayy over
my head for now.
Basically.. I have sitemap match a lookup time ticket form, which calls a
JXForm (sitemap calls jxform function), then displays the results. ( I used
the petstore sample to get me going.) The error happens if someone else logs
in from another machine. and does the same action. The first person in gets
cannot convert null to an object. Seems that the second user's database
connection bumps the first one into nothingness.
I tried to implement the change posted to the list, (In the above thread),
but I must be mixed up about what has been changed in the cvs, because I got
a nullpointer errors loading JXForms.js in my flowscript.
So I thought I would try to figure out what the best practice for this would
be :)
JD
----- Original Message -----
From: "Reinhard Pötz" <re...@gmx.net>
To: <de...@cocoon.apache.org>
Sent: Thursday, July 10, 2003 12:04 AM
Subject: RE: Flow Database stuff ( The new FOM? )
> From: JD Daniels
>
> > ok, I am confused on what is happening to the Datbase.js
> > file. but instead of a request for the long explanation, I
> > will settle for a quick yes or no.
> >
> > I am a java newbie... so bear with me...
> >
> > From the petstore:
> >
> > // temporary hack to avoid requiring datasource
> > config in cocoon.xconf
> > java.lang.Class.forName("org.hsqldb.jdbcDriver");
> > var jdbc =
> > java.sql.DriverManager.getConnection("jdbc:hsqldb:.",
> > "sa", "")
> > var conn = new Database(jdbc);
> > if (this.hsql == null) {
> > // keep hsql in-memory database alive
> > this.hsql =
> > java.sql.DriverManager.getConnection("jdbc:hsqldb:.", "sa", "");
> > }
> > return conn;
> > } else {
> > // lookup datasource in cocoon.xconf
> > return Database.getConnection(id);
> > }
> >
> > Is what has been talked about here on the list mean the "Best
> > Practice" way to get a database connection in flow is the way
> > that is commented here as a "temporary hack" ie. use
> > java.lang.whatever and code as if we were writing the app in
> > pure java?
>
> IMO no. I would use Object/Relational mapping tools like OJB
> http://db.apache.org/ojb/ or Hibernate (http://hibernate.bluemars.net).
>
>
> > Is there a wiki somewhere on this type of thing?
>
> http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscr
> ipt
> and here you find a component providing a Hibernate session:
> http://cvs.werken.com/viewcvs.cgi/plexus-components/hibernate
> /src/java/org/apache/plexus/hibernate/DefaultHibernateService.java?cvsro
> ot=plexus
>
> > (I have been
> > building apps in PHP and PERL for a few years, and its gets
> > frustrating KNOWING way better tools are RIGHT HERE in front of me :)
>
> Currently we are finishing the flow itself and try to find a way how to
> continue with XMLForms/JXForms in the future. After this we will have
> to write *a lot of* documentation. I know, this doesn't help you
> right now but of course we can help you here on the cocoon mailing
> lists.
>
> ;-) hint: We would be very pleased if you could help us writing
> some of the docs that guide other users into the right direction if they
> have similar problems (espacially as you have a lot of knowledge in
> other
> languages/framworks and this is of course one of our most important
> target
> groups)
>
> > Sorry if this is a pain in the *** question, bu tthe idea of
> > flow has me giddy. But I am stuck on the "cannot convert null
> > to an object issue"
>
> Where do you get this error? Usually this happens if you change your
> scripts and the context is reset and all variables are reset.
>
> Cheers,
> Reinhard
>
>
>
RE: JXForms/XMLForms
Posted by Reinhard Pötz <re...@gmx.net>.
> -----Original Message-----
> From: Christopher Oliver [mailto:res1cf5x@verizon.net]
> Sent: Saturday, July 12, 2003 4:27 AM
> To: dev@cocoon.apache.org
> Subject: Re: JXForms/XMLForms
>
>
> Reinhard Pötz wrote:
>
> >From: Christopher Oliver
> >
> >
> >
> >>I think it would be easiest to move it to its own block. Then
> >>we could
> >>deprecate XMLForm and those who are using it won't get
> >>broken. I'm not
> >>sure how you would merge it with the XMLForm block, anyway.
> If making
> >>JXForms its own block is ok, then I can do that. Otherwise, I don't
> >>think I'll be able to spend time merging it with XMLForm.
> >>
> >>
> >
> >>From a **Forms user's point of view there are following points
> >interesting:
> >
> > - the syntax how to describe the form
> > --> different
> > - validation rules (schematron)
> > --> should be the same
> > - the controller
> > --> the BIG difference
> >
> >All other things shouldn't be of much interest for them. So I'm fine
> >with making the XMLForms block a "deprecated" block and create a new
> >one without the XMLFormsTransformer but the
> >JXFormsGenerator/Transformer instead. The remaining
> >question is the different syntax which will cause problems
> if you want
> >to migrate.
> >
> >Which implementation uses the "standard" described by the W3C?
> >
> >
> JXForms
>
> >The second difference is the controller. I should be possible to use
> >the Actions framework to control the forms, shouldn't it?
> >
> No! You don't need actions. (But that's only my opinion, and I know
> others disagree with me)
I don't need them too, believe me. The question is: Should we provide
backwards compatibility in the new block (without ever releasing the
deprecated block)?
So after our discussion I think it is the best way to simply move
JXForms into it's own block. If the need for an action controller arises
and somebody starts a discussion on this topic again we can decide in
the future whether we want to integrate it into JXForms or not.
I also say this because I expect ONE "Cocoon Forms" block where we
provide ONE solution (integrating the best from
JXForms/XMLForms/Woody/JSF/M$Forms/...) in the future.
Cheers,
Reinhard
Re: JXForms/XMLForms
Posted by Christopher Oliver <re...@verizon.net>.
Reinhard Pötz wrote:
>From: Christopher Oliver
>
>
>
>>I think it would be easiest to move it to its own block. Then
>>we could
>>deprecate XMLForm and those who are using it won't get
>>broken. I'm not
>>sure how you would merge it with the XMLForm block, anyway. If making
>>JXForms its own block is ok, then I can do that. Otherwise, I don't
>>think I'll be able to spend time merging it with XMLForm.
>>
>>
>
>>>From a **Forms user's point of view there are following points
>interesting:
>
> - the syntax how to describe the form
> --> different
> - validation rules (schematron)
> --> should be the same
> - the controller
> --> the BIG difference
>
>All other things shouldn't be of much interest for them. So I'm fine
>with making
>the XMLForms block a "deprecated" block and create a new one without the
>XMLFormsTransformer but the JXFormsGenerator/Transformer instead. The
>remaining
>question is the different syntax which will cause problems if you want
>to migrate.
>
>Which implementation uses the "standard" described by the W3C?
>
>
JXForms
>The second difference is the controller. I should be possible to use the
>Actions framework to control the forms, shouldn't it?
>
No! You don't need actions. (But that's only my opinion, and I know
others disagree with me)
>I only had a brief
>look into the sources ...
>
>What do you think?
>
>Reinhard
>
>
>
>
JXForms/XMLForms
Posted by Reinhard Pötz <re...@gmx.net>.
From: Christopher Oliver
> I think it would be easiest to move it to its own block. Then
> we could
> deprecate XMLForm and those who are using it won't get
> broken. I'm not
> sure how you would merge it with the XMLForm block, anyway. If making
> JXForms its own block is ok, then I can do that. Otherwise, I don't
> think I'll be able to spend time merging it with XMLForm.
>From a **Forms user's point of view there are following points
interesting:
- the syntax how to describe the form
--> different
- validation rules (schematron)
--> should be the same
- the controller
--> the BIG difference
All other things shouldn't be of much interest for them. So I'm fine
with making
the XMLForms block a "deprecated" block and create a new one without the
XMLFormsTransformer but the JXFormsGenerator/Transformer instead. The
remaining
question is the different syntax which will cause problems if you want
to migrate.
Which implementation uses the "standard" described by the W3C?
The second difference is the controller. I should be possible to use the
Actions framework to control the forms, shouldn't it? I only had a brief
look into the sources ...
What do you think?
Reinhard
Re: Flow Database stuff ( The new FOM? )
Posted by Christopher Oliver <re...@verizon.net>.
Reinhard Pötz wrote:
>Hi Chris,
>
>I'll give it a try this weekend.
>
>To understand the changes: In a function with continuations I
>call a component once and if sendPageAndWait() is called the
>component is released automatically. If the continuation
>created is called later the variable with a pointer to a
>component will be reassigned with a newly created component of
>the same type?
>
>
Yep.
>I know this sounds very disbelieving but I wrote my mail only
>a few hours ago and you come up with a solution ... ;-)
>
>
>
I had already prototyped it. I didn't write it after you sent your message.
>Another question: The JXTemplate* stuff and the petstore are
>moved to the main trunk or a block. Do you plan to move the
>JXForms into the XMLForms package? (I want to avoid duplicate
>work because could have time this weekend doing it but can't
>promise it now.) So if you have time don't hesitate ;-)
>
>
I think it would be easiest to move it to its own block. Then we could
deprecate XMLForm and those who are using it won't get broken. I'm not
sure how you would merge it with the XMLForm block, anyway. If making
JXForms its own block is ok, then I can do that. Otherwise, I don't
think I'll be able to spend time merging it with XMLForm.
>Cheers,
>Reinhard
>
>
>
>>-----Original Message-----
>>From: Christopher Oliver [mailto:res1cf5x@verizon.net]
>>Sent: Friday, July 11, 2003 6:56 PM
>>To: dev@cocoon.apache.org
>>Subject: Re: Flow Database stuff ( The new FOM? )
>>
>>
>>Will the attached work?
>>
>>Reinhard Pötz wrote:
>>
>>
>>
>>><dream-mode>
>>>I would like to use this Avalon component mentioned above and the
>>>Flow interpreter takes care of releasing (and providing) stateful
>>>components within my scripts. So I would have to lookup the
>>>
>>>
>>Hibernate
>>
>>
>>>Session at the beginning(2) and until I finally release(8)
>>>
>>>
>>it I don't
>>
>>
>>>have to take care for it.
>>>
>>>1 function xxx() {
>>>2 var hibS = cocoon.getComponent( "hibernateSession" );
>>>3 var custBean = hibS.blablabla // get your beans with hibernate
>>>4 sendPageAndWait( "bla", {customer : custBean} );
>>>5 // do something (updates, reads, whatever)
>>>6 var someDifferentBean = hibS.blalbalba
>>>7 sendPageAndWait( "bla", {diff : someDifferentBean } );
>>>8 sendPageAndRelease( "thankYou", {} );
>>>9 }
>>>
>>>This would be IMO a very elegant way and IIU the recent discussion
>>>correctly possible from a technical point of view. Maybe Chris can
>>>comment on this :-)
>>>
>>>Thoughts?
>>>
>>></dream-mode>
>>>
>>>
>>>Cheers,
>>>Reinhard
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
Hi Chris,
I'll give it a try this weekend.
To understand the changes: In a function with continuations I
call a component once and if sendPageAndWait() is called the
component is released automatically. If the continuation
created is called later the variable with a pointer to a
component will be reassigned with a newly created component of
the same type?
I know this sounds very disbelieving but I wrote my mail only
a few hours ago and you come up with a solution ... ;-)
Another question: The JXTemplate* stuff and the petstore are
moved to the main trunk or a block. Do you plan to move the
JXForms into the XMLForms package? (I want to avoid duplicate
work because could have time this weekend doing it but can't
promise it now.) So if you have time don't hesitate ;-)
Cheers,
Reinhard
> -----Original Message-----
> From: Christopher Oliver [mailto:res1cf5x@verizon.net]
> Sent: Friday, July 11, 2003 6:56 PM
> To: dev@cocoon.apache.org
> Subject: Re: Flow Database stuff ( The new FOM? )
>
>
> Will the attached work?
>
> Reinhard Pötz wrote:
>
> >
> >
> ><dream-mode>
> > I would like to use this Avalon component mentioned above and the
> >Flow interpreter takes care of releasing (and providing) stateful
> >components within my scripts. So I would have to lookup the
> Hibernate
> >Session at the beginning(2) and until I finally release(8)
> it I don't
> >have to take care for it.
> >
> > 1 function xxx() {
> > 2 var hibS = cocoon.getComponent( "hibernateSession" );
> > 3 var custBean = hibS.blablabla // get your beans with hibernate
> > 4 sendPageAndWait( "bla", {customer : custBean} );
> > 5 // do something (updates, reads, whatever)
> > 6 var someDifferentBean = hibS.blalbalba
> > 7 sendPageAndWait( "bla", {diff : someDifferentBean } );
> > 8 sendPageAndRelease( "thankYou", {} );
> > 9 }
> >
> > This would be IMO a very elegant way and IIU the recent discussion
> > correctly possible from a technical point of view. Maybe Chris can
> > comment on this :-)
> >
> > Thoughts?
> >
> ></dream-mode>
> >
> >
> >Cheers,
> >Reinhard
> >
> >
> >
> >
>
>
Re: Flow Database stuff ( The new FOM? )
Posted by Christopher Oliver <re...@verizon.net>.
Will the attached work?
Reinhard Pötz wrote:
>
>
><dream-mode>
> I would like to use this Avalon component mentioned above and
> the Flow interpreter takes care of releasing (and providing)
> stateful components within my scripts. So I would have to
> lookup the Hibernate Session at the beginning(2) and until I
> finally release(8) it I don't have to take care for it.
>
> 1 function xxx() {
> 2 var hibS = cocoon.getComponent( "hibernateSession" );
> 3 var custBean = hibS.blablabla // get your beans with hibernate
> 4 sendPageAndWait( "bla", {customer : custBean} );
> 5 // do something (updates, reads, whatever)
> 6 var someDifferentBean = hibS.blalbalba
> 7 sendPageAndWait( "bla", {diff : someDifferentBean } );
> 8 sendPageAndRelease( "thankYou", {} );
> 9 }
>
> This would be IMO a very elegant way and IIU the recent discussion
> correctly possible from a technical point of view. Maybe Chris
> can comment on this :-)
>
> Thoughts?
>
></dream-mode>
>
>
>Cheers,
>Reinhard
>
>
>
>
Re: Flow Database stuff ( The new FOM? )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Sunday, July 13, 2003, at 10:40 AM, Reinhard Pötz wrote:
> To understand this correctly: Does e.g. Hibernate give you this
> typed "object repository"? You only have to deal with beans and
> all the persistence stuff is done for you "by magic".
>
It is not magic, but it does feel a bit like it sometimes ;)
Anyway, because I think you would really like to see how Hibernate can
be used, here is some (non-brilliant) code for adding a child bean
(Coverage represents a hierarchy of geographical locations).
'Edit' uses a (non-continuation) screen that shows lots of
relationships around the individual Bean providing links to function
calls to change complex properties and a form to edit simple properties
(submitted to self), 'Add' uses a subset of the 'Edit' screen which
just has the editable fields for simple properties and is a
continuation.
HTH
regards Jeremy
/*
* edit a bean defined by the ID (args.id) and TYPE (args.type)
* externally called function "edit/[type]/[id]"
* if args.id is empty, get the user to choose a bean to work on
* currently throws exceptions to the top
*/
function edit(args){
var bean = null;
if ("".equals(args.id)) {
// chooseBean is a continuation to navigate and choose a Bean
bean = chooseBean(args, "Please choose a " + args.type + " to start
work on.");
if (bean == null) {
redirect("../../start");
return;
} else {
args.id = bean.id;
bean.userMessage = "Ready to Edit " + bean.name + ".";
}
} else {
bean = getBean(args);
bean.userMessage = "Ready to Edit " + bean.name + ".";
if (cocoon.request.getParameter(Constants.SAVEACTION)) {
saveThisBean(bean, args);
}
}
editThisBean(bean, args);
}
/*
* present an editing screen
* currently throws exceptions to the top
* part of the screen is a form to save changes to the local
properties, submitted to self
*/
function editThisBean(bean, args) {
fetchSession().refresh(bean); // function used in situations where the
HSession may be closed
var editable = {
bean : bean,
formaction: "edit/" + args.type + "/" + args.id,
constants : Constants
};
sendPage("screen/" + args.type + "/edit", editable);
}
/*
* gives you a form to add a new coverage
* currently throws exceptions to the top
*/
function addCoverage(args) {
var bean = getBean(args);
var editable = {
bean : { name : "", description : "", userMessage : "Ready to Add a
child to " + bean.name},
errors : { name : "", description : "", count: 0 },
formaction : "edit/" + args.type + "/" + args.id, // my
continuation is in a ReqParam
constants : Constants
};
while (true) {
sendPageAndWait("screen/coverage/details", editable);
editable.bean.name = cocoon.request.getParameter(Constants.NAMEFIELD);
editable.bean.description =
cocoon.request.getParameter(Constants.DESCFIELD);
if (cocoon.request.getParameter(Constants.CANCELACTION)) {
bean.setUserMessage("Addition cancelled by User");
break;
}
// this validation should be elsewhere ideally
if ("".equals(editable.bean.name)) {
editable.errors.name = "Please fill in the name properly";
editable.errors.count++;
}
if ("".equals(editable.bean.description)) {
editable.errors.description = "Please fill in the description
properly";
editable.errors.count++;
}
if (editable.errors.count > 0) {
editable.bean.userMessage = "There were problems [" +
editable.errors.count + "], please try again";
editable.errors.count = 0;
} else { // no errors
// chooseType is a continuation to navigate and choose a Type Bean
var type = chooseType(args, "Choose a Type for: " +
editable.bean.name);
if (type == null) {
bean.setUserMessage("Addition cancelled by User");
break;
} else {
fetchSession().refresh(bean); // the Session had been closed
var child = new Packages.org.iniva.archive.Coverage();
// this property setting should be moved elsewhere too .....
child.setName(editable.bean.name);
child.setDescription(editable.bean.description);
child.setType(type);
child.setParent(bean);
bean.addChild(child);
saveBean(child);
bean.userMessage = child.name + " successfully saved.";
break;
}
}
} // end while
editThisBean(bean, args);
}
/*
* Return a Bean persisted by Hibernate, using the ID and class
* Throws Hibernate Exceptions
*/
function getBean (args) {
var sess = fetchSession(); // calls a static method in the Persistence
Filter
var bean = new Packages[args.klass]();
var transaction = null;
try {
transaction = sess.beginTransaction();
sess.load(bean, new java.lang.Long(args.id));
transaction.commit();
return bean;
} catch (e) {
rollBack(transaction);
throw e;
}
}
/*
* Persist a Bean using Hibernate
* Throws Hibernate Exceptions
*/
function saveBean(bean) {
var sess = fetchSession();
var transaction = null;
try {
transaction = sess.beginTransaction();
sess.saveOrUpdate(bean);
transaction.commit();
} catch (e) {
rollBack(transaction);
throw e;
}
}
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: Berin Loritsch
> Ugo Cei wrote:
>
> > Reinhard Pötz wrote:
> >
> >> As I'm curious I have a technical question:
> >> What's the difference if I read the necessary data in the flow or
> >> some milliseconds latter in the view layer? What do I gain?
> >
> >
> > You gain a cleaner separation of concerns. I simply don't like
> > accessing
> > my persistence layer from the view. The view is passed a model that
> > consisits of Javascript objects, Java beans or DOMs and it
> should not
> > care where it comes from.
> >
> > Just IMHO,
>
>
> There is no "right" answer on this. Some folks don't mind
> the overhead of populating and passing objects around while
> others prefer a more direct approach. The latter is most
> common in the prototyping stage where you are telling
> management about new things you can do.
>
> That said, I prefer both the view and the flow to merely use
> objects and not control persistence directly. This allows me
> the freedom to define a typed "object repository" that
> encapsulates persistence and caching concerns. But I have
> worked on projects where it was easier for a quick and dirty approach.
To understand this correctly: Does e.g. Hibernate give you this
typed "object repository"? You only have to deal with beans and
all the persistence stuff is done for you "by magic".
Cheers,
Reinhard
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: Ugo Cei [mailto:u.cei@cbim.it]
> Reinhard Pötz wrote:
> > To understand this correctly: Does e.g. Hibernate give you
> this typed
> > "object repository"? You only have to deal with beans and all the
> > persistence stuff is done for you "by magic".
>
> No. You still have to open a Session to your database and use its
> methods to load and store objects. What Hibernate (and other
> ORM tools
> like JDO, if I'm not mistaken) gives you is that now you are working
> with POJOs (Plain Old Java Objects) instead of with
> ResultSets or with
> EJBs. You also map relations to object references and
> Collections (Maps,
> Sets, Lists) and so you manage your objects in an "idiomatic"
> way that
> is more friendly to us Java programmers.
Ok. Then I have to rephrase my questions more open: What is
an "object repository" in this sense?
Cheers,
Reinhard
Re: Flow Database stuff ( The new FOM? )
Posted by Ugo Cei <u....@cbim.it>.
Reinhard Pötz wrote:
> To understand this correctly: Does e.g. Hibernate give you this
> typed "object repository"? You only have to deal with beans and
> all the persistence stuff is done for you "by magic".
No. You still have to open a Session to your database and use its
methods to load and store objects. What Hibernate (and other ORM tools
like JDO, if I'm not mistaken) gives you is that now you are working
with POJOs (Plain Old Java Objects) instead of with ResultSets or with
EJBs. You also map relations to object references and Collections (Maps,
Sets, Lists) and so you manage your objects in an "idiomatic" way that
is more friendly to us Java programmers.
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: Berin Loritsch
> Ugo Cei wrote:
>
> > Reinhard Pötz wrote:
> >
> >> As I'm curious I have a technical question:
> >> What's the difference if I read the necessary data in the flow or
> >> some milliseconds latter in the view layer? What do I gain?
> >
> >
> > You gain a cleaner separation of concerns. I simply don't like
> > accessing
> > my persistence layer from the view. The view is passed a model that
> > consisits of Javascript objects, Java beans or DOMs and it
> should not
> > care where it comes from.
> >
> > Just IMHO,
>
>
> There is no "right" answer on this. Some folks don't mind
> the overhead of populating and passing objects around while
> others prefer a more direct approach. The latter is most
> common in the prototyping stage where you are telling
> management about new things you can do.
>
> That said, I prefer both the view and the flow to merely use
> objects and not control persistence directly. This allows me
> the freedom to define a typed "object repository" that
> encapsulates persistence and caching concerns. But I have
> worked on projects where it was easier for a quick and dirty approach.
To understand this correctly: Does e.g. Hibernate give you this
typed "object repository"? You only have to deal with beans and
all the persistence stuff is done for you "by magic".
Cheers,
Reinhard
Re: Flow Database stuff ( The new FOM? )
Posted by Berin Loritsch <bl...@apache.org>.
Ugo Cei wrote:
> Reinhard Pötz wrote:
>
>> As I'm curious I have a technical question:
>> What's the difference if I read the necessary data in the flow or some
>> milliseconds latter in the view layer? What do I gain?
>
>
> You gain a cleaner separation of concerns. I simply don't like accessing
> my persistence layer from the view. The view is passed a model that
> consisits of Javascript objects, Java beans or DOMs and it should not
> care where it comes from.
>
> Just IMHO,
There is no "right" answer on this. Some folks don't mind the overhead of
populating and passing objects around while others prefer a more direct
approach. The latter is most common in the prototyping stage where you are
telling management about new things you can do.
That said, I prefer both the view and the flow to merely use objects and
not control persistence directly. This allows me the freedom to define a
typed "object repository" that encapsulates persistence and caching concerns.
But I have worked on projects where it was easier for a quick and dirty
approach.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Flow Database stuff ( The new FOM? )
Posted by Ugo Cei <u....@cbim.it>.
Reinhard Pötz wrote:
> As I'm curious I have a technical question:
> What's the difference if I read the necessary data in the flow or some
> milliseconds latter in the view layer? What do I gain?
You gain a cleaner separation of concerns. I simply don't like accessing
my persistence layer from the view. The view is passed a model that
consisits of Javascript objects, Java beans or DOMs and it should not
care where it comes from.
Just IMHO,
Ugo
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: Jeremy Quinn
> On Sunday, July 13, 2003, at 10:30 AM, Reinhard Pötz wrote:
>
> >
> > From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
> >
> >> By passing a Bean persisted by Hibernate from the flow
> layer to the
> >> view layer, you are implementing SoC by allowing the view layer to
> >> decide what is relevant for that view. This aspect not being the
> >> Flow's concern.
> >
> > Only to make it transparent (for me): The flow layer passes e.g. a
> > user bean with the id 4711 to the view layer. The view layer only
> > "knows" that it can expect a user bean and has tho show
> e.g. the name
> > and the adress and so it doesn't care where the bean comes from
> > (database, webservice, ...). Do we agree on this?
>
> I reckon we do
Fine :-)
<snip/>
> > Why do you think it is self-defeating? IIUC the point of lazy
> > initialization is calling the persistence layer at the time
> when it is
> > really needed (when I generate some output). If I pass the bean with
> > sendPageAndWait("myPage", {bean:bean}) I *already know* that I need
> > this
> > bean
> > - otherwise I wouldn't pass it, wouldn't I?
>
> OK, yes in this simple case you are right.
>
> I am too tied up in my head with my current project where I have lots
> of "one-to-many" and "many-to-many" relationships between composite
> beans, whereby loading one Bean would conceptually load >10k rows out
> of my DB.
>
> Under these circumstances I take advantage of lazy-initialisation and
> let the view layer decide that it wants to show (eg.) siblings
> (bean.parent.children) for navigation purposes, or just a few local
> properties (bean.name, bean.description etc.) for editing.
Thank you. This was the argument I was looking for. Now
lazy-initialization
makes sense to me.
>
> Additionally, in the case of editing, I tend to copy the editable
> properties to a temporary JS Properties list to pass to the
> view layer
> as I do not wish to be bothered with rolling back any changes if the
> user cancels halfway through, though this might not be one of my best
> design decisions ;)
Reinhard
Re: Flow Database stuff ( The new FOM? )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Sunday, July 13, 2003, at 10:30 AM, Reinhard Pötz wrote:
>
> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
>
>> By passing a Bean persisted by Hibernate from the flow layer to the
>> view layer, you are implementing SoC by allowing the view layer to
>> decide what is relevant for that view. This aspect not being
>> the Flow's
>> concern.
>
> Only to make it transparent (for me): The flow layer passes e.g. a
> user bean with the id 4711 to the view layer. The view layer only
> "knows" that it can expect a user bean and has tho show e.g. the name
> and the adress and so it doesn't care where the bean comes from
> (database,
> webservice, ...). Do we agree on this?
I reckon we do
>>
>> However, once you have triggered the view layer with
>> SendPageAndWait(),
>> control does not return to the flow layer until the Response has been
>> sent and the next Request received, thus loosing you the
>> opportunity to
>> close the Hibernate Session from the Flow layer before the
>> Response is
>> sent.
>
> Chris' experimental implementation of cocoon.getComponent() should
> solve
> this problem.
Interesting .....
I am not entirely sure how right now, but will look into this.
>> SendPage() might not suffer this problem, but due to the nature of a
>> SAX event pipeline, I would not bet on it.
>>
>> With 'lazy initialisation' SQL Queries are only made when getter
>> methods of the Bean are executed. If you have passed the Bean to the
>> view layer, XPath expressions in JXPathTemplate (etc.) will result in
>> those getter methods being accessed. If your flowscript has already
>> released it's Hibernate Component, you are in trouble.
>>
>> You could clone the Bean to pass it to the view layer, but it is kind
>> of self-defeating IMHO.
>
> Why do you think it is self-defeating? IIUC the point of lazy
> initialization
> is calling the persistence layer at the time when it is really needed
> (when I generate some output). If I pass the bean with
> sendPageAndWait("myPage", {bean:bean}) I *already know* that I need
> this
> bean
> - otherwise I wouldn't pass it, wouldn't I?
OK, yes in this simple case you are right.
I am too tied up in my head with my current project where I have lots
of "one-to-many" and "many-to-many" relationships between composite
beans, whereby loading one Bean would conceptually load >10k rows out
of my DB.
Under these circumstances I take advantage of lazy-initialisation and
let the view layer decide that it wants to show (eg.) siblings
(bean.parent.children) for navigation purposes, or just a few local
properties (bean.name, bean.description etc.) for editing.
Additionally, in the case of editing, I tend to copy the editable
properties to a temporary JS Properties list to pass to the view layer
as I do not wish to be bothered with rolling back any changes if the
user cancels halfway through, though this might not be one of my best
design decisions ;)
regards Jeremy
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
> By passing a Bean persisted by Hibernate from the flow layer to the
> view layer, you are implementing SoC by allowing the view layer to
> decide what is relevant for that view. This aspect not being
> the Flow's
> concern.
Only to make it transparent (for me): The flow layer passes e.g. a
user bean with the id 4711 to the view layer. The view layer only
"knows" that it can expect a user bean and has tho show e.g. the name
and the adress and so it doesn't care where the bean comes from
(database,
webservice, ...). Do we agree on this?
>
> However, once you have triggered the view layer with
> SendPageAndWait(),
> control does not return to the flow layer until the Response has been
> sent and the next Request received, thus loosing you the
> opportunity to
> close the Hibernate Session from the Flow layer before the
> Response is
> sent.
Chris' experimental implementation of cocoon.getComponent() should solve
this problem.
> SendPage() might not suffer this problem, but due to the nature of a
> SAX event pipeline, I would not bet on it.
>
> With 'lazy initialisation' SQL Queries are only made when getter
> methods of the Bean are executed. If you have passed the Bean to the
> view layer, XPath expressions in JXPathTemplate (etc.) will result in
> those getter methods being accessed. If your flowscript has already
> released it's Hibernate Component, you are in trouble.
>
> You could clone the Bean to pass it to the view layer, but it is kind
> of self-defeating IMHO.
Why do you think it is self-defeating? IIUC the point of lazy
initialization
is calling the persistence layer at the time when it is really needed
(when I generate some output). If I pass the bean with
sendPageAndWait("myPage", {bean:bean}) I *already know* that I need this
bean
- otherwise I wouldn't pass it, wouldn't I?
Cheers,
Reinhard
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
>
> On Tuesday, July 15, 2003, at 08:28 AM, Christopher Oliver wrote:
>
> > Reinhard Pötz wrote:
> >
> >> From: Christopher Oliver [mailto:res1cf5x@verizon.net]
> > <snip>
> >
> >>
> >>> catch (break) {
> >>> // a continuation is being captured,
> // code to
> >>> handle that goes here
> >>> releaseSession();
> >>> }
> >>>
> >>
> >> ... and this is called after the pipeline has been
> processed? How is
> >> this possible from a technical POV? If the view layer is called by
> >> sendPageAndWait the flow interpreter isn't active until
> the response
> >> returns from the client (map:call continuation="...").
> >>
> >> Reinhard
> >>
> > Unfortunately, you're right. In this case the call to
> releaseSession()
> > is made when the continuation is created - which is before the view
> > layer is called (see fom_system.js).
> >
> > I've just commited an update to Rhino that [re-]enables a further
> > syntax extension, namely:
> >
> > catch (return) {
> > // This continuation is about to be replaced with another
> > continuation
> > // code to handle that goes here
> > }
> >
> > By placing the code to release the hibernate session inside, i.e.
> >
> > catch (return) {
> > cocoon.releaseComponent(hibSession);
> > }
> >
> > you get the effect you're looking for: namely that the session is
> > released after calling the view layer but before control leaves the
> > interpreter.
> >
> > As I said, Ovidiu and I decided to put these features in to try to
> > provide the functionality provided by dynamic-wind in
> Scheme, but this
> > kind of explicit resource management seems awkard and error-prone.
>
> Thanks Chris
>
> I think I will stick with the TomCat Filter technique at the
IIRC filters are part of the servlet spec, aren't they?
> moment, I
> am struggling to see the advantage of using
> cocoon.***Component() stuff
> in this situation to be honest.
In this case it's a matter of taste. But I will do some research with
the alternative implementation by Chris.
Cheers,
Reinhard
Re: Flow Database stuff ( The new FOM? )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Tuesday, July 15, 2003, at 08:28 AM, Christopher Oliver wrote:
> Reinhard Pötz wrote:
>
>> From: Christopher Oliver [mailto:res1cf5x@verizon.net]
> <snip>
>
>>
>>> catch (break) {
>>> // a continuation is being captured, // code to
>>> handle that goes here
>>> releaseSession();
>>> }
>>>
>>
>> ... and this is called after the pipeline has been processed? How is
>> this possible from a technical POV? If the view layer is called by
>> sendPageAndWait the flow interpreter isn't active until the response
>> returns from the client (map:call continuation="...").
>>
>> Reinhard
>>
> Unfortunately, you're right. In this case the call to releaseSession()
> is made when the continuation is created - which is before the view
> layer is called (see fom_system.js).
>
> I've just commited an update to Rhino that [re-]enables a further
> syntax extension, namely:
>
> catch (return) {
> // This continuation is about to be replaced with another
> continuation
> // code to handle that goes here
> }
>
> By placing the code to release the hibernate session inside, i.e.
>
> catch (return) {
> cocoon.releaseComponent(hibSession);
> }
>
> you get the effect you're looking for: namely that the session is
> released after calling the view layer but before control leaves the
> interpreter.
>
> As I said, Ovidiu and I decided to put these features in to try to
> provide the functionality provided by dynamic-wind in Scheme, but this
> kind of explicit resource management seems awkard and error-prone.
Thanks Chris
I think I will stick with the TomCat Filter technique at the moment, I
am struggling to see the advantage of using cocoon.***Component() stuff
in this situation to be honest.
regards Jeremy
Re: Flow Database stuff ( The new FOM? )
Posted by Christopher Oliver <re...@verizon.net>.
Reinhard Pötz wrote:
>From: Christopher Oliver [mailto:res1cf5x@verizon.net]
>
>
<snip>
>
>
>>catch (break) {
>> // a continuation is being captured,
>> // code to handle that goes here
>> releaseSession();
>>}
>>
>>
>
>... and this is called after the pipeline has been processed? How is
>this possible from a technical POV? If the view layer is called by
>sendPageAndWait the flow interpreter isn't active until the response
>returns from the client (map:call continuation="...").
>
>Reinhard
>
>
Unfortunately, you're right. In this case the call to releaseSession()
is made when the continuation is created - which is before the view
layer is called (see fom_system.js).
I've just commited an update to Rhino that [re-]enables a further syntax
extension, namely:
catch (return) {
// This continuation is about to be replaced with another continuation
// code to handle that goes here
}
By placing the code to release the hibernate session inside, i.e.
catch (return) {
cocoon.releaseComponent(hibSession);
}
you get the effect you're looking for: namely that the session is
released after calling the view layer but before control leaves the
interpreter.
As I said, Ovidiu and I decided to put these features in to try to
provide the functionality provided by dynamic-wind in Scheme, but this
kind of explicit resource management seems awkard and error-prone.
Chris
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: Christopher Oliver [mailto:res1cf5x@verizon.net]
> Reinhard Pötz wrote:
>
> >From: Jeremy Quinn
> >
> >
> >
> >>What I do not grok ATM, how does the Hibernate Session automatically
> >>get closed at the appropriate time (ie. after the view layer has
> >>completed)?
> >>
> >>
> >
> >IIU the current flow implementation correctly you have no
> chance but to
> >use lazy initializiation as implemented by you because after reaching
> >sendPageAndWait() the flow interpreter has no chance to
> react. Maybe we
> >need something like a "finalize" in pipeline processing where those
> >things (releasing of components) are done.
> >
> >HTH
> >Reinhard
> >
> >
> >
> >
> Actually, although not particularly user-friendly, there is a
> way to do
> this, even now, with the extended "catch" syntax supported by Rhino
> (which is intended to provide functionality similar to
> "dynamic-wind" in
> Scheme):
>
>
> var hibSession = null;
>
> function getSession() {
> if (hibSession == null) {
> hibSession = cocoon.getComponent("hibernateSession");
> }
> }
>
> function releaseSession() {
> if (hibSession != null) {
> cocoon.releaseComponent(hibSession);
> hibSession = null;
> }
> }
>
> catch (break) {
> // a continuation is being captured,
> // code to handle that goes here
> releaseSession();
> }
... and this is called after the pipeline has been processed? How is
this possible from a technical POV? If the view layer is called by
sendPageAndWait the flow interpreter isn't active until the response
returns from the client (map:call continuation="...").
Reinhard
>
> catch (continue) {
> // a continuation is being restored
> // code to handle that goes here
> }
>
> function myFlow() {
> var custBean = getSession().blah;
> sendPageAndWait("cust.xml", custBean);
> var anotherBean = getSession().blahblah
> }
>
Re: Flow Database stuff ( The new FOM? )
Posted by Christopher Oliver <re...@verizon.net>.
Reinhard Pötz wrote:
>From: Jeremy Quinn
>
>
>
>>What I do not grok ATM, how does the Hibernate Session automatically
>>get closed at the appropriate time (ie. after the view layer has
>>completed)?
>>
>>
>
>IIU the current flow implementation correctly you have no chance but to
>use lazy initializiation as implemented by you because after reaching
>sendPageAndWait() the flow interpreter has no chance to react. Maybe
>we need something like a "finalize" in pipeline processing where those
>things (releasing of components) are done.
>
>HTH
>Reinhard
>
>
>
>
Actually, although not particularly user-friendly, there is a way to do
this, even now, with the extended "catch" syntax supported by Rhino
(which is intended to provide functionality similar to "dynamic-wind" in
Scheme):
var hibSession = null;
function getSession() {
if (hibSession == null) {
hibSession = cocoon.getComponent("hibernateSession");
}
}
function releaseSession() {
if (hibSession != null) {
cocoon.releaseComponent(hibSession);
hibSession = null;
}
}
catch (break) {
// a continuation is being captured,
// code to handle that goes here
releaseSession();
}
catch (continue) {
// a continuation is being restored
// code to handle that goes here
}
function myFlow() {
var custBean = getSession().blah;
sendPageAndWait("cust.xml", custBean);
var anotherBean = getSession().blahblah
}
Re: Flow Database stuff ( The new FOM? )
Posted by Joerg Heinicke <jo...@gmx.de>.
IIU(C) = If I understand (correctly) IIRC :)
Joerg
Jeremy Quinn wrote:
> Incidentally, someone tell me what 'IIU' stands for, cannot find it
> anywhere .....
>
> regards Jeremy
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
> -----Original Message-----
> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
> Sent: Tuesday, July 15, 2003 11:33 AM
> To: dev@cocoon.apache.org
> Subject: Re: Flow Database stuff ( The new FOM? )
>
>
>
> On Tuesday, July 15, 2003, at 07:21 AM, Reinhard Pötz wrote:
>
> >
> > From: Jeremy Quinn
> >
> >> What I do not grok ATM, how does the Hibernate Session
> automatically
> >> get closed at the appropriate time (ie. after the view layer has
> >> completed)?
> >
> > IIU the current flow implementation correctly you have no
> chance but
> > to use lazy initializiation as implemented by you because after
> > reaching
> > sendPageAndWait() the flow interpreter has no chance to react. Maybe
> > we need something like a "finalize" in pipeline processing
> where those
> > things (releasing of components) are done.
>
> OK, I must have completely misunderstood what Chris's auto-magic
> component releasing was all about.
>
> Incidentally, someone tell me what 'IIU' stands for, cannot find it
> anywhere .....
sorry for that ... :(
"if I understand"
---
There was also an interesting answer by Chris on this!
Cheers,
Reinhard
>
> regards Jeremy
>
Re: Flow Database stuff ( The new FOM? )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Tuesday, July 15, 2003, at 07:21 AM, Reinhard Pötz wrote:
>
> From: Jeremy Quinn
>
>> What I do not grok ATM, how does the Hibernate Session automatically
>> get closed at the appropriate time (ie. after the view layer has
>> completed)?
>
> IIU the current flow implementation correctly you have no chance but to
> use lazy initializiation as implemented by you because after reaching
> sendPageAndWait() the flow interpreter has no chance to react. Maybe
> we need something like a "finalize" in pipeline processing where those
> things (releasing of components) are done.
OK, I must have completely misunderstood what Chris's auto-magic
component releasing was all about.
Incidentally, someone tell me what 'IIU' stands for, cannot find it
anywhere .....
regards Jeremy
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: Jeremy Quinn
> What I do not grok ATM, how does the Hibernate Session automatically
> get closed at the appropriate time (ie. after the view layer has
> completed)?
IIU the current flow implementation correctly you have no chance but to
use lazy initializiation as implemented by you because after reaching
sendPageAndWait() the flow interpreter has no chance to react. Maybe
we need something like a "finalize" in pipeline processing where those
things (releasing of components) are done.
HTH
Reinhard
Re: Flow Database stuff ( The new FOM? )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, July 14, 2003, at 04:39 PM, Hugo Burm wrote:
>
>
>
>> -----Original Message-----
>> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
>> Sent: Monday, July 14, 2003 3:43 PM
>> To: dev@cocoon.apache.org
>> Subject: Re: Flow Database stuff ( The new FOM? )
>>
>>
>>
>> On Sunday, July 13, 2003, at 10:40 AM, Reinhard Pötz wrote:
>>
>>>> However, once you have triggered the view layer with
>>>> SendPageAndWait(),
>>>> control does not return to the flow layer until the Response has
>>>> been
>>>> sent and the next Request received, thus loosing you the
>>>> opportunity to
>>>> close the Hibernate Session from the Flow layer before the
>>>> Response is
>>>> sent.
>>>
>>> Chris' experimental implementation of cocoon.getComponent() should
>>> solve
>>> this problem.
>>>
>>>
>>
>> I am not very confidant with the lifecycle of Cocoon/Avalon
>> components,
>> would someone be kind enough to recommend which methods I should
>> ideally write to implement a (Hibernate Factory) component, and at
>> which stage in FlowScript processing they get called?
>>
>> TIA
>>
>> regards Jeremy
>>
>>
>
> 1) There is an Avalon Hibernate Factory in the Hibernate_ext
> contributed
> package (see the Hibernate project at Sourceforge), and one in the
> Hibernate
> examples on the Wiki.
Thanks for the pointers.
What I do not grok ATM, how does the Hibernate Session automatically
get closed at the appropriate time (ie. after the view layer has
completed)?
I can see that initialize() and dispose() (are these the ones that
would get called on each Request?) seem to be dealing with
SessionFactory, not the Session itself.
TIA
regards Jeremy
RE: Flow Database stuff ( The new FOM? )
Posted by Hugo Burm <hu...@xs4all.nl>.
> -----Original Message-----
> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
> Sent: Monday, July 14, 2003 3:43 PM
> To: dev@cocoon.apache.org
> Subject: Re: Flow Database stuff ( The new FOM? )
>
>
>
> On Sunday, July 13, 2003, at 10:40 AM, Reinhard Pötz wrote:
>
> >> However, once you have triggered the view layer with
> >> SendPageAndWait(),
> >> control does not return to the flow layer until the Response has been
> >> sent and the next Request received, thus loosing you the
> >> opportunity to
> >> close the Hibernate Session from the Flow layer before the
> >> Response is
> >> sent.
> >
> > Chris' experimental implementation of cocoon.getComponent() should
> > solve
> > this problem.
> >
> >
>
> I am not very confidant with the lifecycle of Cocoon/Avalon components,
> would someone be kind enough to recommend which methods I should
> ideally write to implement a (Hibernate Factory) component, and at
> which stage in FlowScript processing they get called?
>
> TIA
>
> regards Jeremy
>
>
1) There is an Avalon Hibernate Factory in the Hibernate_ext contributed
package (see the Hibernate project at Sourceforge), and one in the Hibernate
examples on the Wiki.
2) You definitely need the paper:
http://avalon.apache.org/developing/developing-with-avalon.html
Download the printer-friendly version, save it to disk, load it in an
editor, remove all <[CDATA[ opening and closing tags, reload it in your
browser, and suddenly a lot of code examples will appear. This problem was
posted on the Avalon dev list about three weeks ago.
Hugo
Re: Flow Database stuff ( The new FOM? )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Sunday, July 13, 2003, at 10:40 AM, Reinhard Pötz wrote:
>> However, once you have triggered the view layer with
>> SendPageAndWait(),
>> control does not return to the flow layer until the Response has been
>> sent and the next Request received, thus loosing you the
>> opportunity to
>> close the Hibernate Session from the Flow layer before the
>> Response is
>> sent.
>
> Chris' experimental implementation of cocoon.getComponent() should
> solve
> this problem.
>
>
I am not very confidant with the lifecycle of Cocoon/Avalon components,
would someone be kind enough to recommend which methods I should
ideally write to implement a (Hibernate Factory) component, and at
which stage in FlowScript processing they get called?
TIA
regards Jeremy
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
> By passing a Bean persisted by Hibernate from the flow layer to the
> view layer, you are implementing SoC by allowing the view layer to
> decide what is relevant for that view. This aspect not being
> the Flow's
> concern.
Only to make it transparent (for me): The flow layer passes e.g. a
user bean with the id 4711 to the view layer. The view layer only
"knows" that it can expect a user bean and has tho show e.g. the name
and the adress and so it doesn't care where the bean comes from
(database,
webservice, ...). Do we agree on this?
>
> However, once you have triggered the view layer with
> SendPageAndWait(),
> control does not return to the flow layer until the Response has been
> sent and the next Request received, thus loosing you the
> opportunity to
> close the Hibernate Session from the Flow layer before the
> Response is
> sent.
Chris' experimental implementation of cocoon.getComponent() should solve
this problem.
> SendPage() might not suffer this problem, but due to the nature of a
> SAX event pipeline, I would not bet on it.
>
> With 'lazy initialisation' SQL Queries are only made when getter
> methods of the Bean are executed. If you have passed the Bean to the
> view layer, XPath expressions in JXPathTemplate (etc.) will result in
> those getter methods being accessed. If your flowscript has already
> released it's Hibernate Component, you are in trouble.
>
> You could clone the Bean to pass it to the view layer, but it is kind
> of self-defeating IMHO.
Why do you think it is self-defeating? IIUC the point of lazy
initialization
is calling the persistence layer at the time when it is really needed
(when I generate some output). If I pass the bean with
sendPageAndWait("myPage", {bean:bean}) I *already know* that I need this
bean
- otherwise I wouldn't pass it, wouldn't I?
Cheers,
Reinhard
Re: Flow Database stuff ( The new FOM? )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Friday, July 11, 2003, at 05:45 PM, Reinhard Pötz wrote:
>
> From: Jeremy Quinn
>
>> The problem arises when you wish to use a (brilliant) feature of
>> Hibernate called 'lazy-initialisation', whereby access to the DB is
>> only made when you actually ask for Bean Properties.
>>
>> This is particularly useful when you have large 'graphs' of related
>> Beans, for instance child/parent relationships, whereby loading one
>> Bean may result in the whole database loading!!
>>
>> If you have closed your Hibernate Session in your Flowscript, your
>> display layer can throw LazyInitialisationExceptions, because the
>> connection is no longer available.
>>
>> Not closing the Session after you have sent the Response, is
>> considered
>> bad practise, so the Servlet Filter is a handy solution.
>
> It's a pity that Hibernate is under LGPL - this would be a great
> example
> ...
> Have the Hibernate people ever been asked if they would put their
> great piece of software under a more Apache like licence?
Yes, they have been asked on numerous occasions, last time I noticed by
Hugo Burm (a cocoon regular), they are obviously pretty sick of being
asked because they can get pretty rude about it ....
They are firmly of the opinion that LGPL does not prevent Hibernate
being used by other projects, which is something I know this forum
strongly disagrees with.
I have not wanted to wade into that discussion with them TBH, I have
not found them to be a particularly friendly community.
They have several Apache jars in their dist, so I find it pretty
objectionable that the reverse cannot be accomplished!
> As I'm curious I have a technical question:
> What's the difference if I read the necessary data in the flow or some
> milliseconds latter in the view layer? What do I gain?
By passing a Bean persisted by Hibernate from the flow layer to the
view layer, you are implementing SoC by allowing the view layer to
decide what is relevant for that view. This aspect not being the Flow's
concern.
However, once you have triggered the view layer with SendPageAndWait(),
control does not return to the flow layer until the Response has been
sent and the next Request received, thus loosing you the opportunity to
close the Hibernate Session from the Flow layer before the Response is
sent.
SendPage() might not suffer this problem, but due to the nature of a
SAX event pipeline, I would not bet on it.
With 'lazy initialisation' SQL Queries are only made when getter
methods of the Bean are executed. If you have passed the Bean to the
view layer, XPath expressions in JXPathTemplate (etc.) will result in
those getter methods being accessed. If your flowscript has already
released it's Hibernate Component, you are in trouble.
You could clone the Bean to pass it to the view layer, but it is kind
of self-defeating IMHO.
>>>> However, with the generous assistance of Ugo Cei, I am
>> successfully
>>>> using the technique highlighted in the first sample here [1] for
>>>> managing Hibernate Sessions in my FlowApp.
>>>>
>>>> The basic issue is that you want to avoid maintaining an open
>>>> Hibernate Session whilst the user is interacting with a
>> form (etc.).
>>>> The Session
>>>> should to be opened and closed during each Request (and any
>>>> Transient
>>>> Beans refreshed before re-use). The above technique uses a Servlet
>>>> Filter to manage this, with a static method to retrieve a
>> Session in
>>>> your flowscript at the beginning of each Request that needs it.
>>>>
>>>> [1] http://hibernate.bluemars.net/43.html
>>>>
>>>
>>> Sounds cool and I remember that I've already heard from it
>> but haven't
>>> found the time to try it myself.
>>
>> I am using it ATM on a client project and it is a dream!
>>
>>> <dream-mode>
>>> I would like to use this Avalon component mentioned above and the
>>> Flow interpreter takes care of releasing (and providing) stateful
>>> components within my scripts. So I would have to lookup
>> the Hibernate
>>> Session at the beginning(2) and until I finally release(8)
>> it I don't
>>> have to take care for it.
>>>
>>> 1 function xxx() {
>>> 2 var hibS = cocoon.getComponent( "hibernateSession" );
>>> 3 var custBean = hibS.blablabla // get your beans with hibernate
>>> 4 sendPageAndWait( "bla", {customer : custBean} );
>>> 5 // do something (updates, reads, whatever)
>>> 6 var someDifferentBean = hibS.blalbalba
>>> 7 sendPageAndWait( "bla", {diff : someDifferentBean } );
>>> 8 sendPageAndRelease( "thankYou", {} );
>>> 9 }
>>>
>>> This would be IMO a very elegant way and IIU the recent
>> discussion
>>> correctly possible from a technical point of view. Maybe Chris can
>>> comment on this :-)
>>>
>>> Thoughts?
>>
>> This is a reality!
>> Wake up and smell the toast ;)
>
> ;-)
>
>>
>> I just do not use the Component Manager, because I cannot manage the
>> Hibernate Session entirely from the FlowScript layer as explained
>> above. I have a static method that gives me a fresh Session. I get s
>> Session at the beginning of Function, or directly after a
>> sendPageAndWait().
>
> Is it possible to have a look at the sources? I would be very
> interested!
I don't have any really clear examples to show you right now (I have
tried to extract some but I am not happy with them, I am also not very
happy NOT sending something ;), but I was thinking of making a sample
'User Editor' as a contribution to the wiki, once my work-rush is over
....
regards Jeremy
RE: Flow Database stuff ( The new FOM? )
Posted by Hugo Burm <hu...@xs4all.nl>.
Hello,
I tried to raise this LGPL issue in the Hibernate community.
The answer of Gaving King and Cristian Bauer was: we stick to LGPL untill we
have a compelling reason (a real case) to change our minds.
I did not try to explain that Apache is refusing LGPL altogether.
Hugo
-----Original Message-----
From: Reinhard Pötz [mailto:reinhard_poetz@gmx.net]
Sent: Friday, July 11, 2003 6:46 PM
To: dev@cocoon.apache.org
Subject: RE: Flow Database stuff ( The new FOM? )
It's a pity that Hibernate is under LGPL - this would be a great example
...
Have the Hibernate people ever been asked if they would put their
great piece of software under a more Apache like licence?
Cheers,
Reinhard
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: Jeremy Quinn
> The problem arises when you wish to use a (brilliant) feature of
> Hibernate called 'lazy-initialisation', whereby access to the DB is
> only made when you actually ask for Bean Properties.
>
> This is particularly useful when you have large 'graphs' of related
> Beans, for instance child/parent relationships, whereby loading one
> Bean may result in the whole database loading!!
>
> If you have closed your Hibernate Session in your Flowscript, your
> display layer can throw LazyInitialisationExceptions, because the
> connection is no longer available.
>
> Not closing the Session after you have sent the Response, is
> considered
> bad practise, so the Servlet Filter is a handy solution.
It's a pity that Hibernate is under LGPL - this would be a great example
...
Have the Hibernate people ever been asked if they would put their
great piece of software under a more Apache like licence?
As I'm curious I have a technical question:
What's the difference if I read the necessary data in the flow or some
milliseconds latter in the view layer? What do I gain?
> >> However, with the generous assistance of Ugo Cei, I am
> successfully
> >> using the technique highlighted in the first sample here [1] for
> >> managing Hibernate Sessions in my FlowApp.
> >>
> >> The basic issue is that you want to avoid maintaining an open
> >> Hibernate Session whilst the user is interacting with a
> form (etc.).
> >> The Session
> >> should to be opened and closed during each Request (and any
> >> Transient
> >> Beans refreshed before re-use). The above technique uses a Servlet
> >> Filter to manage this, with a static method to retrieve a
> Session in
> >> your flowscript at the beginning of each Request that needs it.
> >>
> >> [1] http://hibernate.bluemars.net/43.html
> >>
> >
> > Sounds cool and I remember that I've already heard from it
> but haven't
> > found the time to try it myself.
>
> I am using it ATM on a client project and it is a dream!
>
> > <dream-mode>
> > I would like to use this Avalon component mentioned above and the
> > Flow interpreter takes care of releasing (and providing) stateful
> > components within my scripts. So I would have to lookup
> the Hibernate
> > Session at the beginning(2) and until I finally release(8)
> it I don't
> > have to take care for it.
> >
> > 1 function xxx() {
> > 2 var hibS = cocoon.getComponent( "hibernateSession" );
> > 3 var custBean = hibS.blablabla // get your beans with hibernate
> > 4 sendPageAndWait( "bla", {customer : custBean} );
> > 5 // do something (updates, reads, whatever)
> > 6 var someDifferentBean = hibS.blalbalba
> > 7 sendPageAndWait( "bla", {diff : someDifferentBean } );
> > 8 sendPageAndRelease( "thankYou", {} );
> > 9 }
> >
> > This would be IMO a very elegant way and IIU the recent
> discussion
> > correctly possible from a technical point of view. Maybe Chris can
> > comment on this :-)
> >
> > Thoughts?
>
> This is a reality!
> Wake up and smell the toast ;)
;-)
>
> I just do not use the Component Manager, because I cannot manage the
> Hibernate Session entirely from the FlowScript layer as explained
> above. I have a static method that gives me a fresh Session. I get s
> Session at the beginning of Function, or directly after a
> sendPageAndWait().
Is it possible to have a look at the sources? I would be very
interested!
Cheers,
Reinhard
Re: Flow Database stuff ( The new FOM? )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Friday, July 11, 2003, at 03:13 PM, Reinhard Pötz wrote:
>
>> From: Jeremy Quinn
>
>>
>> On Thursday, July 10, 2003, at 09:04 AM, Reinhard Pötz wrote:
>>
>>>
>>> IMO no. I would use Object/Relational mapping tools like OJB
>>> http://db.apache.org/ojb/ or Hibernate
>>> (http://hibernate.bluemars.net).
>>>
>>>
>>>> Is there a wiki somewhere on this type of thing?
>>>
>>> http://wiki.cocoondev.org/
>>> Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscr
>>> ipt
>>> and here you find a component providing a Hibernate session:
>>> http://cvs.werken.com/viewcvs.cgi/plexus-components/hibernate
>>> /src/java/org/apache/plexus/hibernate/
>>> DefaultHibernateService.java?cvsro
>>> ot=plexus
>>>
>>
>> Forgive me if I have not entirely understood the usage
>> patterns of the
>> classes above.
>
> IIUC this component provides a Hibernate Session. At the current
> FOM implementation you have to take care that you open and close
> these sessions correctly.
The problem arises when you wish to use a (brilliant) feature of
Hibernate called 'lazy-initialisation', whereby access to the DB is
only made when you actually ask for Bean Properties.
This is particularly useful when you have large 'graphs' of related
Beans, for instance child/parent relationships, whereby loading one
Bean may result in the whole database loading!!
If you have closed your Hibernate Session in your Flowscript, your
display layer can throw LazyInitialisationExceptions, because the
connection is no longer available.
Not closing the Session after you have sent the Response, is considered
bad practise, so the Servlet Filter is a handy solution.
>> However, with the generous assistance of Ugo Cei, I am successfully
>> using the technique highlighted in the first sample here [1] for
>> managing Hibernate Sessions in my FlowApp.
>>
>> The basic issue is that you want to avoid maintaining an open
>> Hibernate
>> Session whilst the user is interacting with a form (etc.).
>> The Session
>> should to be opened and closed during each Request (and any
>> Transient
>> Beans refreshed before re-use). The above technique uses a Servlet
>> Filter to manage this, with a static method to retrieve a Session in
>> your flowscript at the beginning of each Request that needs it.
>>
>> [1] http://hibernate.bluemars.net/43.html
>>
>
> Sounds cool and I remember that I've already heard from it but
> haven't found the time to try it myself.
I am using it ATM on a client project and it is a dream!
> <dream-mode>
> I would like to use this Avalon component mentioned above and
> the Flow interpreter takes care of releasing (and providing)
> stateful components within my scripts. So I would have to
> lookup the Hibernate Session at the beginning(2) and until I
> finally release(8) it I don't have to take care for it.
>
> 1 function xxx() {
> 2 var hibS = cocoon.getComponent( "hibernateSession" );
> 3 var custBean = hibS.blablabla // get your beans with hibernate
> 4 sendPageAndWait( "bla", {customer : custBean} );
> 5 // do something (updates, reads, whatever)
> 6 var someDifferentBean = hibS.blalbalba
> 7 sendPageAndWait( "bla", {diff : someDifferentBean } );
> 8 sendPageAndRelease( "thankYou", {} );
> 9 }
>
> This would be IMO a very elegant way and IIU the recent discussion
> correctly possible from a technical point of view. Maybe Chris
> can comment on this :-)
>
> Thoughts?
This is a reality!
Wake up and smell the toast ;)
I just do not use the Component Manager, because I cannot manage the
Hibernate Session entirely from the FlowScript layer as explained
above. I have a static method that gives me a fresh Session. I get s
Session at the beginning of Function, or directly after a
sendPageAndWait().
>
> </dream-mode>
HTH
regards Jeremy
Re: External Blocks (was Re: Flow Database stuff ( The new FOM? ))
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Geoff Howard wrote:
> Daniel Fagerstrom wrote:
>
>> Hugo Burm wrote:
>> <snip/>
>>
>>> - Hibernate is LGPL.
>>> This is a pain in the ass. I cannot provide a ready-to-use Hibernate
>>> cocoon
>>> block because of LGPL versus Apache license issues.
>>
>>
>> You can, it can be hosted under cocoondev.org like Fins and CVSSource,
>> that booth are based on LGPL libraries. A Hibernate block under
>> cocoondev where discussed in the thread
>> http://marc.theaimsgroup.com/?t=105074471400001&r=1&w=2, but I don't
>> know if anything happened.
>>
>> -- o --
>>
>> A somewhat OT discussion about "external" blocks:
>>
>> It is possible to host Cocoon blocks (I talk about the current compile
>> time installable blocks, not the forthcomming "real" blocks) outside
>> the the Cocoon CVS. I submitted some patches to the Fins community
>> for packaging Fins as a block.
>>
>> An externally hosted block consists of the block itself together with
>> some xml fragments for configuration. The installation instructions
>> are as follows:
>> * download the latest cocoon-2.1
>> * copy (or put a link to) your block to cocoon-2.1/src/blocks
>> * patch cocoon-2.1/gump.xml and cocoon-2.1/lib/jars.xml with the
>> configuration snippets
>> * ./build.sh
>> not that complicated. It would be even simpler to install an external
>> block if the gump.xml and jars.xml patching was made with the xmap
>> mechanism, in that case it would be enough to copy the block to the
>> blocks directory and recompile. The main drawback with this would be
>> that the gump descriptor would have to be generated before it could be
>> used.
>
>
> Couldn't you compile the code elsewhere, drop the jar in WEB-INF, and
> edit the .xconf, and .xmap files you need using the xpatch task? You
> would not be able to add new things to .roles, but can't we already get
> around that? (with component-instance in cocoon.xconf)
Yes I did like that before when I developed custom Cocoon components for
my webapps. When I did that, I had to write an own build file and make
sure that the class path contains everything that I need. It is simpler
to just reuse Cocoons build system. And I also happen to like the block
concept so I prefer to use that :)
> If that works,
> I could help work up a target to do this stuff - it'd be pretty trivial.
I guess I was a litle bit unclear, unfortunatly I have no cool blocks to
provide at the moment ;) I merely wanted to tell Hugo that there are ways
to publish an LGPL dependent Cocoon block, if he wanted to, (I got the
impression that he allready had written an Hibernate block).
On the more general side I think it could be worth while to discuss how
to construct and use external blocks. I think that Forrest and Lenya as
well as the cocoondev projects would be easier to install and use if
they where packaged as blocks. And as indicated in my earlier mail, the
mechanisms are allready provided by Cocoon, even if they could be made
somewhat easier to use.
/Daniel
External Blocks (was Re: Flow Database stuff ( The new FOM? ))
Posted by Geoff Howard <co...@leverageweb.com>.
Daniel Fagerstrom wrote:
> Hugo Burm wrote:
> <snip/>
>
>> - Hibernate is LGPL.
>> This is a pain in the ass. I cannot provide a ready-to-use Hibernate
>> cocoon
>> block because of LGPL versus Apache license issues.
>
> You can, it can be hosted under cocoondev.org like Fins and CVSSource,
> that booth are based on LGPL libraries. A Hibernate block under
> cocoondev where discussed in the thread
> http://marc.theaimsgroup.com/?t=105074471400001&r=1&w=2, but I don't
> know if anything happened.
>
> -- o --
>
> A somewhat OT discussion about "external" blocks:
>
> It is possible to host Cocoon blocks (I talk about the current compile
> time installable blocks, not the forthcomming "real" blocks) outside the
> the Cocoon CVS. I submitted some patches to the Fins community for
> packaging Fins as a block.
>
> An externally hosted block consists of the block itself together with
> some xml fragments for configuration. The installation instructions are
> as follows:
> * download the latest cocoon-2.1
> * copy (or put a link to) your block to cocoon-2.1/src/blocks
> * patch cocoon-2.1/gump.xml and cocoon-2.1/lib/jars.xml with the
> configuration snippets
> * ./build.sh
> not that complicated. It would be even simpler to install an external
> block if the gump.xml and jars.xml patching was made with the xmap
> mechanism, in that case it would be enough to copy the block to the
> blocks directory and recompile. The main drawback with this would be
> that the gump descriptor would have to be generated before it could be
> used.
Couldn't you compile the code elsewhere, drop the jar in WEB-INF, and
edit the .xconf, and .xmap files you need using the xpatch task? You
would not be able to add new things to .roles, but can't we already get
around that? (with component-instance in cocoon.xconf) If that works,
I could help work up a target to do this stuff - it'd be pretty trivial.
Geoff
Re: Flow Database stuff ( The new FOM? )
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Hugo Burm wrote:
<snip/>
> - Hibernate is LGPL.
> This is a pain in the ass. I cannot provide a ready-to-use Hibernate cocoon
> block because of LGPL versus Apache license issues.
You can, it can be hosted under cocoondev.org like Fins and CVSSource,
that booth are based on LGPL libraries. A Hibernate block under
cocoondev where discussed in the thread
http://marc.theaimsgroup.com/?t=105074471400001&r=1&w=2, but I don't
know if anything happened.
-- o --
A somewhat OT discussion about "external" blocks:
It is possible to host Cocoon blocks (I talk about the current compile
time installable blocks, not the forthcomming "real" blocks) outside the
the Cocoon CVS. I submitted some patches to the Fins community for
packaging Fins as a block.
An externally hosted block consists of the block itself together with
some xml fragments for configuration. The installation instructions are
as follows:
* download the latest cocoon-2.1
* copy (or put a link to) your block to cocoon-2.1/src/blocks
* patch cocoon-2.1/gump.xml and cocoon-2.1/lib/jars.xml with the
configuration snippets
* ./build.sh
not that complicated. It would be even simpler to install an external
block if the gump.xml and jars.xml patching was made with the xmap
mechanism, in that case it would be enough to copy the block to the
blocks directory and recompile. The main drawback with this would be
that the gump descriptor would have to be generated before it could be used.
/Daniel
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: Hugo Burm
> Hello,
>
> This <dreammode> is almost a reality. See the Wiki pages on Hibernate.
>
> Main spoilers are:
>
> - A user can quit in the middle of your function xxx (e.g. by
> closing the browser). This will generate a zombie Hibernate
> session. Jeremy and Ugo are using a workaround based on an
> newer version of the servlet api.
Maybe Chris' latest prototyp of FOM_Cocoon can help to manage
the "zombie" session problem.
>
> - Hibernate is LGPL.
> This is a pain in the ass. I cannot provide a ready-to-use
> Hibernate cocoon block because of LGPL versus Apache license issues.
We (the Cocoon community) should contact them. Maybe there's a chance
...
Cheers,
Reinhard
RE: Flow Database stuff ( The new FOM? )
Posted by Hugo Burm <hu...@xs4all.nl>.
Hello,
This <dreammode> is almost a reality. See the Wiki pages on Hibernate.
Main spoilers are:
- A user can quit in the middle of your function xxx (e.g. by closing the
browser). This will generate a zombie Hibernate session. Jeremy and Ugo are
using a workaround based on an newer version of the servlet api.
- Hibernate is LGPL.
This is a pain in the ass. I cannot provide a ready-to-use Hibernate cocoon
block because of LGPL versus Apache license issues.
Hugo
-----Original Message-----
From: Reinhard Pötz [mailto:reinhard_poetz@gmx.net]
Sent: Friday, July 11, 2003 4:14 PM
To: dev@cocoon.apache.org
Subject: RE: Flow Database stuff ( The new FOM? )
<dream-mode>
I would like to use this Avalon component mentioned above and
the Flow interpreter takes care of releasing (and providing)
stateful components within my scripts. So I would have to
lookup the Hibernate Session at the beginning(2) and until I
finally release(8) it I don't have to take care for it.
1 function xxx() {
2 var hibS = cocoon.getComponent( "hibernateSession" );
3 var custBean = hibS.blablabla // get your beans with hibernate
4 sendPageAndWait( "bla", {customer : custBean} );
5 // do something (updates, reads, whatever)
6 var someDifferentBean = hibS.blalbalba
7 sendPageAndWait( "bla", {diff : someDifferentBean } );
8 sendPageAndRelease( "thankYou", {} );
9 }
This would be IMO a very elegant way and IIU the recent discussion
correctly possible from a technical point of view. Maybe Chris
can comment on this :-)
Thoughts?
</dream-mode>
Cheers,
Reinhard
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
> From: Jeremy Quinn
>
> On Thursday, July 10, 2003, at 09:04 AM, Reinhard Pötz wrote:
>
> >
> > IMO no. I would use Object/Relational mapping tools like OJB
> > http://db.apache.org/ojb/ or Hibernate
> > (http://hibernate.bluemars.net).
> >
> >
> >> Is there a wiki somewhere on this type of thing?
> >
> > http://wiki.cocoondev.org/
> > Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscr
> > ipt
> > and here you find a component providing a Hibernate session:
> > http://cvs.werken.com/viewcvs.cgi/plexus-components/hibernate
> > /src/java/org/apache/plexus/hibernate/
> > DefaultHibernateService.java?cvsro
> > ot=plexus
> >
>
> Forgive me if I have not entirely understood the usage
> patterns of the
> classes above.
IIUC this component provides a Hibernate Session. At the current
FOM implementation you have to take care that you open and close
these sessions correctly.
>
> However, with the generous assistance of Ugo Cei, I am successfully
> using the technique highlighted in the first sample here [1] for
> managing Hibernate Sessions in my FlowApp.
>
> The basic issue is that you want to avoid maintaining an open
> Hibernate
> Session whilst the user is interacting with a form (etc.).
> The Session
> should to be opened and closed during each Request (and any
> Transient
> Beans refreshed before re-use). The above technique uses a Servlet
> Filter to manage this, with a static method to retrieve a Session in
> your flowscript at the beginning of each Request that needs it.
>
> [1] http://hibernate.bluemars.net/43.html
>
Sounds cool and I remember that I've already heard from it but
haven't found the time to try it myself.
<dream-mode>
I would like to use this Avalon component mentioned above and
the Flow interpreter takes care of releasing (and providing)
stateful components within my scripts. So I would have to
lookup the Hibernate Session at the beginning(2) and until I
finally release(8) it I don't have to take care for it.
1 function xxx() {
2 var hibS = cocoon.getComponent( "hibernateSession" );
3 var custBean = hibS.blablabla // get your beans with hibernate
4 sendPageAndWait( "bla", {customer : custBean} );
5 // do something (updates, reads, whatever)
6 var someDifferentBean = hibS.blalbalba
7 sendPageAndWait( "bla", {diff : someDifferentBean } );
8 sendPageAndRelease( "thankYou", {} );
9 }
This would be IMO a very elegant way and IIU the recent discussion
correctly possible from a technical point of view. Maybe Chris
can comment on this :-)
Thoughts?
</dream-mode>
Cheers,
Reinhard
Re: Flow Database stuff ( The new FOM? )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, July 10, 2003, at 09:04 AM, Reinhard Pötz wrote:
>
> IMO no. I would use Object/Relational mapping tools like OJB
> http://db.apache.org/ojb/ or Hibernate (http://hibernate.bluemars.net).
>
>
>> Is there a wiki somewhere on this type of thing?
>
> http://wiki.cocoondev.org/
> Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscr
> ipt
> and here you find a component providing a Hibernate session:
> http://cvs.werken.com/viewcvs.cgi/plexus-components/hibernate
> /src/java/org/apache/plexus/hibernate/
> DefaultHibernateService.java?cvsro
> ot=plexus
>
Forgive me if I have not entirely understood the usage patterns of the
classes above.
However, with the generous assistance of Ugo Cei, I am successfully
using the technique highlighted in the first sample here [1] for
managing Hibernate Sessions in my FlowApp.
The basic issue is that you want to avoid maintaining an open Hibernate
Session whilst the user is interacting with a form (etc.). The Session
should to be opened and closed during each Request (and any Transient
Beans refreshed before re-use). The above technique uses a Servlet
Filter to manage this, with a static method to retrieve a Session in
your flowscript at the beginning of each Request that needs it.
[1] http://hibernate.bluemars.net/43.html
HTH
regards Jeremy
RE: Flow Database stuff ( The new FOM? )
Posted by Reinhard Pötz <re...@gmx.net>.
From: JD Daniels
> ok, I am confused on what is happening to the Datbase.js
> file. but instead of a request for the long explanation, I
> will settle for a quick yes or no.
>
> I am a java newbie... so bear with me...
>
> From the petstore:
>
> // temporary hack to avoid requiring datasource
> config in cocoon.xconf
> java.lang.Class.forName("org.hsqldb.jdbcDriver");
> var jdbc =
> java.sql.DriverManager.getConnection("jdbc:hsqldb:.",
> "sa", "")
> var conn = new Database(jdbc);
> if (this.hsql == null) {
> // keep hsql in-memory database alive
> this.hsql =
> java.sql.DriverManager.getConnection("jdbc:hsqldb:.", "sa", "");
> }
> return conn;
> } else {
> // lookup datasource in cocoon.xconf
> return Database.getConnection(id);
> }
>
> Is what has been talked about here on the list mean the "Best
> Practice" way to get a database connection in flow is the way
> that is commented here as a "temporary hack" ie. use
> java.lang.whatever and code as if we were writing the app in
> pure java?
IMO no. I would use Object/Relational mapping tools like OJB
http://db.apache.org/ojb/ or Hibernate (http://hibernate.bluemars.net).
> Is there a wiki somewhere on this type of thing?
http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscr
ipt
and here you find a component providing a Hibernate session:
http://cvs.werken.com/viewcvs.cgi/plexus-components/hibernate
/src/java/org/apache/plexus/hibernate/DefaultHibernateService.java?cvsro
ot=plexus
> (I have been
> building apps in PHP and PERL for a few years, and its gets
> frustrating KNOWING way better tools are RIGHT HERE in front of me :)
Currently we are finishing the flow itself and try to find a way how to
continue with XMLForms/JXForms in the future. After this we will have
to write *a lot of* documentation. I know, this doesn't help you
right now but of course we can help you here on the cocoon mailing
lists.
;-) hint: We would be very pleased if you could help us writing
some of the docs that guide other users into the right direction if they
have similar problems (espacially as you have a lot of knowledge in
other
languages/framworks and this is of course one of our most important
target
groups)
> Sorry if this is a pain in the *** question, bu tthe idea of
> flow has me giddy. But I am stuck on the "cannot convert null
> to an object issue"
Where do you get this error? Usually this happens if you change your
scripts and the context is reset and all variables are reset.
Cheers,
Reinhard
Flow Database stuff ( The new FOM? )
Posted by JD Daniels <jd...@datatrio.com>.
ok, I am confused on what is happening to the Datbase.js file. but instead
of a request for the long explanation, I will settle for a quick yes or no.
I am a java newbie... so bear with me...
>From the petstore:
// temporary hack to avoid requiring datasource config in
cocoon.xconf
java.lang.Class.forName("org.hsqldb.jdbcDriver");
var jdbc = java.sql.DriverManager.getConnection("jdbc:hsqldb:.",
"sa", "")
var conn = new Database(jdbc);
if (this.hsql == null) {
// keep hsql in-memory database alive
this.hsql =
java.sql.DriverManager.getConnection("jdbc:hsqldb:.", "sa", "");
}
return conn;
} else {
// lookup datasource in cocoon.xconf
return Database.getConnection(id);
}
Is what has been talked about here on the list mean the "Best Practice" way
to get a database connection in flow is the way that is commented here as a
"temporary hack" ie. use java.lang.whatever and code as if we were writing
the app in pure java?
Is there a wiki somewhere on this type of thing? (I have been building apps
in PHP and PERL for a few years, and its gets frustrating KNOWING way better
tools are RIGHT HERE in front of me :)
Sorry if this is a pain in the *** question, bu tthe idea of flow has me
giddy. But I am stuck on the "cannot convert null to an object issue"
JD Daniels
RE: [Vote] Cocoon Advanced Control Flow
Posted by Reinhard Pötz <re...@gmx.net>.
From: Steven Noels
> On 9/07/2003 14:37 Reinhard Pötz wrote:
>
> > [3] I'm aware of Sylvain's and Marc's proposal on changing
> > the scope of available controllers. I contacted Sylvain off-list
> > and the said that they want to come up with a concrete
> > implementation
> > of their proposal in the future and this should *not* influence
> > the release of Cocoon 2.1 as the proposed changes would
> only have
> > a small impact on the *public* interfaces.
>
> +1 under the assumption that:
>
> - we can reasonably expect that Sylvain & Marc will try to minimize
> the impact on public interfaces (i.e. sitemap syntax and friends) of
> their planned future contributions
>
> - the 'original flow' is considered to be but one implementation of
> the aspect of flow handling in Cocoon, especially in the
> naming sense.
> It should be possible that sitemap constructs can be
> reconsidered, and
> it should also be possible that 'Flow' is considered to be a
> generalized
> service in Cocoon, with a number of realisations, without the
> 'original
> flow' claiming the entire Flow concept thought- and namespace
No problem if the community decides in the future to go this way things
will change. And IIUC from a technical POV the proposed changes are
pretty
small *for the user* of the already existing JavaScript _controller_ ;-)
and we can help them if we provide a 'compatibility' mode (as suggested
by Sylvain) that writes WARN logs and if we write into all release docs
that a public interface will be deprecated.
> It's good to see progress in this matter, thank you for
> shepherding the discussion into a vote, Reinhard!
:-)
Cheers,
Reinhard
Re: [Vote] Cocoon Advanced Control Flow
Posted by Steven Noels <st...@outerthought.org>.
On 9/07/2003 14:37 Reinhard Pötz wrote:
> [3] I'm aware of Sylvain's and Marc's proposal on changing
> the scope of available controllers. I contacted Sylvain off-list
> and the said that they want to come up with a concrete
> implementation
> of their proposal in the future and this should *not* influence
> the release of Cocoon 2.1 as the proposed changes would only have
> a small impact on the *public* interfaces.
+1 under the assumption that:
- we can reasonably expect that Sylvain & Marc will try to minimize
the impact on public interfaces (i.e. sitemap syntax and friends) of
their planned future contributions
- the 'original flow' is considered to be but one implementation of
the aspect of flow handling in Cocoon, especially in the naming sense.
It should be possible that sitemap constructs can be reconsidered, and
it should also be possible that 'Flow' is considered to be a generalized
service in Cocoon, with a number of realisations, without the 'original
flow' claiming the entire Flow concept thought- and namespace
It's good to see progress in this matter, thank you for shepherding the
discussion into a vote, Reinhard!
</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: [Vote] Cocoon Advanced Control Flow
Posted by Reinhard Pötz <re...@gmx.net>.
From: Marc Portier
>
> just dotting the i's and crossing the t's
> (don't want to be nagging)
>
> Reinhard Pötz wrote:
>
> <snip />
>
> > [D] All flow interpreters[3] are Avalon components and declared
> > in the cocoon.xonf:
> >
> > <flow-interpreters default="[yourLanguage]"
> logger="[yourLogger]">
> > ...
> > </flow-interpreters>
> >
>
> our proposal was about having also non-interpreter
> implementations of the 'generalized flow' concept
>
> so while the xconf remark is totally valid, the link in the same
> paragraph to our proposal might be a bit misleading...
>
> >
> > [3] I'm aware of Sylvain's and Marc's proposal on changing
> > the scope of available controllers. I contacted Sylvain off-list
> > and the said that they want to come up with a concrete
> > implementation
>
> - we felt the group not able to really conclude the discussion at
> this point, and don't want to be the PITA that blocks releases.
>
> - we think code will say more then the wiki write up:
> (while we do appear to make some 'theoretical' sense, and got
> some people into the thinking apparently, I still can't shake off
> the feeling that some still carry some YAGNI-feeling around this)
>
> - we are committed to do our discussions, and status reporting
> towards this implementation on this list hoping that the road to
> it will be a helpful tutorial into our thinking here
>
> > of their proposal in the future and this should *not* influence
> > the release of Cocoon 2.1 as the proposed changes would
> only have
> > a small impact on the *public* interfaces.
> >
>
> - we are convinced at this stage (and wil do our best to keep it
> as such) that the impact on the public interfaces will be indeed
> limited
>
> - we are hoping on the other side that our lenient position at
> this stage is not going to be cutting us back in re-considering
> some of this in the future.
Thanks for the clarification!
Cheers,
Reinhard
Re: [Vote] Cocoon Advanced Control Flow
Posted by Marc Portier <mp...@outerthought.org>.
just dotting the i's and crossing the t's
(don't want to be nagging)
Reinhard Pötz wrote:
<snip />
> [D] All flow interpreters[3] are Avalon components and declared
> in the cocoon.xonf:
>
> <flow-interpreters default="[yourLanguage]" logger="[yourLogger]">
> ...
> </flow-interpreters>
>
our proposal was about having also non-interpreter
implementations of the 'generalized flow' concept
so while the xconf remark is totally valid, the link in the same
paragraph to our proposal might be a bit misleading...
>
> [3] I'm aware of Sylvain's and Marc's proposal on changing
> the scope of available controllers. I contacted Sylvain off-list
> and the said that they want to come up with a concrete
> implementation
- we felt the group not able to really conclude the discussion at
this point, and don't want to be the PITA that blocks releases.
- we think code will say more then the wiki write up:
(while we do appear to make some 'theoretical' sense, and got
some people into the thinking apparently, I still can't shake off
the feeling that some still carry some YAGNI-feeling around this)
- we are committed to do our discussions, and status reporting
towards this implementation on this list hoping that the road to
it will be a helpful tutorial into our thinking here
> of their proposal in the future and this should *not* influence
> the release of Cocoon 2.1 as the proposed changes would only have
> a small impact on the *public* interfaces.
>
- we are convinced at this stage (and wil do our best to keep it
as such) that the impact on the public interfaces will be indeed
limited
- we are hoping on the other side that our lenient position at
this stage is not going to be cutting us back in re-considering
some of this in the future.
hope this is acceptable to all
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [Vote] Cocoon Advanced Control Flow
Posted by Vadim Gritsenko <va...@verizon.net>.
Reinhard Pötz wrote:
>From: Vadim Gritsenko
>
>
>
>>Reinhard Pötz wrote:
>><snip/>
>>
>>
>>
>>>Thank you for voting/reading so far (13 items ;-)!
>>>
>>>
>>>
>>Reinhard,
>>
>>This doco nicely summarizes what we have so far in the flow. And,
>>because it is already present, and was already dicussed/voted
>>some time ago, what here we are voting for? :)
>>
>>
>
>I can't remember that we have ever voted on the base requirments a
>flow interpreter has to fullfill, the FOM and the behaviour of
>our first implementation: the JavaScript interpreter. And as the
>flow has never been released yet I think a vote is necessary.
>
Ok, you've got mine +1 :)
Vadim
Re: [Vote] Cocoon Advanced Control Flow
Posted by Christopher Oliver <re...@verizon.net>.
+1.
Chris
Reinhard Pötz wrote:
>From: Vadim Gritsenko
>
>
>
>>Reinhard Pötz wrote:
>><snip/>
>>
>>
>>
>>>Thank you for voting/reading so far (13 items ;-)!
>>>
>>>
>>>
>>Reinhard,
>>
>>This doco nicely summarizes what we have so far in the flow. And,
>>because it is already present, and was already dicussed/voted
>>some time
>>ago, what here we are voting for? :)
>>
>>
>
>I can't remember that we have ever voted on the base requirments a
>flow interpreter has to fullfill, the FOM and the behaviour of
>our first implementation: the JavaScript interpreter. And as the
>flow has never been released yet I think a vote is necessary.
>
>Cheers,
>Reinhard
>
>
>
>
RE: [Vote] Cocoon Advanced Control Flow
Posted by Reinhard Pötz <re...@gmx.net>.
From: Vadim Gritsenko
>
> Reinhard Pötz wrote:
> <snip/>
>
> >Thank you for voting/reading so far (13 items ;-)!
> >
>
> Reinhard,
>
> This doco nicely summarizes what we have so far in the flow. And,
> because it is already present, and was already dicussed/voted
> some time
> ago, what here we are voting for? :)
I can't remember that we have ever voted on the base requirments a
flow interpreter has to fullfill, the FOM and the behaviour of
our first implementation: the JavaScript interpreter. And as the
flow has never been released yet I think a vote is necessary.
Cheers,
Reinhard
Re: [Vote] Cocoon Advanced Control Flow
Posted by Vadim Gritsenko <va...@verizon.net>.
Reinhard Pötz wrote:
<snip/>
>Thank you for voting/reading so far (13 items ;-)!
>
Reinhard,
This doco nicely summarizes what we have so far in the flow. And,
because it is already present, and was already dicussed/voted some time
ago, what here we are voting for? :)
Vadim
Re: [Vote] Cocoon Advanced Control Flow
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christopher Oliver wrote:
> Sylvain Wallez wrote:
>
>> That is perfectly ok. Also, would "cocoon.parameters" make sense for
>> <map:call continuation> also ? IMO yes, as otherwise there's no means
>> to pass e.g. parts of the URI (matcher wildcards) to the continued
>> script.
>>
>> What do you think ?
>>
>> Sylvain
>>
> It's already there (as in Ovidiu's original code).
Doh ! Sorry, it's my dumb-question day :-/
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: [Vote] Cocoon Advanced Control Flow
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
> Christopher Oliver wrote:
>
>> Just to clarify: what I added was the "cocoon.parameters" property
>> that contains a map of the parameters passed from the sitemap. The
>> parameters are also passed positionally to the function as before. So
>> if you want to access a named parameter you can do this:
>> <map:call function="myFlow">
>> <map:parameter name="x" value = y"/>
>> ...
>>
>> function myFlow() {
>> var x = cocoon.parameters.x;
>> }
>>
>> The same functionality is in the original flow implementation.
>>
>> Do we want something different?
>
>
>
> That is perfectly ok. Also, would "cocoon.parameters" make sense for
> <map:call continuation> also ? IMO yes, as otherwise there's no means
> to pass e.g. parts of the URI (matcher wildcards) to the continued
> script.
>
> What do you think ?
>
> Sylvain
>
It's already there (as in Ovidiu's original code).
Chris
Re: [Vote] Cocoon Advanced Control Flow
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christopher Oliver wrote:
> Just to clarify: what I added was the "cocoon.parameters" property
> that contains a map of the parameters passed from the sitemap. The
> parameters are also passed positionally to the function as before. So
> if you want to access a named parameter you can do this:
> <map:call function="myFlow">
> <map:parameter name="x" value = y"/>
> ...
>
> function myFlow() {
> var x = cocoon.parameters.x;
> }
>
> The same functionality is in the original flow implementation.
>
> Do we want something different?
That is perfectly ok. Also, would "cocoon.parameters" make sense for
<map:call continuation> also ? IMO yes, as otherwise there's no means to
pass e.g. parts of the URI (matcher wildcards) to the continued script.
What do you think ?
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: [Vote] Cocoon Advanced Control Flow
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, July 9, 2003, at 06:03 PM, Christopher Oliver wrote:
> Just to clarify: what I added was the "cocoon.parameters" property
> that contains a map of the parameters passed from the sitemap. The
> parameters are also passed positionally to the function as before. So
> if you want to access a named parameter you can do this:
> <map:call function="myFlow">
> <map:parameter name="x" value = y"/>
> ...
>
> function myFlow() {
> var x = cocoon.parameters.x;
> }
>
>
> The same functionality is in the original flow implementation.
>
> Do we want something different?
This looks perfect!
Many thanks
regards Jeremy
Re: [Vote] Cocoon Advanced Control Flow
Posted by Christopher Oliver <re...@verizon.net>.
Just to clarify: what I added was the "cocoon.parameters" property that
contains a map of the parameters passed from the sitemap. The parameters
are also passed positionally to the function as before. So if you want
to access a named parameter you can do this:
<map:call function="myFlow">
<map:parameter name="x" value = y"/>
...
function myFlow() {
var x = cocoon.parameters.x;
}
The same functionality is in the original flow implementation.
Do we want something different?
Chris
Christopher Oliver wrote:
> Sylvain Wallez wrote:
>
>> Reinhard Pötz wrote:
>>
>> +1 on everything but [B] :
>>
>>> [B] Functions provided by scripts can be called within the sitemap
>>> using:
>>> <map:call function="[yourFunction]">
>>> <map:parameter name="x" value="y"/>[2]
>>> </map:call>
>>> There are no special restrictions where you can put
>>> it within <map:pipeline .../> (e.g. put it within action elements)
>>>
>>
>> As pointed out recently by Jeremy, <map:parameters> inside a
>> <map:call> are currently passed as positional arguments to the JS
>> function, which can be very confusing since the sitemap syntax uses
>> named parameters. Jeremy also proposed these parameters to be passed
>> as a single Map-like object to the function.
>>
>> So I'm +1 for the syntax but I'd like the parameters to be passed by
>> named.
>
>
> Uh, I already added this. Sorry, forgot to mention.
>
> Chris
>
>
Re: [Vote] Cocoon Advanced Control Flow
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christopher Oliver wrote:
> Sylvain Wallez wrote:
>
>> Reinhard Pötz wrote:
>>
>> +1 on everything but [B] :
>>
>>> [B] Functions provided by scripts can be called within the sitemap
>>> using:
>>> <map:call function="[yourFunction]">
>>> <map:parameter name="x" value="y"/>[2]
>>> </map:call>
>>> There are no special restrictions where you can put
>>> it within <map:pipeline .../> (e.g. put it within action elements)
>>>
>>
>> As pointed out recently by Jeremy, <map:parameters> inside a
>> <map:call> are currently passed as positional arguments to the JS
>> function, which can be very confusing since the sitemap syntax uses
>> named parameters. Jeremy also proposed these parameters to be passed
>> as a single Map-like object to the function.
>>
>> So I'm +1 for the syntax but I'd like the parameters to be passed by
>> named.
>
>
> Uh, I already added this. Sorry, forgot to mention.
Cool ! Thanks a lot !
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: [Vote] Cocoon Advanced Control Flow
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
> Reinhard Pötz wrote:
>
> +1 on everything but [B] :
>
>> [B] Functions provided by scripts can be called within the sitemap
>> using:
>> <map:call function="[yourFunction]">
>> <map:parameter name="x" value="y"/>[2]
>> </map:call>
>> There are no special restrictions where you can put
>> it within <map:pipeline .../> (e.g. put it within action elements)
>>
>
> As pointed out recently by Jeremy, <map:parameters> inside a
> <map:call> are currently passed as positional arguments to the JS
> function, which can be very confusing since the sitemap syntax uses
> named parameters. Jeremy also proposed these parameters to be passed
> as a single Map-like object to the function.
>
> So I'm +1 for the syntax but I'd like the parameters to be passed by
> named.
Uh, I already added this. Sorry, forgot to mention.
Chris
Re: [Vote] Cocoon Advanced Control Flow
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Reinhard Pötz wrote:
+1 on everything but [B] :
> [B] Functions provided by scripts can be called within the sitemap
> using:
>
> <map:call function="[yourFunction]">
> <map:parameter name="x" value="y"/>[2]
> </map:call>
>
> There are no special restrictions where you can put
> it within <map:pipeline .../> (e.g. put it within action elements)
>
As pointed out recently by Jeremy, <map:parameters> inside a <map:call>
are currently passed as positional arguments to the JS function, which
can be very confusing since the sitemap syntax uses named parameters.
Jeremy also proposed these parameters to be passed as a single Map-like
object to the function.
So I'm +1 for the syntax but I'd like the parameters to be passed by named.
Also, in order to ensure so that there's no hidden secret, here's what I
answered to Reinhard asking me privately about the name changes RT and
this vote :
"The discussion following the RT showed that the proposed changes can
conceptually make sense but require more thinking and some concrete code
to be widely accepted. So we won't vote on this issue now, but this
subject is very likely to come back in a more formalized form and with
actual code in the future."
And of course if such changes happen, a back-compatible behaviour will
be maintained.
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: [Vote] Cocoon Advanced Control Flow
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, July 9, 2003, at 01:37 PM, Reinhard Pötz wrote:
> I know it's a lot ;-) but I don't want a general vote on such an
> important part as the "Cocoon Advanced Control Flow" (many of us
> consider it as an equal part to sitemaps).
>
> Thank you for voting/reading so far (13 items ;-)!
>
Thanks for taking this so far ....
Sorry I am a bit behind with my reading ....
You have my +1 on all issues here.
regards Jeremy
[Vote] [Results] Cocoon Advanced Control Flow
Posted by Reinhard Pötz <re...@gmx.net>.
+1 on all issues
-------------------------------
Betrand
Chris
Jeremy
Reinhard
Steven
Sylvain (the open issue mentioned by him has already
been implemented)
Vadim
+1 NOT on all issues
-------------------------------
Stephan (voted -1 on the sitemap integration)
The result of this vote shows that the "Cocoon Advanced Control Flow"
and
the JavaScript implementation has been accepted.
** +1 for the release **
On the part *sitemap integration* we will vote based on Sylvain's and
Marc's
proposal.
The flow/session integration is investigated in a separate discussion
and
cannot be considered as accepted.
Cheers,
Reinhard
RE: [Vote] Cocoon Advanced Control Flow
Posted by Reinhard Pötz <re...@gmx.net>.
> -----Original Message-----
> From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch]
> Sent: Wednesday, July 09, 2003 6:26 PM
> To: dev@cocoon.apache.org
> Subject: Re: [Vote] Cocoon Advanced Control Flow
>
>
> > Thank you for voting/reading so far (13 items ;-)!
>
> +1 on everything - I cannot look at all the details now but I
> trust you
> guys ;-)
Thank you ;-)
There shouldn't be any surprises as we found consensus on all issues
IMO.
But as the Control Flow is a community effort a concluding vote is
necessary.
Cheers,
Reinhard
Re: [Vote] Cocoon Advanced Control Flow
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
> Thank you for voting/reading so far (13 items ;-)!
+1 on everything - I cannot look at all the details now but I trust you
guys ;-)
-Bertrand
RE: [Vote] Cocoon Advanced Control Flow
Posted by Reinhard Pötz <re...@gmx.net>.
From: Reinhard Pötz
> +------------------------------------------------------------------+
> | Cocoon Advanced Control Flow (in general) |
> +------------------------------------------------------------------+
+1 for A to G
> +------------------------------------------------------------------+
> | JavaScript Interpreter |
> +------------------------------------------------------------------+
+1 for H to M
Reinhard
Re: [Vote] Cocoon Advanced Control Flow
Posted by Stephan Michels <st...@apache.org>.
On Mon, 14 Jul 2003, Geoff Howard wrote:
> As I understand it (and intend to use it) the flow is not supposed to be
> actually performing the heavy lifting of your business logic, but
> "glue"ing it all together. You can do any transactional handling in a
> real java class which is then called by a simple flow. Does that meet
> your need?
No, it doesn't. Yes, I can write extra components which handles the
difficult stuff, and glue them together with 3 lines of JavaScript.
But at this point, the easiness of JavaScript is obsolete, and makes
the thing more difficult.
And I don't like temporary solutions like using servlet filter to
close my transaction.
But thank you ;-)
The real problem is that you have in the current Javascript implementation
an executing of a function over serveral page, which can cause timeouts
if you have open transactions, for example.
tx.begin()
sendPage(A)
tx.doSomething();
sendPage(b)
tx.doSomething();
tx.commit();
This is not good pratice, moreover it's dangerous. If you use method
between the pages, you doesn't came on the idea to write this from above.
page A
doActionA()
page B
doActionB()
doAction()
{
tx.begin
tx.doSomething();
tx.commit();
}
And also the ATCT solution not a good pratice in my eyes, because
you can also get the idea that the first snippet work.
So in POV, the best solution for me is some kind of FSM in XML,
which uses 'cut down'-Actions(without redirector), which the continuation
concept.
This will not be a problem until we decide to focus on a javascript-only
implementation.
Stephan.
> Stephan Michels wrote:
> > Hoping I'm not too late. Please interpret this not as personal attack
> > or something else. I like the idea of the flow, but the javascript
> > implementation inhibit me to take a deeper look into it.
> >
> ...
>
> >> +------------------------------------------------------------------+
> >> | JavaScript Interpreter |
> >> +------------------------------------------------------------------+
> >>
> >> [H] Our first and currently only[5] interpreter implementation is
> >> a Javascript implementation based on Mozilla Rhino which
> >> has been extended to support continuations.[6]
> >
> >
> > It just one solution. I don't like javascript, and the impression
> > that all can be handle harmless in one Javascript function is
> > dangerous, see handling transaction(hilbernate).
> >
> > I would love to see an alternative implementation.
> >
> > In my POV the flow belongs to the core, but not the javascript
> > implementation.
Re: [Vote] Cocoon Advanced Control Flow
Posted by Geoff Howard <co...@leverageweb.com>.
As I understand it (and intend to use it) the flow is not supposed to be
actually performing the heavy lifting of your business logic, but
"glue"ing it all together. You can do any transactional handling in a
real java class which is then called by a simple flow. Does that meet
your need?
Geoff
Stephan Michels wrote:
> Hoping I'm not too late. Please interpret this not as personal attack
> or something else. I like the idea of the flow, but the javascript
> implementation inhibit me to take a deeper look into it.
>
...
>> +------------------------------------------------------------------+
>> | JavaScript Interpreter |
>> +------------------------------------------------------------------+
>>
>> [H] Our first and currently only[5] interpreter implementation is
>> a Javascript implementation based on Mozilla Rhino which
>> has been extended to support continuations.[6]
>
>
> It just one solution. I don't like javascript, and the impression
> that all can be handle harmless in one Javascript function is
> dangerous, see handling transaction(hilbernate).
>
> I would love to see an alternative implementation.
>
> In my POV the flow belongs to the core, but not the javascript
> implementation.
>
RE: [Vote] Cocoon Advanced Control Flow
Posted by Reinhard Pötz <re...@gmx.net>.
From: Stephan Michels [mailto:stephan@apache.org]
> Hoping I'm not too late. Please interpret this not as
> personal attack or something else.
No I don't - all those issues are not my personal opinion but the
sum of more than two years of discussion, design and implementation.
> I like the idea of the
> flow, but the javascript implementation inhibit me to take a
> deeper look into it.
Maybe the "balkanization" discussion triggered by Stefano is
of some interest for you and you may contribute to it.
Cheers,
Reinhard
Re: [Vote] Cocoon Advanced Control Flow
Posted by Stephan Michels <st...@apache.org>.
Hoping I'm not too late. Please interpret this not as personal attack
or something else. I like the idea of the flow, but the javascript
implementation inhibit me to take a deeper look into it.
> +------------------------------------------------------------------+
> | Cocoon Advanced Control Flow (in general) |
> +------------------------------------------------------------------+
>
>
> [A] The "Cocoon Advanced Control Flow" provides a controller that is
> linked into the sitemap (as child element of <map:sitemap .../>:
>
> <map:flow language="[yourLanguage]">
> <map:script src="script_1"/>
> <map:script src="script_2"/>
> <map:script src="script_..."/>
> <map:script src="script_n"/>
> </map:flow>
-1, because it leaves the impression that the flow must be a script.
Alternative, I would prefer
<map:flows language="[yourLanguage]">
<map:flow src="script_1"/>
<map:flow src="script_2"/>
<map:flow src="script_..."/>
<map:flow src="script_n"/>
</map:flows>
Just like generators and generator
> [B] Functions provided by scripts can be called within the sitemap
> using:
>
> <map:call function="[yourFunction]">
> <map:parameter name="x" value="y"/>[2]
> </map:call>
Again -1, functions are one way to implement a flow, see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105732879827785&w=2
Perhaps <map:start continuation="[yourFunction]">
>
> [C] If a script provides continuations to continue
> they are called within the sitemap using:
>
> <map:call continuation="[continuation-id]"/>
<map:continue id="[continuation-id]"/> is for my opinion a better
solution.
>
> [D] All flow interpreters[3] are Avalon components and declared
> in the cocoon.xonf:
>
> <flow-interpreters default="[yourLanguage]" logger="[yourLogger]">
> ...
> </flow-interpreters>
+1
> [E] All interpreters have to implement the Flow Object Model [FOM][4]
> as far as possible but *must not* extend it without prior vote.
> They also have to support all "FOM-aware" components (e.g.
> JXTemplateGenerator/Transformer)
-1, I think our users are adult enough to decide, what they should use
and what not. To get the full access to request/response/session and cm
etc. seems to be harmless for me.
> [F] FOM contains following objects:
>
> * cocoon
> * request
> * response
> * session
> * cookie
> * log
> * context
> * continuation
+0
> [G] The FOM does not grant access to actions and input modules
> but the flow interpreter *can* provide support for it but must not
> give them the appearence of "first-class-Cocoon-citizens".
-0
> +------------------------------------------------------------------+
> | JavaScript Interpreter |
> +------------------------------------------------------------------+
>
> [H] Our first and currently only[5] interpreter implementation is
> a Javascript implementation based on Mozilla Rhino which
> has been extended to support continuations.[6]
It just one solution. I don't like javascript, and the impression
that all can be handle harmless in one Javascript function is
dangerous, see handling transaction(hilbernate).
I would love to see an alternative implementation.
In my POV the flow belongs to the core, but not the javascript
implementation.
> [I] This JavaScript implementation is declared in the cocoon.xconf:
>
> <flow-interpreters default="JavaScript" logger="flow">
> <component-instance name="JavaScript"
> class="org.apache.cocoon.components.flow.javascript.
> fom.FOM_JavaScriptInterpreter">
> <load-on-startup>resource://org/apache/cocoon/components/
> flow/javascript/fom/fom_system.js</load-on-startup>
> <reload-scripts>true</reload-scripts>
> <check-time>4000</check-time>
> <!--<debugger>enabled</debugger> -->
> </component-instance>
> </flow-interpreters>
+1
> [J] Flows and sessions:
>
> (i) A flow script does not create a session automatically.
> Accessing the session object (is a property of the cocoon
> object) leads to the creation of a session if no session
> is available.
>
> (ii) The global scope of a flow only lives as long as the session
>
> which the flow is tied to is active.
> So if the session expires or you use another client to
> continue a 'waiting' function you only have access to the
> local scope within the flow function.
>
> (iii) All scripts within a <map:script>...></> part share the
> same global context. If you want to share more objects
> you need another scope (request, session, context).
+1
> [K] Behaviour of variables within the flow:
> All variables within the flow scripts are shared by reference
> over continuations.
+1
> [L] A continuations manager based on the excalibur-event packages
> is responsible for the expiration of continuations. It is
> declared in the cocoon.xconf:
>
> <continuations-manager logger="flow" time-to-live="3600000">
> <expirations-check type="periodic">
> <offset>[timeInMs]</offset>
> <period>[timeInMs]</period>
> </expirations-check>
> </continuations-manager>
+1
> [M] Getting and releasing of components has to be done explicitly
> by the flow script programmer using:[7]
>
> cocoon.getComponent( id );
> cocoon.releaseComponent( component );
+1
Stephan.