So it's a presenter/decorator? Dave
On Mon, Oct 7, 2013 at 4:26 PM, Mike Menzies <glo...@gmail.com> wrote: > Hello, > > My name is Mike, and I work for a fairly large company that uses Struts 2 > for most of its web apps. Some of these web apps are quite large, and one > in particular has grown into a monster. In my ongoing efforts to clean up > this project, I have developed what I like to call a JspHelper. Before I > explain exactly what that is, I'd like to provide you with some examples of > the problems that I set out to fix. > > *Problem 1 - Monster JSPs* > During early development of this project, struts tags were highly > leveraged. I was not involved with the early phases of this project, so I > can't speak to why they were used so extensively.. but they were. Tons of > nested if tags that read var tags that were set in the JSP. Some of these > JSPs were very hard to follow. > > Even though I am a fan of struts tags, I've come to realize that they > should not be overused. JSPs cannot be unit tested and JSPs are hard to > debug. > > So cleaning up a JSP means shifting logic out, in most cases into the > action. An easy clean up could be something like this: > > <s:if test="articles != null && articles.size > 0 && user.canViewArticles"> > > into > > <s:if test="showArticleSection()"> > > It's instantly more readable, and the logic is in a testable Java class. > Following this approach creates a lot of methods in the action, which can > be a problem if you already have... > > *Problem 2 - Bloated Action Classes* > > When the project was small, it made a lot of sense to create > abstract/parent action classes to share code between actions. As time > passed, we just continued shoving any shared code in one of two "abstract" > classes... even if the code was only being shared between two out of the 20 > actions. > > The fix for this trend is to moved shared code into services, so we began > enforcing that practice. But this approach had its limitations. We use > Spring injection for all of our services, and some times a particular piece > of logic just required too much stateful input... it just made more sense > to leave it on the action where it had easy access to everything it needed, > as opposed to shoving it in a stateless service and having to pass in a ton > of arguments. > > What we really needed was some best practices put in place for the creation > of stateful, non-Spring services. > > *Enter JspHelperInceptor > > * > It wasn't until after I created this inceptor that I realized it is almost > identical to the ModelDrivenInceptor. At which point, I wondered if that is > what I should actually be using.. but more on that later. > > All this interceptor does is push an object onto the value stack. That's > it. Your action implements JspHelperAware which provides Object > getJspHelper(), and the intercept code reads almost line for line with the > ModelDrivenInterceptor. > > The idea behind this JspHelper, which is just a POJO that you define, is to > provide a place where all (or most) of the data your JSP needs can be > found. This means that OGNL can find any public members or operations > faster, and also developers can trace back any OGNL expressions in the JSP > to it's corresponding Java code. > > This approach places code in a shareable component. You can easily > aggregate one JSPHelper into another one, and then either provide wrapper > methods or simply push the aggregate helper onto the stack using the s:push > tag for direct access to it's members. > > This approach makes the actions leaner, and provides a very clear cut view. > I find at times that the action tends to be both controller and view, when > really it should only act as the controller (IMO). > > This technique is functionally very similar to ModelDriven, but it's used > slightly differently. I've used a JspHelper in combination with > ModelDriven, and I've found the JspHelper to be a good place to store > logic.. and leave the Model strictly as a business object. > > *Conclusion > * > I have personally found this technique incredibly useful in cleaning up > code. You can shift all of the JSP exclusive logic and properties to the > helper without touching the JSP (the OGNL expressions remain the same). > Then after that initial step, you have a real handle on the exact input > your JSP needs, and the actual clean up process progresses faster and with > less errors. I'm still in the process of establishing some best practices, > but so far this approach is working for us. > > I would like some honest feedback > -- e: davelnew...@gmail.com m: 908-380-8699 s: davelnewton_skype t: @dave_newton <https://twitter.com/dave_newton> b: Bucky Bits <http://buckybits.blogspot.com/> g: davelnewton <https://github.com/davelnewton> so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton>
