Hi Dave:
Thank you very much for your suggestion.
I'd like to discuss a little more about this issue. Hope it don't bother you.
Let's think about a situation which i think it is very common in web app.
1, We need a page to insert/modify our data.
2, We need to display the input page, and
Trying to wedge all functionality into a single action will eventually
lead to problems, and/or hacks.
And interceptor stacks are *designed* to be customized: that's their
point. That's where application-wide behavior is supposed to live...
Not that a custom prepare interceptor is difficult, as
/Master-details-JSP-with-Validation-xml-tp29940574p29942596.html
Sent from the Struts - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h
On Wed, Oct 13, 2010 at 12:44 AM, Li Ying wrote:
But, in some case, the data loading logic need to access the
parameters value to know what data should be loaded.
And, unfortunately, the interceptor [prepare] is configured
before interceptor [params] in the default interceptor stack.
see:
would adopt to use the second one.
Please advise! Thanks!
Terry.
--
View this message in context:
http://old.nabble.com/Master-details-JSP-with-Validation-xml-tp29940574p29940574.html
Sent from the Struts - User mailing list archive at Nabble.com
Hi,
since your customer's data are in session, i think you can use the
session scope to display these data for the warehouses. Otherwise, you
can also use hidden fields for warehouses data to simulate an input but
don't use these data in your action if your use case is not meant to
update
Hi cellterry:
I think your problem is very general.
What you need is a chance to reload some data, when the
validation get failed and the page is displayed again.
I think this document can help you:
http://struts.apache.org/2.2.1/docs/inputconfig-annotation.html
Another solution is:
1, Implement interface [ValidationWorkflowAware] in your Action class
2, In method [getInputResultName], you can load all the data you need,
and then, return constant [INPUT] as the result name.
Actually, In my application, I am using this solution in a little different
By the way, you can read source code of
[com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor] to
see how these 2 solutions get work.
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands,
:
http://old.nabble.com/Master-details-JSP-with-Validation-xml-tp29940574p29942596.html
Sent from the Struts - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
--
View this message in context:
http://old.nabble.com/Master-details-JSP-with-Validation-xml-tp29940574p29942596.html
Sent
commands, e-mail: user-h...@struts.apache.org
--
View this message in context:
http://old.nabble.com/Master-details-JSP-with-Validation-xml-tp29940574p29942596.html
Sent from the Struts - User mailing list archive at Nabble.com
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
--
View this message in context:
http://old.nabble.com/Master-details-JSP-with-Validation-xml-tp29940574p29942596.html
Sent
Interface [Preparable] is another choice to implement
the data loading logic.
But, in some case, the data loading logic need to access the
parameters value to know what data should be loaded.
And, unfortunately, the interceptor [prepare] is configured
before interceptor [params] in the default
14 matches
Mail list logo
