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 method-level examples of interceptor functionally already exist in validate. Making a method do something other than its intended purpose is less readable, and more misleading: its name is no longer accurate, and you *must* read either the function, its documentation, or both, in order to understand the action's flow. Its functionality that lives outside the framework or a framework extension. YMMV, but I think it's counter-intuitive and doesn't make good use of the flexibility the framework provides. Dave On Tuesday, October 19, 2010, Li Ying <liying.cn.2...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
