I think that by now everyone is using the DispatcherServlet->ActionClass paradigm but I
still see discrepancies between how the JSP pages become part of the application.
I do not have a designer working on my JSP pages so I have freedom to design the JSP
stuff
as I think would be easiest for me :). This has emerged in the following design that I
would like you to comment on.
1. JSP sections - I've decided to have small and simple JSP pages that define a part
of
display instead of having a JSP page be the actual display. This means that I have not
only _topnavigation.jsp and _disclaimer.jsp but also _searchbox.jsp and _resultlist.jsp
which are very simple components.
2. Main JSP page - this page takes DisplayManager and identifies what sections it has
and
whether to paint them or not and it creates the JSP page from <jsp:include /> tags.
It has
the basic layout of the application (or it can take it from DisplayManager). So it
knows
that DisplayManager.TOPBANNER goes on top and that then there is a table with two
cells and
the left one has DisplayManager.NAVIGATION and the right one has
DisplayManager.SEARCHBOX.
3. DisplayManager - I still don't know all the things that this class would do. I
think
that you could set up a basic look for the page. Something like AWT layouts and then
as
you put sections in they fall in place.
4. ViewableSection - besides having filename for itself (_searchbox.jsp) it would
also
have minimized (_searchbox_min.jsp) and editable (_searchbox_edit.jsp) modes.
5. Action - the way Action would use DisplayManger is something like the following:
- action takes the DisplayManger from ServletContext and tells it .newPage()
- the action keeps adding things to it as needed:
DisplayManager.addSection(DisplayManager.add(DisplayManager.SEARCHBOX)
Action always forwards to the same main JSP page that (see 1)
This design would lend itself to something like www.excite.com where you have clearly
separated sections for My Sports and My Weather and so forth but it can be used in
simpler
user interfaces as well.
I have not fully implemented this design yet. Your comments are appreciated.
dave.
"Craig R. McClanahan" wrote:
> Damian Fauth wrote:
>
> > "Craig R. McClanahan" wrote:
> > >
> > > The general organization of request processing in my apps goes like this:
> >
> > [..]
> >
> > > What I normally do is use a single servlet per web application, and then map it
>to
> > > a filename extension (I like ".go" because it implies motion). Now, if I submit
>a
> > > form to URL "/saveCustomer.go", my controller servlet is called. It can parse
> > > "saveCustomer" out of the request URI and use it as the key to a lookup table
> > > containing the Java class of the corresponding implementation class (all
> > > configured in initialization properties -- no hard coding). The first time I
>call
> > > a particular action procedure, I instantiate a new instance of that action class.
> > > After that, I resuse the same one over again (which must be thread-safe, for
> > > obvious reasons).
> >
> > Using this approach, how do you determine which page to display next?
> > Using your example above, would you then use
> > getRequestDispatcher("/saveCustomer.jsp").forward(request,response)?
> >
>
> I have used two different techniques. In my early crack at this, the name of the
> normal display page (see below for error handling) was hard coded in the action
> procedure. In other words, the action procedure for saving a customer "knows"
>(because
> I designed the UI that way) that the next page is a customer list, so it forwards to
> "/customerList.jsp".
>
> More recently, I've adopted a trick that was used in the J2EE example application
>from
> Sun. In your configuration parameters for the controller servlet, give each possible
> destination screen a logical name (such as "Display Customer List"), mapped to an
> actual JSP name ("/customerList.jsp" for the above case). Now, I can rearrange my
>JSP
> URLs without having to recompile the action classes. All I need to do is change my
> initialization parameters for the logical-to-physical mapping.
>
> In all cases, I do use RequestDispatcher.forward() at the end of my action procedure
>--
> the action procedure knows it's being invoked in a servlet-based environment (because
> it was passed a reference to the controller servlet itself, plus the
>HttpServletRequest
> and HttpServletResponse), so it can do anything you can do in the doGet() or doPost()
> method. As you'll see below, none of the logic utilized by the action procedure
>knows
> that it is being called from a servlet, so that code can be reused in other apps as
> well.
>
> >
> > How do you handle business-logic type errors that require the user to
> > correct their form input? Presumably these would be detected in your
> > Action class - can put some sort of ErrorBean into the request and
> > forward() back to the referring page?
> >
>
> Here is where the elegance of this architecture really shows up. Let's go back and
>add
> a couple more details:
>
> * In my Edit Customer display screen (with the submit that goes
> to "/customerSave.go"), the data values for all the fields are
> defaulted from a CustomerBean that was added to my session
> by some previous processing, such as the logic that selected the
> customer I wanted to edit.
>
> * When I am filling out the form, the visual appearance is that it
> shows all the info about the current customer.
>
> * I submit to the control servlet, which goes to the action
> procedure for saving a customer. It does the following:
>
> * Updates the CustomerBean properties to reflect
> the stuff I just entered.
>
> * Validate the properties of CustomerBean to make
> sure everything passes all the business rules about
> what makes a correct customer.
>
> * If there was an error, a new request bean is added
> (containing the text of the error mesage to display)
> and control forwards to the Edit Customer display
> screen again. This page now displays the most recent
> values I have entered -- plus an error message that
> is only displayed if a particular request bean (the one
> containing the error message) is present.
>
> * If there was no error, it invokes the database logic
> to save the updated customer, and then forwards
> to the normal next page, as described above.
>
> A couple of benefits of doing things this way:
>
> * From the user interface point of view, the system always
> remembers the most recent input values, just like a typical
> GUI application does. No retyping is required.
>
> * From the action procedure point of view, it is dealing only
> with the internal (object oriented) representation of a
> customer, via the CustomerBean class. It has no idea how
> the data is actually stored.
>
> * Likewise, the functional logic to save an updated customer
> also deals with CustomerBean -- it has no clue that the
> input came from a servlet/JSP based application versus some
> other mechanism.
>
> * I deal with the branching in the user interface (error case
> versus normal case) in the controller's action procedure.
> No need to have convoluted logic in a JSP page itself to
> decide which "state" the application is in.
>
> >
> > Damian
> >
>
> Craig McClanahan
>
> ===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
> FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
--
David Mossakowski [EMAIL PROTECTED]
Programmer 212.310.7275
Instinet Corporation
"I don't sit idly by, I'm planning a big surprise"
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
