Feedback on a design decision?

Discussion in 'Java' started by Jeff Marder, Oct 5, 2006.

  1. Jeff Marder

    Jeff Marder Guest

    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 =
    public statc final String DISPLAY_REPORT_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

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

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

    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,

    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.
    Jeff Marder, Oct 5, 2006
    1. Advertisements

  2. 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.

    Manish Pandit, Oct 5, 2006
    1. Advertisements

  3. Jeff Marder

    Jeff Marder Guest

    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?
    Jeff Marder, Oct 5, 2006
  4. 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, Oct 5, 2006
  5. 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.
    Christopher Benson-Manica, Oct 5, 2006
  6. Jeff Marder

    Jeff Marder Guest

    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, Oct 5, 2006
  7. Jeff Marder

    Jeff Marder Guest

    I suppose I would rather see the filenames in a nested class in the
    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";

    Jeff Marder, Oct 5, 2006
  8. They'd be no more or less accessible from the outside than they would
    be as members...
    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, Oct 5, 2006
  9. 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 :)
    Christopher Benson-Manica, Oct 5, 2006
  10. Jeff Marder

    Oliver Wong Guest

    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
    Oliver Wong, Oct 5, 2006
  11. Jeff Marder

    Lew Guest

    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

    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
    Lew, Oct 6, 2006
  12. Jeff Marder

    Simon Brooke Guest

    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'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, Oct 6, 2006
  13. Jeff Marder

    Simon Brooke Guest

    Simon Brooke, Oct 6, 2006
  14. Because they have no meaning or utility for any unit other than the
    Christopher Benson-Manica, Oct 6, 2006
  15. Jeff Marder

    Simon Brooke Guest

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

    (Simon Brooke)
    ;; 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.
    Simon Brooke, Oct 8, 2006
  16. See my response elsethread - my personal (humble) opinion is that


    looks better than

    WELCOME_JSP_PAGE // or some such name

    , which I believe are the two alternatives under discussion.
    Christopher Benson-Manica, Oct 9, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.