Skip Hollowell wrote:
This may be a bit off target, but I was hoping some folks here have
some suggestions.
I have been working on a Struts2 app here for the last6-8 months, and
it is now pretty stable. So stable in fact that we want to use it as
a model for more apps with similar functionality. So my question is,
how can I split this thing apart, presumably into Core features, and
project specific features.
I assume I will keep a separate set of JSP's for each app. But what
about actions? I can keep the struts jar files, and the base actions
in the core project. And then...what? Extend those actions as needed
for features outside of the core set on a project by project basis?
All of my file and XML processing for example, can be core. But each
of my actions extends the ApplicationSupport.java, which in turn is
used to load all of my application.properties. So do I somehow tell
it to use a properties file from my project dir instead? How?
You can see my confusion, and my dilemma. I am just trying to set
things up now so I am not maintaining multiple copies of code for the
core features of all of these apps, and most of these core feature are
very Struts2 related.
Any help, pointers, wikis or articles that you know of would be
greatly appreciated.
Skip.
Hi Skip,
Here's some tips:
1. Refactor common business logic out into its own re-usable jar(s).
This should have no struts dependency whatsoever. Build upon this and
refactor as it grows and you'll end up with code you can reuse across
your applications. These should be common classes, services, mixins and
helpers that your actions and other applications can reuse.
2. Your common actions, result types, interceptors, validators etc can
all be refactored into jar(s). Struts2 will allow you to use any of
these if they're referenced in your config and available in your app's
classpath.
3. Unfortunately JSP's cannot be loaded from the classpath and this is
an important reason many developers prefer Freemarker or Velocity
pages. Your JSP's will need to be duplicated for each webapp (you could
make this part of the build process though). If you are genuinely going
to reuse pages and or components, consider converting them to Freemarker
or Velocity as don'e for all the struts UI tags. This approach also
allows them to be unit tested easily and potentially reused in other
applications.
4. Depending on what you're re-using, it may be beneficial to create
your own struts2 plugin that sets up your re-usable default stack,
interceptors, default results, etc. This is surprising
straight-forward: http://struts.apache.org/2.0.11/docs/plugins.html
5. Finally, strongly resist the temptation to create a deep action class
hierarchy. If you genuinely have common simple behaviour, sure, create
your own ActionSupport equivalent, but otherwise try following the
patterns already used in struts2: Simple and shallow pojo actions. eg.
create your own interfaces like ValidationAware, SessionAware etc. for
your actions (eg. I use EmployeeAware) and create delegates, mixins or
services for the common behaviour. Don't allow unused superclass
behaviour to get into your action classes as it may bite you later.
Keep them nice and simple.
Hope that helps,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
