Postback/form resubmission detection

[alpheratz-jb]

This is probably a FAQ but here goes anyway.

Consider a very simple app (PURE JSF, no pageflows, etc): 1 home page that kicks off to a form that, on successful submission returns to the home page (which redisplays the--now updated--data).

Consider: the user now hits the browser back button and resubmits the data.

The question is...how to handle this in Seam?

I guess that the ultimate answer would be to move to Seam's pageflow mechanism...I have read sect. 4.1.2, etc. and I agreee that for a bigger app, this is the way to go, but for the very simple situation I have here it isn't really worth it.

EXCEPT that I can't get a clear feeling for any alternative.

For example:

http://www.jroller.com/page/cagataycivici/weblog/ispostback_in_jsf

Presents what looks to be a promising solution but to quote: "I just realized that requestParamMap trick won't work when a navigation happens without a redirect. It does not always works."

I read in 4.1.2 that "However, our experience is that in the context of Seam, where there is a well-defined conversational model, backed by stateful session beans, it is actually quite straightforward. Usually it is as simple as combining the use of the @Conversational annotation with null checks at the beginning of action listener methods. We consider support for freeform navigation to be almost always desirable."

Is there an example of this to look at?

I would love some guidance here! I am making no real headway.

On a more high-level note: this seems such a simple thing (and was in struts: saveToken(), etc. [but it nonetheless felt 'unsatisfactory']) Shale has an equivalent s:token tag but that again seems much too low-level for Seam. From my googling for a solution, it would seem that Seam could really help the average Joe Programmer if it implemented a simple solution. My AU$0.02 worth (I'm up in sunny Bribane, Oz).

Thanks in advance! All help is really gratefully appreciated.

[gavin.king]

If you do the work in a long-running conversation, and then end that conversation when redirecting back to the home page, then Seam automagically detects that the conversation is over when the form is resubmitted.

It Just Works.

Try this out in the booking demo.

[alpheratz-jb]

It Just Works.

It sure does! MANY thanks...it is coming together for me now!

My (poor longsuffering) wife just heard me exclaim "Gavin, you genious!"

I LIKE this feature (now I understand it, of course...)

This is exactly what I mean by "simple solution" and "a high-level note".

When I evaluate a framework, I am looking for "added value", or more "bang for buck." This feature just did it for me ;-)

I have been looking at apache shale (didn't seem enough of a "leap forward"); spring (I just LOVE the way that people are saying that EJB2.x descriptors are too complex, and then wading into spring's morasses of XML configuration; easier testability is nice, though) and Seam....Seam "felt right" to me, in terms of making proper use of the latest and greatest, but I couldn't see my way through.

So: many thanks. This is Good Work.

Alph.

[gavin.king]

Cheers ;-)

P.S. I think you'll like Seam 1.1 even better, when it finally gets born...

[alpheratz-jb]

Looking forward to 1.1! Already like <s:decorate>...

Any suggestions to how to handle the UI aspects of postback.

At the moment, I can use <h:messages /> to display "No conversation" at the bottom of the page but I'd like to be able to display something nicer. I guess also I'd like to be able to display a friendlier message against a field (say the first on the page, for argument's sake).

Cheers,

Alph

[gavin.king]

You can use the <s:message/> tag with <s:decorate/>, just like in the updated booking example in CVS, or just use <h:message for="inputId"/>.

Or isn't that what you are asking?

[alpheratz-jb]

I haven't yet actually tried the <s:*> tags YET.

I have <h:message for=""> with my input elements and <h:messages> in the page body...

When I do a back-button/resubmit, I see no messages against any input element and only "No conversation" from the <h:messages> tag.

I guess that the "you are not in a conversation" situation does not occur due to a validation error and so is not 'for' any input element...

As an aside, in the JBoss log, I see:

[ConversationInterceptor] no long-running conversation for @Conversational bean: disasterManager

This is good.

The issue is how to make this situation more 'beautiful' for the user...can I hook into things somewhere so that I can present a more user-oriented message like "please don't do back/submit...you dolt" ;-)

Cheers,

Alph

[gavin.king]

Just set org.jboss.seam.NoConversation=..... in your messages.properties file.

[alpheratz-jb]

Sigh. Nothing is ever easy, eh!

I get:

===

javax.servlet.ServletException: could not instantiate ClassValidator
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:121)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)

...

at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Unknown Source)
18:22:05,562 INFO [SeamExceptionFilter] killing transaction
18:22:05,562 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception
java.lang.IllegalArgumentException: could not instantiate ClassValidator
at org.hibernate.validator.ClassValidator.createValidator(ClassValidator.java:265)
at org.hibernate.validator.ClassValidator.createMemberValidator(ClassValidator.java:233)
at org.hibernate.validator.ClassValidator.initValidator(ClassValidator.java:176)

...

at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Unknown Source)
Caused by: java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key validator.length
at java.util.ResourceBundle.getObject(Unknown Source)
at java.util.ResourceBundle.getString(Unknown Source)
at org.hibernate.validator.ClassValidator.replace(ClassValidator.java:518)
at org.hibernate.validator.ClassValidator.createValidator(ClassValidator.java:260)
... 46 more

===

I saw this:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3928305

Is this still an issue...should I go to the shiny new version in CVS (planning to give it a try anyhow...)

Cheers,

Alph

[alpheratz-jb]

current workaround is to copy default messageset from

org.hibernate.validator.resources.DefaultValidatorMessages.properties

Then...its like a bought one!

Still...I'll have to give CVS version a try.

Alph