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
Why is the params-prepare-params not in the default stack / behavior
already? I think one of the first things S2 gets really useful at is the
params / prepare stuff and a LOT of people keeps asking the same
question, and getting the same answer "use the params-prepare-params
stack". Any reasons
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
It does if you use the prepare params prepare stack.
On Tuesday, October 12, 2010, cellterry wrote:
>
> At Preparable timing it does not have the customer data (customer=null) so
> that I cannot retrieve warehouse information by customer ID.
>
> Terry.
>
>
> Dave Newton-6 wrote:
>>
>> Ugh, implem
At Preparable timing it does not have the customer data (customer=null) so
that I cannot retrieve warehouse information by customer ID.
Terry.
Dave Newton-6 wrote:
>
> Ugh, implementing Prepareable seems more palatable to me than throwing
> the same logic into somethingnthat returns the inputn
Ugh, implementing Prepareable seems more palatable to me than throwing
the same logic into somethingnthat returns the inputnresult name.
Dave
On Tuesday, October 12, 2010, cellterry wrote:
>
> Thank you.
>
> This helps to solve the problem,, Li Ying.
>
> Terry.
>
>
> Li Ying-2 wrote:
>>
>> Hi ce
Thank you.
This helps to solve the problem,, Li Ying.
Terry.
Li Ying-2 wrote:
>
> 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
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
13 matches
Mail list logo
