Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / October 2006

Tip: Looking for answers? Try searching our database.

Feedback on a design decision?

Thread view: 
Jeff Marder - 05 Oct 2006 16:39 GMT
I have reached a stalemate with a coworker in a discussion about a
particular design issue and I'm interested in getting a few other
opinions. We are developing an MVC web application using servlets and
JSP. Currently, we use a servlet as a controller that instantiates a
singleton data access bean which returns data transfer objects. The
point of contention is the use of a "constants" class which contains
configuration information. A typical "constants" object looks something
like this:

public class MyDemoApplicationConstants {
      public static final String DSN = "myDsn";
      public static final String PARAMETERS_JSP =
"selectSomeReportParameters.jsp";
      public statc final String DISPLAY_REPORT_JSP =
"reportDisplay.jsp";
}

This is it. There are no methods in this class. It contains only public
static final variables.

Our servlet would have something like this:

...
public void handlePageRequest(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException,
JspException {
      // instantiate data access object
      MyDataAccessObject whatever = new
MyDataAccessObject(MyDemoApplicationConstants.DSN);

      String pageAction = request.getParameter("pageAction");

      if (pageAction.equals("showReportParametersForm")) {
         // processing
         // forward to JSP
         this.goToPage(MyDemoApplicationConstants.PARAMETERS_JSP ,
request, response);
         return;
      }

      else if (pageAction.equals("showReport")) {
           // read in variables and call appropriate methods on data
access bean
           // set result in request

this.goToPage(MyDemoApplicationConstants.DISPLAY_REPORT_JSP, request,
response);
           return;
      }
}

Now, the specific issue here is what are the advantages and
disadvantages of keeping the configuration in a separate "constants"
class? Keep in mind that this configuration is not application-wide,
but is specific to the servlet and may be required by objects
instantiated by the servlet. Why not keep it in the servlet? I'm also
interested in any opinions on the use of a configuration parameter for
the filenames of JSP's. Keep in mind there is no logic to dynamically
change the JSP that we are forwarding to. Why use a variable instead of
just writing the name? Any feedback is greatly appreciated.
Manish Pandit - 05 Oct 2006 16:56 GMT
Hi,

>From what I could understand, this approach has these 2 disadvantages:

1. Any changes to your navigation will need code change + build +
redeploy vs. if you use something like struts, the navigation change
may not need a code change + build 99% of the times.

2. Your code will be full of if-else.

If you think that the constants are specific to a servlet, and
obviously do not change throughout the servlet life cycle, why not put
them in your web.xml as servlet init parameters? That way, your servlet
will have access to them all the time, and you'd also be able to change
them without having to do any code change and rebuild.

Either way, please take a look at struts - it puts a very clean MVC
approach in place.

-cheers,
Manish
Jeff Marder - 05 Oct 2006 17:01 GMT
> Hi,
>
[quoted text clipped - 17 lines]
> -cheers,
> Manish

I appreciate the feedback, but I'm more interested specifically in
whether or not it's a good idea to put variables required by a servlet
into a separate "configuration" class. I am aware that any changes to
the configuration require a recompile, but for the kinds of parameters
we'll be storing in those classes it's not an issue. What do you guys
think of putting the JSP filenames in a variable contained in the
constants class rather than in the servlet?
Christopher Benson-Manica - 05 Oct 2006 18:28 GMT
> What do you guys
> think of putting the JSP filenames in a variable contained in the
> constants class rather than in the servlet?

I suppose I would rather see the filenames in a nested class in the
servlet rather than existing by themselves, for what that's worth.

Signature

C. Benson Manica           | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com      | don't, I need to know.  Flames welcome.

Jeff Marder - 05 Oct 2006 19:08 GMT
> I suppose I would rather see the filenames in a nested class in the
> servlet rather than existing by themselves, for what that's worth.

At that point, why even use a nested class? They wouldn't be accessible
from the outside so why not just make them members?

public MyServlet extends HttpServlet {
  public static final String JSP_PARAMS = "params.jsp";
  public static final String JSP_DISPLAY_REPORTS = "report.jsp";

  ...
}
Christopher Benson-Manica - 05 Oct 2006 20:06 GMT
> At that point, why even use a nested class? They wouldn't be accessible
> from the outside so why not just make them members?

They'd be no more or less accessible from the outside than they would
be as members...

> public MyServlet extends HttpServlet {
>    public static final String JSP_PARAMS = "params.jsp";
>    public static final String JSP_DISPLAY_REPORTS = "report.jsp";

>    ...
> }

I would suggest that

public MyServlet extends HttpServlet {
 public static class JspPages {
   public static final String PARAMS = "params.jsp";
   public static final String DISPLAY_REPORTS = "report.jsp";
 }

 ...
}

, yielding in-class references like JspPages.PARAMS, both looks better
and will make it easier for your IDE to helpfully display a list of
possible JSP page names.  Not to mention that it makes a nice logical
grouping of these related items.

Signature

C. Benson Manica           | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com      | don't, I need to know.  Flames welcome.

Oliver Wong - 05 Oct 2006 22:00 GMT
>> I suppose I would rather see the filenames in a nested class in the
>> servlet rather than existing by themselves, for what that's worth.
[quoted text clipped - 8 lines]
>   ...
> }

   If they're not accessible from the outside, how about:

public MyServlet extends HttpServlet {
  private static final String JSP_PARAMS = "params.jsp";
  private static final String JSP_DISPLAY_REPORTS = "report.jsp";

  ...
}

   - Oliver
Simon Brooke - 06 Oct 2006 15:42 GMT
>> What do you guys
>> think of putting the JSP filenames in a variable contained in the
>> constants class rather than in the servlet?
>
> I suppose I would rather see the filenames in a nested class in the
> servlet rather than existing by themselves, for what that's worth.

Why?

Signature

simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/

       ;; L'etat c'est moi                     -- Louis XVI
       ;; I... we... the Government            -- Tony Blair

Christopher Benson-Manica - 06 Oct 2006 16:27 GMT
> > I suppose I would rather see the filenames in a nested class in the
> > servlet rather than existing by themselves, for what that's worth.

> Why?

Because they have no meaning or utility for any unit other than the
servlet.

Signature

C. Benson Manica           | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com      | don't, I need to know.  Flames welcome.

Simon Brooke - 08 Oct 2006 00:38 GMT
>> > I suppose I would rather see the filenames in a nested class in the
>> > servlet rather than existing by themselves, for what that's worth.
[quoted text clipped - 3 lines]
> Because they have no meaning or utility for any unit other than the
> servlet.

But why bother with the nested class? Why not make them static class
variables of the Servlet class itself?

Signature

simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; This email may contain confidential or otherwise privileged
;; information, though, quite frankly, if you're not the intended
;; recipient and you've got nothing better to do than read other
;; folks' emails then I'm glad to have brightened up your sad little
;; life a tiny bit.

Christopher Benson-Manica - 09 Oct 2006 15:26 GMT
> But why bother with the nested class? Why not make them static class
> variables of the Servlet class itself?

See my response elsethread - my personal (humble) opinion is that

JspPages.WELCOME

looks better than

WELCOME_JSP_PAGE // or some such name

, which I believe are the two alternatives under discussion.

Signature

C. Benson Manica           | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com      | don't, I need to know.  Flames welcome.

Christopher Benson-Manica - 05 Oct 2006 18:24 GMT
> public class MyDemoApplicationConstants {
>        public static final String DSN = "myDsn";
[quoted text clipped - 3 lines]
> "reportDisplay.jsp";
> }

I presume that 1.5 enums are not an option.  You missed the private
default constructor, as well.  In the absence of enums, IMHO this is
an acceptable design choice and one which I'm sure has been made in
many similar situations.  One thing you might consider is moving the
actual constant values to a properties file, obviating the need to
rebuild if those values should happen to change.  

If nothing else, this approach keeps your constant values in one
easily accessible place, which strikes me as a good thing.

Signature

C. Benson Manica           | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com      | don't, I need to know.  Flames welcome.

Jeff Marder - 05 Oct 2006 19:04 GMT
Thanks for your insight. There is no constructor and these objects are
never instantiated. The variables are accessed in static context. What
about putting the names of stylesheets and JavaScript files in the
constants object and having the servlet pass them to the JSP via the
request object.

> > public class MyDemoApplicationConstants {
> >        public static final String DSN = "myDsn";
[quoted text clipped - 17 lines]
> C. Benson Manica           | I *should* know what I'm talking about - if I
> cbmanica(at)gmail.com      | don't, I need to know.  Flames welcome.
Christopher Benson-Manica - 05 Oct 2006 20:07 GMT
> Thanks for your insight. There is no constructor and these objects are
> never instantiated. The variables are accessed in static context. What
> about putting the names of stylesheets and JavaScript files in the
> constants object and having the servlet pass them to the JSP via the
> request object.

I'm not sure I like that better than simply making them members,
although your prime happiness target is obviously your coworker and
not me :-)

Signature

C. Benson Manica           | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com      | don't, I need to know.  Flames welcome.

Lew - 06 Oct 2006 05:09 GMT
> Thanks for your insight. There is no constructor and these objects are
> never instantiated. The variables are accessed in static context. What
> about putting the names of stylesheets and JavaScript files in the
> constants object and having the servlet pass them to the JSP via the
> request object.

When you say "there is no constructor", do you mean that you have not declared
one in the source for your constants class? If so, then there likely *is* a
constructor.

If no constructor is provided for a non-abstract class, then Java provides the
default constructor for you (that's why it's called the "default"
constructor), hence the need to declare one as private.

- Lew
Simon Brooke - 06 Oct 2006 15:40 GMT
> I have reached a stalemate with a coworker in a discussion about a
> particular design issue and I'm interested in getting a few other
[quoted text clipped - 4 lines]
> configuration information. A typical "constants" object looks something
> like this:

[scythe: code example]

> Now, the specific issue here is what are the advantages and
> disadvantages of keeping the configuration in a separate "constants"
> class? Keep in mind that this configuration is not application-wide,
> but is specific to the servlet and may be required by objects
> instantiated by the servlet. Why not keep it in the servlet?

I would keep it in the Servlet. Indeed, to go further, I /do/ keep that
sort of thing in the Servlet. I can see no possible design, engineering or
maintenance basis for inventing a separate class for them - *unless* they
are widely shared by other classes.

> I'm also
> interested in any opinions on the use of a configuration parameter for
> the filenames of JSP's. Keep in mind there is no logic to dynamically
> change the JSP that we are forwarding to. Why use a variable instead of
> just writing the name? Any feedback is greatly appreciated.

I'd tend to put it in a constant rather than using a string in the code,
simply because if you've got it in a constant it's easier to reuse it
somewhere else, for example in debugging or logging code. Yes, you may not
need to do this right now, but it's easier for maintenance in future. It's
also easier for maintenance if The Programmer Who Is To Come After You can
find all the specific values in a well commented declaration block at the
head of the file, rather than having to search through all the code to
find it.

Signature

simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; We don't just borrow words; on occasion, English has pursued other
;; languages down alleyways to beat them unconscious and riffle their
;; pockets for new vocabulary                      -- James D. Nicoll



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.