Feedback on a design decision?

[Jeff Marder]

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]

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]

Hi,


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

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]

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";
}

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.

 

[Christopher Benson-Manica]

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.

 

[Jeff Marder]

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.

 

[Jeff Marder]

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]

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.

 

[Christopher Benson-Manica]

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

 

[Oliver Wong]

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";

...
}

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

 

[Lew]

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]

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:
[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.

 

[Simon Brooke]

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?

 

[Christopher Benson-Manica]

Why?

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

 

[Simon Brooke]

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?

--
(e-mail address removed) (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]

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.