what is your reason, that you want to persist the enity in the validation event?
i think its more clear to persist it in the onSuccess event method with regards Sven Homburg Founder of the Chenille Kit Project http://www.chenillekit.org 2009/9/11 Bruno Santos <bitbet...@gmail.com> > Thanks for your answer, i learned a bit more of tapestry. > > Now i have one more problem, not exactly related but in the same area. > > I have > > void onValidateForm() { > if (entity.getId().longValue() == 0l) { > league.setId(null); > } > > System.out.println("OnValidateForm"); > try { > _entityDAO.persist(entity); > } catch (RuntimeException ex) { > leagueForm.recordError("error"); // EXCEPTION IS > THROWN - THE TEST > I'M DOING HITS THE UNIQUE CONSTRAINT > } > > } > > void onFailure() { > _entityDAO.abort(); > System.out.println("onFailure"); > } > > And this is working except it doesn't refresh the form with the errors > i added on the onValidate > > When i use: > > Object onFailure() { > _entityDAO.abort(); > System.out.println("onFailure"); > return this; > } > > The following exception is thrown: > > Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException: > null id in pt.hi.asianconnect.entities.League entry (don't flush the > Session after an exception occurs) [at > classpath:pt/hi/asianconnect/components/generated/CreateUpdateLeague.tml, > line 12] > at > org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:62) > at > org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.read(InternalComponentResourcesImpl.java:510) > ... 119 more > Caused by: org.hibernate.AssertionFailure: null id in > pt.hi.asianconnect.entities.League entry (don't flush the Session > after an exception occurs) > at > org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:78) > at > org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187) > at > org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143) > at > org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219) > at > org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99) > at > org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58) > at > org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996) > at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1589) > at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306) > at DefaultHibernateDAO.findByCriteria(DefaultHibernateDAO.java:104) > > > The abort method from DAO was an experiment of mine wich calls > hibernatesessionmanager.abort(). From what i understand, what happens > is when the page is to be renderered, the hibernatesessionmanager > that's used has "dirty" data that's why it uses > SessionImpl.autoFlushIfRequired when i'm fetching data to refill the > page, hence my experiment on calling the abort from > hibernatesessionmanger, still this doesn't do it and i don't know how > to "clean" data from the sessionmanager. > > Ideas anyone? > > One importante note, the test i'm doing implies that the my method > that saveOrUpdate the entity is "hitting" a unique constraint > > On Thu, Sep 10, 2009 at 11:20 PM, Kalle Korhonen > <kalle.o.korho...@gmail.com> wrote: > > You should instead try storing it onValidate. If it fails, you should > > record an error and if it succeeds you should commit only in onSuccess > > (but the method body can be otherwise empty). > > > > Kalle > > > > > > On Thu, Sep 10, 2009 at 2:55 PM, Bruno Santos <bitbet...@gmail.com> > wrote: > >> Good evening, > >> > >> I have a form using a zone and i have @CommitAfter on the > >> onSubmitFromEntityForm() > >> > >> <t:form t:id="entityForm" zone="entityZone"> > >> <input type="text" t:type="textfield" t:id="name" > >> t:value="entity.name" /> > >> </t:form> > >> > >> @CommitAfter > >> Object onSubmitFromEntityForm() { > >> .... > >> try { > >> entityDao.persist(entity); > >> } catch (exception ex) { > >> // handle exception > >> } > >> } > >> > >> altough i'm handling the exception the @CommitAfter creates a new > >> exception since it tries to commit something that's not in transaction > >> due to catched exception. > >> > >> How to deal with this? Is there a way to avoid the @CommitAfter to > >> execute ... a handler i can use? I think i can remove the @CommitAfter > >> but don't believe this should be first option. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: users-h...@tapestry.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
