Re: T5: Tapestry-Hibernate, do we have to save()?
On Nov 22, 2007 1:20 PM, Massimo Lusetti [EMAIL PROTECTED] wrote: On Nov 22, 2007 8:37 AM, lasitha [EMAIL PROTECTED] wrote: A follow up for anyone keeping score: i've just verified that hibernate does _not_ automatically flush a Session when it is closed. If anyone is interested i can pass along my learning test. That's clearly written in the API. Hmm, i must've missed where this was documented. The api certainly doesn't mention anything about flushing on close, but i was uncomfortable assuming this, particularly since earlier versions of hibernate _did_ flush on close, if i recall. In any case, my apologies for any unnecessary clutter. lasitha. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Tapestry-Hibernate, do we have to save()?
On Nov 22, 2007 9:02 AM, lasitha [EMAIL PROTECTED] wrote: Hmm, i must've missed where this was documented. The api certainly doesn't mention anything about flushing on close, but i was uncomfortable assuming this, particularly since earlier versions of hibernate _did_ flush on close, if i recall. Force this session to flush. Must be called at the end of a unit of work, before commiting the transaction and closing the session (depending on flush-mode, Transaction.commit() calls this method). Taken from Session.flush() API from http://www.hibernate.org/hib_docs/v3/api/ Regards -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Tapestry-Hibernate, do we have to save()?
Hello Yunhua, Depends on why do you have it :) Most probably you just store the object you've got from Hibernate in the session and since every object associated with persistent context (it's actually a JPA term, but it is very well defined therefore we can use it for Hibernate env. also) has a reference to already closed session you might be having this exception. There are multiple consideration need to be taken into account, first is you might be interesting in storing object in the session and let user edit it over multiple pages, in this case you would better use detach/attach strategy (as was already mentioned in this thread), but please take care that you have an optimistic concurrency control in place (every object has a version in it and versions are checked by hibernate in case two users have conflicting changes). With this solution we are going to the area of emulating long transactions and different session management patterns for Hibernate (google for long-living session). Another use case is when it's just simpler to store object in the session therefore you might just considering storing primary key of the object and then fetch it from the Hibernate every time page is loaded, this will potentially require shorter transactions (entity is loaded, modified and saved during one request). One very elegant way to do that in T4 was DataSquezers, they can generally encode any hibernate entity to it's primary key automatically and then restore it during the next request (you can check Honeycomb for that), also as far as I remember Honeycomb also had a feature that in case hibernate entity is stored in session by Tapestry then it is also doing all kind of conversion on it also (but I'm not sure wherever it works, check honeycomb). Renat On 21/11/2007, Yunhua Sang [EMAIL PROTECTED] wrote: Hi Renat, Do you have some good ideas to prevent LazyInitializationException be thrown out after form submitting? My current solution looks not smart: explicitly call collection.size() in the first thread. Thanks Yunhua On Nov 21, 2007 9:54 AM, Renat Zubairov [EMAIL PROTECTED] wrote: There is a simpler solution that works is to rollback the DB transaction in case validation fails. So we are actually get a transaction from the Hibernate session and roll it back therefore no changes are efficient in the session. There is not very flexible solution but works for simpler cases. There are different solution, e.g. working on detached objects or clearing session. Renat On 30/10/2007, Maximilian Weißböck [EMAIL PROTECTED] wrote: Oh yes, this is really a problem we actually had in a Tapestry 4 Application. We had to use (ugly) DTO Objects to avoid this problem. As far as I can remember, this problem is addressed in JSF with its complex render cycle. Values are stored in intermediate objects until validation is completed and only then are copied to the bean data object. Would be interesting if there could be a similar soultion for T5? Max -Ursprüngliche Nachricht- Von: lasitha [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 30. Oktober 2007 15:29 An: Tapestry users Betreff: Re: T5: Tapestry-Hibernate, do we have to save()? On 10/30/07, Angelo Chen [EMAIL PROTECTED] wrote: is this really needed? I got confused, why the changes are saved without calling _session.save()? Angelo, this is default hibernate behaviour. See: http://www.hibernate.org/hib_docs/v3/reference/en/html/objects tate.html#objectstate-modifying However, your post brings up an interesting question: will the object's state be persisted even after validation fails? My first guess is might actually be a problem. Consider: 1. Object is retrieved in onAttached() and associated with a new session, 2. Fields are updated with values from the form submission (lets assume they are valid), 3. Some cross-validation fails in onValidate() - so onSuccess() is never called, but... 4. As the thread cleans up, the HibernateSessionManager commits the transaction anyway and the invalid values are persisted! I'd like to test this and look around the lists a bit but am throwing this out in case others have thoughts. Cheers, lasitha. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Renat Zubairov - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Renat Zubairov
unsubscribe
hello, I tried the bot [EMAIL PROTECTED] but for some reason the confirmation reply is not working.Can any admin remove me from User, Dev and Commit Lists?Thanks in advance, []s - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5 - validation of composite components
I have a problem implementing proper validation of composite components. Assume I have a component consisting of two text fields. For validation, I need to consider the contents of both. The way I understand validation, it works thusly: 1. All fields within a form are asked by the form to pull their values out of the incoming request and validate these values (each validating its own value) 2. Form emits a validate() event which is propagate UPWARDS in the component hierarchy. Therefore, my composite component gets notified to pull its values out of the incoming request (which it can't, but its text fields will do), but never sees the validate() event, as it is within the form and thus below it in the component hierarchy. So, in effect, each text field can validate its own value, and anything above the form can validate the component, but the component cannot validate itself. Is that correct? What am I missing? Is there a way to get a validate event trigger in a component once the child components have restored their values and have validated themselves? Thanks, Markus -- View this message in context: http://www.nabble.com/T5---validation-of-composite-components-tf4855742.html#a13894911 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Tapestry-Hibernate, do we have to save()?
Hi Renat,
Thanks a lot for your explain. However, my question is what' is the
elegant way to prevent
potential LazyInitializationException when Tapestry5 processing form
submitting, since action request and render request are in 2 different
threads now, thus the hibernate Sessions in 2 requests should be
different instances.
For instance:
I have a class called People:
People {
String firstname;
@lazyLoading Set addresses;
}
Page1 {
@Inject Session session;
@Persist People people;
onSubmitFromForm1 {
session.save(people);
// people.getAddresses().size();
}
}
Steps:
1. edit a people' firstname in Page1, It's possible I don't need to
show address here, so get Addresses() is NOT called,
2. I submit the form, modify firstname, save people.
3. I render people (already be detached) in page1 again WITH address
info, i.e. call getAddresses(); here LazyInitializationException
happens. because the hibernate session for step 2 has been closed. my
solutions is to call people.getAddresses().size() explicitly to force
the lazyloading set be opened in step2, but I don't think this is a
good way.
I knew merge() or refresh() both work, but where should I call them?
in beginRender()? sounds not good.
Any suggestion?
Thanks
Richard
On Nov 22, 2007 4:37 AM, Renat Zubairov [EMAIL PROTECTED] wrote:
Hello Yunhua,
Depends on why do you have it :) Most probably you just store the object
you've got from Hibernate in the session and since every object associated
with persistent context (it's actually a JPA term, but it is very well
defined therefore we can use it for Hibernate env. also) has a reference to
already closed session you might be having this exception.
There are multiple consideration need to be taken into account, first is you
might be interesting in storing object in the session and let user edit it
over multiple pages, in this case you would better use detach/attach
strategy (as was already mentioned in this thread), but please take care
that you have an optimistic concurrency control in place (every object has a
version in it and versions are checked by hibernate in case two users have
conflicting changes). With this solution we are going to the area of
emulating long transactions and different session management patterns for
Hibernate (google for long-living session).
Another use case is when it's just simpler to store object in the session
therefore you might just considering storing primary key of the object and
then fetch it from the Hibernate every time page is loaded, this will
potentially require shorter transactions (entity is loaded, modified and
saved during one request). One very elegant way to do that in T4 was
DataSquezers, they can generally encode any hibernate entity to it's
primary key automatically and then restore it during the next request (you
can check Honeycomb for that), also as far as I remember Honeycomb also had
a feature that in case hibernate entity is stored in session by Tapestry
then it is also doing all kind of conversion on it also (but I'm not sure
wherever it works, check honeycomb).
Renat
On 21/11/2007, Yunhua Sang [EMAIL PROTECTED] wrote:
Hi Renat,
Do you have some good ideas to prevent LazyInitializationException be
thrown out after form submitting? My current solution looks not smart:
explicitly call collection.size() in the first thread.
Thanks
Yunhua
On Nov 21, 2007 9:54 AM, Renat Zubairov [EMAIL PROTECTED] wrote:
There is a simpler solution that works is to rollback the DB transaction
in
case validation fails. So we are actually get a transaction from the
Hibernate session and roll it back therefore no changes are efficient in
the
session.
There is not very flexible solution but works for simpler cases.
There are different solution, e.g. working on detached objects or
clearing
session.
Renat
On 30/10/2007, Maximilian Weißböck [EMAIL PROTECTED]
wrote:
Oh yes, this is really a problem we actually had in a Tapestry 4
Application. We had to use (ugly) DTO Objects to avoid this problem.
As far as I can remember, this problem is addressed in JSF with its
complex
render cycle. Values are stored in intermediate objects until
validation is completed and only then are copied to the bean data
object.
Would be interesting if there could be a similar soultion for T5?
Max
-Ursprüngliche Nachricht-
Von: lasitha [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 30. Oktober 2007 15:29
An: Tapestry users
Betreff: Re: T5: Tapestry-Hibernate, do we have to save()?
On 10/30/07, Angelo Chen [EMAIL PROTECTED] wrote:
is this really needed? I got confused, why the changes are
saved without
calling _session.save()?
Angelo, this is default hibernate behaviour. See:
http://www.hibernate.org/hib_docs/v3/reference/en/html/objects
Re: [T5] Request.isXHR() issue
Adam Ayres wrote: There appears to be a small bug with the Request.isXHR() method, the value of the X-Requested-With header that Prototype sets by default for all of its AJAX calls is: XMLHttpRequest Tapestry checks against the value: XmlHttpRequest The RequestImplTest has the header value hard coded incorrectly explaining the test passing. I am happy to log an issue for this if that is helpful. As an aside we have been using AJAX in Tapestry 5 and have found it very easy and very easy and powerful! Thanks, Adam i'm using jquery and today hit the same problem X-Requested-With : XMLHttpRequest - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with not-showing-property in BeanEditorForm
Hi, I have a BeanEditForm with a property whose presentation I want to override, because being a class I wrote myself it cannot be rendered by default. t:beaneditform submitlabel=message:submit-label object=project remove=ID t:parameter name=customer t:select id=customer model=customerList encoder=customerList value=project.customer/ /t:parameter /t:beaneditform customer is an instance of the class Organisation, property of project. customerList is an instance of the class GenericSelectModel as shown here: http://wiki.apache.org/tapestry/Tapestry5HowtoSelectWithObjects The problem seems to be that the BeanEditForm excludes the property customer from start because it doesn't know how to render it. If I try to override the presentation of another property, this other property will be overwritten with the correct content. How can I solve this? Is there any way to tell the BeanEditForm not to remove the customer-Property? Regard, Tobias Wehrum - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Tapestry-Hibernate, do we have to save()?
On Nov 22, 2007 6:27 PM, Yunhua Sang [EMAIL PROTECTED] wrote: ... Steps: 1. edit a people' firstname in Page1, It's possible I don't need to show address here, so get Addresses() is NOT called, 2. I submit the form, modify firstname, save people. 3. I render people (already be detached) in page1 again WITH address info, i.e. call getAddresses(); here LazyInitializationException happens ... I knew merge() or refresh() both work, but where should I call them? in beginRender()? sounds not good. Hello Richard, Where are you loading People? That same place may a good place to start. onActivate(), pageAttached() or onPrepare() seem like good candidates; it sort of depends on the composition of your page and the complexity of events it encounters. The first is often not ideal because it can be called numerous times within a single request (when contained component events bubble up). Since the above events fire on both the original request and the one from the redirect, you'll probably need a null check to differentiate: load from db if null, attach to current session if not. Also, consider using Session.lock(with LockMode.NONE)[1] instead of merge() or refresh(). I don't know when it became fashionable to use merge(), but it essentially gives you a whole new instance and you have to be careful to discard the old one[2]. refresh() has the benefit of rereading state from the db, but if you think the underlying data might change between the save and redirect you should probably lock with LockMode.READ and handle the version check failure. Lastly, i must admit that i usually just reload the object from the db instead of @Persist-ing it. It's just less hassle and has rarely been too slow. Oh, and if you do stay with @Persist, consider using flash persistence instead of the default. Cheers, lasitha. Notes: [1] http://www.hibernate.org/hib_docs/core/api/org/hibernate/Session.html#lock(java.lang.Object,%20org.hibernate.LockMode) [2] merge() does have the advantage of allowing you to call it after modifying the entity, but if you can attach the entities early in the request you're more likely to get the most out of hibernate's dirty checking mechanism. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 - validation of composite components
I havn't tried this, but I think it will work. If your composite component inherits AbstractField, you could override processSubmission() method to do your own validation. Actually, this is how TextField component do the validation. Cheers, Jeffrey Ai Markus Fischer wrote: I have a problem implementing proper validation of composite components. Assume I have a component consisting of two text fields. For validation, I need to consider the contents of both. The way I understand validation, it works thusly: 1. All fields within a form are asked by the form to pull their values out of the incoming request and validate these values (each validating its own value) 2. Form emits a validate() event which is propagate UPWARDS in the component hierarchy. Therefore, my composite component gets notified to pull its values out of the incoming request (which it can't, but its text fields will do), but never sees the validate() event, as it is within the form and thus below it in the component hierarchy. So, in effect, each text field can validate its own value, and anything above the form can validate the component, but the component cannot validate itself. Is that correct? What am I missing? Is there a way to get a validate event trigger in a component once the child components have restored their values and have validated themselves? Thanks, Markus -- View this message in context: http://www.nabble.com/T5---validation-of-composite-components-tf4855742.html#a13900445 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tapestry 4.1 -- Asynchronous request with confirm
Hi:
I would like to build a @DirectLink which made the request in an
asynchronous way but request the client with a javascript confirmation
dialog before the AJAX request. I have tried to make something like:
a jwcid=@DirectLink listener=listener:doDeleteMedium
parameters=ognl:medium.id
async=ognl:true
updateComponents=mediumList
onclick=javascript:return window.confirm('Está seguro que
desea borrar este medio?');span key=delete//a
But it didn't work. Even if I click on OK or Cancel the AJAX action
takes place.
Some help please?
Thanks,
Abel.
signature.asc
Description: This is a digitally signed message part
Re: T5: Tapestry-Hibernate, do we have to save()?
Hi Lasitha, good practice to follow, thanks. can you explain more about about this null check, any example why we have to check? thanks. lasitha wrote: On Nov 22, 2007 6:27 PM, Yunhua Sang [EMAIL PROTECTED] wrote: Since the above events fire on both the original request and the one from the redirect, you'll probably need a null check to differentiate: load from db if null, attach to current session if not. Lastly, i must admit that i usually just reload the object from the db instead of @Persist-ing it. It's just less hassle and has rarely been too slow. Oh, and if you do stay with @Persist, consider using flash persistence instead of the default. Cheers, lasitha. -- View this message in context: http://www.nabble.com/T5%3A-Tapestry-Hibernate%2C-do-we-have-to-save%28%29--tf4718363.html#a13904685 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[T5] A Hibernate question?
I use tapestry-hibernate in my apps,
in one page:
t:grid source=pageList row=page2
t:parameter name=pageIdcell
t:actionLink id=pageDelete context=${page2.pageId}删除/t:actionLink
t:pageLink page=sysadm/editpage context=${page2.pageId}更新/t:pageLink
/t:parameter
/t:grid
in editpage.java
void onActivate(String id) {
page = (Page) session.createCriteria(Page.class).add(
Restrictions.eq(pageId, id)).uniqueResult();
}
void onSuccess() {
session.saveOrUpdate(page);
}
when i submit the editpage, i got a error:
Illegal attempt to associate a collection with two open sessions
...
anyone helps?
