I will intersperse a couple of my own observations on this topic below.
On Fri, 17 Mar 2000, Kedar Sardesai wrote:
> Hi Kevin,
>
> We are planning a project and I must say that I have a very similar design to what
> you have talked about. Please see my comments below.
>
> Kevin Duffey wrote:
>
> > Hi there,
> >
> > I have a couple of questions I am not sure if I am clear about with the
> > Model 2 approach. I would appreciate it if anyone could set me straight once
> > and for all.
> >
> > First off, I am currently using Model 1, and it works ok..but I am starting
> > to see how its getting ugly to manage, and it sure doesn't allow us to hire
> > a web developer without knowing a bit of Java programming with all the
> > scriplet stuff we have in it.
> >
Sounds like you are going the right direction for the right reasons.
> > On that note, I would like to lay out the design of our site. Basically,
> > EVERY JSP page needs to display our header menu, and our footer text menu,
> > and in between is the dynamic or static content. Because some of our pages
> > are static but need to display the header and footer, I use JSP on
> > everything, instead of html. This is so I can include the header and footer
> > .inc files inline with every single page. Also, there is a bit of scriplet
> > code in the header.inc so that it actually takes on some conditional
> > functionality. If a user logs in, a special object becomes existent in the
> > HttpSession, and "/inside" pages are accessible. Without that object
> > existing, any page or resource that is in the /inside folder, is not
> > accessible. At least I dont think it is. Is the way I am doing this a good
> > enough means of security..or can someone actually still get to our inside
> > pages? I know that if they type in a URL directly, or bookmark a page and
> > come back to it, that they can NOT get into any pages in the /inside folder
> > without first logging in. This is actually part of my next question
> > too...should I have EVERY single link, including those in our footer text
> > link, and all links on every page ALWAYS go to the "controller" servlet? I
> > question the use of this, because it seems going to the controller servlet
> > which then forwards on to the proper page is more time consuming and cpu
> > intensive than necessary. What is the general census on this? I do mean only
> > for static pages..which are mostly outside pages. Oh..outside = NOT logged
> > in. INSIDE = logged in.
>
> This is EXACTLY what I am planning to do. I also do not like the to pass on every
> single request to the Controller servlet because then I need a form on every page
> (even when unnecessary) which I MUST submit to the Controller with a 'field'
> specifying the next page-id (All are JSP pages have a page-id, and currently we are
> planning to have a 'page-id' field on every page along with a 'req-page-id' for
> every requested page.
>
> So, I am thinking whether to do it 'pure' Model 2 (every request have to filter
> thru Controller) or have <A href="xyz.jsp">XYZ</A> in certain situations. I think I
> will do it the second way.
>
In my apps, I chose to link directly to the next JSP page when there was
no business logic that needed to be executed -- for example, navigation
links and the like. Otherwise, I always filter through the controller
servlet.
>
> > The next thing. Is it common to use a hidden form field, say with a name
> > like "command" and a value of some sort in order for the controller servlet
> > to know which method to call? Or are there other ways used, such as the
> > requested URI and parsing it based on the URI that comes in? Seems to me
> > using a hidden field on every form would be easier to parse with a switch()
> > statement (once you convert the value to an int type).
>
> We will use hidden fields. I agrre with you that It is easier that way.
>
There are really two issues here. The first one is, how do I indicate to
the controller servlet what method to execute. I've seen (and used) three
different approaches:
* Hidden fields, as described here.
* Using "extra path" info added to the
request URI after the name of the servlet,
which is then picked up with getPathInfo().
* Mapping the servlet itself to a filename
extension, so I can forward to "saveCustomer.go"
or "listOrders.go", and the controller servlet
can use getServletPath() to see what the selector
is.
The second issue is, how does the controller servlet dispatch to the right
method? See the following comment.
> > Next..is it common to use a single servlet with 1 to x number of methods
> > where x = the number of pages/forms being submitted to the controller
> > servlet? It seems to me that a single servlet approach would yield a LOT of
> > methods and code in a single .java file. Right now, the way our old site
> > does it is derive all servlets from a "default" servlet. Each descendant
> > overrides a "dispatch" method that is called by the base servlet on all
> > incoming requests. This way, we can create descendant servlets that are
> > smaller in size and are matched with the "group" of 1 or more forms/pages
> > they belong to. Thus, a login form my have a LoginServlet that descends from
> > BaseServlet and has a hidden command code of 10, that the LoginServlet
> > checks for and handles if its there. Is this a better way of doing the
> > Controller Servlet method? Is there any advantage to either way? The thing
> > is, it seems to me its better organization and easier to work with when
> > descending servlets that provide a set functionality for one or more forms
> > that relate to the servlet. The single servlet approach really seems like it
> > would be time consuming as you add more and more forms that each require a
> > method to handle.
>
> I was planning to use just 1 servlet, but I had a feeling that it was going to grow
> too big. I really like the approach you have taken. I have some trivial Qs about
> the above.
>
The approach I use is to divide the business logic parts into separate
classes that implement an Action interface, rather than being methods in a
paticular servlet. The name of the class to use for each selection is
stored in a Hashtable (loaded in the init() method). Fundamentally, my
controller's doGet() servlet looks like this:
* Extract the selection code as described above.
* Use that to do a hashtable lookup, and retrieve
the class name of the action class to use.
* Use the class name to look up an action class
instance of this class in a second hashtable (the
first time a particular action class is used, I
create a new instance and store it here, under the
class name).
* Call the perform() method of this action class
(the method is defined in the Action inteface).
This avoids having all the logic in a single class, and having to use a
big switch or if/else chain to call the right method.
> - How do you store specific-controller (ex: LoginServlet) objects in your main
> controller (like say, hashtable with key='Login' value='reference to LoginServlet
> object' ?
> - When do you instantiate those specific controllers (guess : main servlet's init()
> method)
> - I assume that you cast specifc controller's to the base-type and then call
> dispatch() on them ?. right ?
>
See above for my appoach.
>
> > How about each method? Is it commong to do the following (in psuedo form)
> >
> > 1) create EJB or local session object
> > 2) read in form parameters into EJB or local session object
> > 3) do logic in that session (whether EJB or a local session object if not
> > doing EJB)
> > 4) get results back
> > 5) create JavaBean and populate javabean properties with results
> > 6) put bean into HttpSession
> > 7) forward (using RequestDispatcher) to proper JSP page to display results.
> >
> > When I say "local session object", I mean basically a class we create that
> > would eventually become an EJB that we use. Right now we are not moving to
> > EJB, but we plan to very soon. I want to be ready by basically creating the
> > "session" object that stores the data needed and does all the logic,
> > database routines, etc, then returns results. I believe this is what EJB is
> > all about isn't it? I know it has transaction management, etc..but from what
> > I have gathered this seems to be the advantage of EJB, and that it can go on
> > a n-tier server and be scalable to multiple servers handling requests.
>
> > Is it common to RequestDispater forward to JSP pages that display (VIEW) the
> > data the servlet/ejb/session object came up with?
>
> I think this is not only common but the recommended and correct (I think) approach.
>
That's what I do, although not all my apps need EJBs. Basically, the
action method in the controller servlet uses session attributes, or
request attributes (depending on how long I need the data) to pass results
on to "view" JSP pages.
> Previously, we also had EJB in mind, but that solution seems to be an 'over-kill'
> for us at this moment. Also, we are short of time to research enough on EJB
> containers and Application servers (in fact, we were close to buying Oracle App.
> Server, had it supported JSP)
> Any way, now I am using plain Java Beans for logic and DB classes (eventually to be
> replaced by EJBs later) which will implement DBIF interface. The EJBs later will
> implement the same interfaces.
>
> > What we would like to be able to do is separate the JSP pages so that a web
> > developer that knows little to nothing about Java can develop
> > HTML/JavaScript/Style-Sheet based web pages, and hopefully with the advent
> > of new JSP/JavaBean aware IDEs to develop web pages with graphically, can
> > just drag/drop a JavaBean onto a page, and use its properties as need be.
> > Then, me, the server-side front-end guy, developers the method(s) to process
> > the request, and developers the JavaBeans to be returned for the JSP page to
> > display. Finally, there would be back-end guys doing the EJB/session and
> > persistence layers. I believe this is what J2EE makes easier isnt it..and
> > this is what we will want in our company.
>
> Yep!
Yep squared.
You might also look at using JSP "custom tags" to create complex HTML
representations of your business objects.
> --
> Kedar
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
