Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (athena.apache.org: domain of davelnewton@gmail.com
 designates 209.85.219.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJvL2g7NkmCSUiJX_507K3i-gd6mNaM2++5V=09nx005m70D0Q@mail.gmail.com>
References: 
 <CAJvL2g7NkmCSUiJX_507K3i-gd6mNaM2++5V=09nx005m70D0Q@mail.gmail.com>
Date: Mon, 7 Oct 2013 16:35:26 -0400
Message-ID: 
 <CADJJoV6d5MCME_H8fpCUOMPzv2vEuyd2AmX9FBfGKSu-FbRKyw@mail.gmail.com>
Subject: Re: JspHelper concept to improve MVC separation
From: Dave Newton <davelnewton@gmail.com>
To: Struts Developers List <dev@struts.apache.org>
Content-Type: multipart/alternative; boundary=001a1134c98ea0ad7b04e82c9769

--001a1134c98ea0ad7b04e82c9769
Content-Type: text/plain; charset=ISO-8859-1

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>

--001a1134c98ea0ad7b04e82c9769--