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 me
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 inser
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.
>
> s
ocs/inputconfig-annotation.html
-
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
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 int
;>
>>>> -----------------
>>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>>>> For additional commands, e-mail: user-h...@struts.apache.org
>>>>
>>>>
>>>&
ruts.apache.org/2.2.1/docs/inputconfig-annotation.html
>>>
>>> -
>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>>> For additional commands, e-mail: user-h...@struts.apache.org
>>
can help you:
>> http://struts.apache.org/2.2.1/docs/inputconfig-annotation.html
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> For additional commands, e-mail: user-h...@struts.apache.org
@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 unsubscr
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,
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 w
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
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 th
robust, but if it is
impossible I 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
14 matches
Mail list logo