struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Newton <davelnew...@gmail.com>
Subject Re: JspHelper concept to improve MVC separation
Date Mon, 07 Oct 2013 20:43:11 GMT
Then I'm not sure I see the point; `ModelDriven` would do the same, but
you'd expose the decorator, not the underlying domain object. I tend
towards the same pattern, but delegate directly to a domain model, so I can
precisely control access (and document) at the view level.

Dave



On Mon, Oct 7, 2013 at 4:38 PM, Mike Menzies <glopal@gmail.com> wrote:

> Yes. That's pretty much exactly what it is.
>
>
> On Mon, Oct 7, 2013 at 3:35 PM, Dave Newton <davelnewton@gmail.com> wrote:
>
> > So it's a presenter/decorator?
> >
> > Dave
> >
> >
> >
> > On Mon, Oct 7, 2013 at 4:26 PM, Mike Menzies <glopal@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: davelnewton@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>
> >
>



-- 
e: davelnewton@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>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message