You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by JD Daniels <jd...@datatrio.com> on 2003/07/10 09:37:35 UTC
Flow Database stuff ( The new FOM? )
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: 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