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 insert/modify DB record when user submit data in this page. We decide to implement both of this 2 process in one Action so we can reuse code better. There are a [execute] method which will [display the input page], and a [save] method which will [insert/modify DB record]. 3, Before [display the input page], we need load some data which will used by the page. For example, option list used by select tag and so on. We implement this process in method [loadData]. 4, Before the [save] method can be executed, we must validate the data input by user. If it is not good, we must [display the input page] again, and of cause, call the method [loadData] again. 5, If the validation before [save] method has no error, we should go on to execute [save] method, but no need to execute [loadData] again. 6, Here come the problem: if we use [paramsPrepareParams] stack as you suggested, (a) the [loadData] process will be executed all the time, even there is no validation error and no need to display the input page again. I think it is not good because the unnecessary code is executed. (b) the [prepare] interceptor is executed BEFORE [validation] interceptor. That means, when [loadData] get executed, we can not check if there are errors or not. (c) in [paramsPrepareParams] stack, the [params] interceptor looks like be executed twice, and it not very good for performance, so i don't think it is a very elegant solution. 7, If we use the 2nd solution you suggested, to implement our own interceptor, we have to: (a)check if there are errors in Action (b)if there are, call [loadData] and return to the input page (c)if there are not error, proceed the execution of action. (d)insert this interceptor into somewhere middle of the interceptor stack provided by Struts2. But these are exactly what [workflow] interceptor is doing. Why should i implement the same thing by my self? So my solution is (as i described in the earlier mail): 1, Implement [ValidationWorkflowAware] interface 2, The [workflow] interceptor will call my method back, only if there are errors. And we don't have to change the interceptor stack, this make it easier to upgrade to a new version of Struts in the future. 2010/10/13 Dave Newton <davelnew...@gmail.com>: > 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: [defaultStack] in this page: >> >> http://struts.apache.org/2.2.1/docs/interceptors.html#Interceptors-TheDefaultConfiguration > > > I'm aware of the default configuration. > > There are two options: use the existing prepareParamsPrepare stack, which > you'll find if you read the entirety of the page you've linked to, or define > your own interceptor stack that implements the functionality your > application requires. > > I think this is inconvenient for me. >> > > This is why (a) the other interceptor stack comes pre-defined, and (b) a > trivial way of implementing custom functionality is provided. > > Dave > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
