This sounds very much like the "Portlets" work being done in the
Apache-Jetspeed project (from what I've understood while lurking on its
mailing-list).
http://java.apache.org/jetspeed/index.html
Lance Lavandowska
www.AgDomain.com
www.Brainopolis.com
----- Original Message -----
From: "David Mossakowski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 04, 2000 12:11 PM
Subject: Re: JSP Architectural Question
> 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
>
===========================================================================
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
