And I'll add my own :). I won't add them intermixed with the other postings so you
don't
have to "search" the new additions.
.- First, I agree with the reasons why you are migrating to Model 2. It seems all the
"model 2 club" are members because of that ;).
About the rest, I pretty much agree with everything that Craig said, so I'll just add
my
own reasoning.
.- Do we always use the controller servlet for ALL the links? No, as Craig said, if
there's no reason to do it, you don't need to. We just do it when we need the
controller
servlet to "control" something for that specific page, like business logic. However, I
have to admit that this is the case with almost all the JSP pages, because if it's a
JSP,
it's dynamic so it probably needs some business logic to get its dynamic content. And
there's almost no performance degradation, or there shouldn't be, between calling a JSP
directly and calling it through your controller servlet, unless you use sendRedirect().
I'm in Craig's club, regarding how we approach the design of an application (he
explained
that in another posting) first get a flexible, clean and appropriate architecture, and
then check if you have performance hotspots. If my page takes 2secs to get to the
browser
without the controller, and 2secs 10 milliseconds when going through the controller
servlet... I'd rather use the controller.
.- How does the controller know which method to execute? We use the filename
extension/servlet path approach. We chose not to use hidden fields because it can get
difficul to manage (change a name of a jsp page and then you have to change all the
pages
where this page is referenced) and because you have to add this information in EVERY
link
to the controller servlet. So we use urls like ".../OperationName.appSuffix" where you
just have to get appSuffix to know which "application" you are calling and
OperationName
to know which "method" to execute. Then use this info to get the appropriate objects to
be called from Hashtables. These hashtables are initialized at init time in the
controller servlet, read from an XML file and easily modified in runtime, so if I want
to
change the JSP page I just have to go to the XML configuration and change it there,
links
can have more meaningful names without imposing these names on actual JSP files, you
don't have to include the JSP file name in every link...
.- Where do we include the code of each "method"? We also use the action pattern, for
various reasons. First, we don't want to impose these classes to be servlets and you
really don't gain much (meaing performance) by using different servlets instead of
one.
Second, we want to have ONE central point of management where we can make sure that all
the common shared resources have been initialized and from where we can control
"application wide events". That means that we declare a set of Actions to be an
application and there are some methods that are executed before any of them can be
called(application starts up) and some are called after all of them have been
"disabled"
(application stops). This is pretty useful when initializing/cleaning initial EJB
references, connection pools... We also add here some security control but I hope this
will be done by all containers sooner than later ;). We actually don't reuse one
instance
of the Action class, like Craig does, but we get each instance through a ActionFactory
object so if one day I need more performance, I can very easily turn this factory into
a
shared pool.
.- Regarding the use of EJB, we don't always use EJB and we usually do as Craig saids,
using session or request parameters depending on the scope. But when using EJB, we try
to
avoid passing the real EJB to the JSP page because every call to an EJB bean method is
a
network call and then you can get very high network traffic. So we get the EJB bean,
convert it into a normal Bean and we "send" the latter to the JSP page.
.- Regarding the presentation issue. We now have tested the model you explained
EJB-Business Logic, Action class-Operational Logic, JSP-Presentation Logic-UI, and we
have found some inconvenients in the presentation part regarding the designers point of
view. Having Java code in the JSP pages introduces "unfriendly" elements into the HTML
designers environment and I understand them. We are not using taglibs (haven't found
time
yet ;)) and I'm pretty sure this will help improving a little bit but I'm not sure it
can
really solve the whole problem so I though of another approach. What I want to test is
adding one more step in the end and using XML and XSL to create the UI, so the scheme
would be something like that:
EJB-Business Logic, Action class-Operational Logic, JSP-Presentation Logic -> XML ->
XSL-UI Creation.
So a programmer creates a JSP page to contruct the appropriate XML document using if,
elses, special taglibs, isUserInRole(), ... and then the designer uses XSL to create
the
HTML view from the XML data. The key point here, IMO, is that HTML designers just
handle
information and don't have to care about loops, security..., they just have to care
about
formatting nicely some information that comes in an structured way (XML). Developers
just
have to care about creaing the appropriate XML from their JSP pages and the inherent
flow
control strcutures of XSL(mainly patterns) will take care of the rest. Another
advantage
is that you can specify exactly the "contract" between developers and designers, that's
the XML document so if you agree on that, the designers can start developing the whole
site with some static XML test files and in the end everything should fit quite
nicely. I
know it has some disadvantages like adding another layer of complexity and forcing
designers to use XSL but I think it might be worthy for some projects and designers are
going to have to learn either XSL or JSP/taglibs so... And for some small projects it
might not be worthy but then, don't use it ;) So, any comment on this approach?
"Craig R. McClanahan" wrote:
> 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
===========================================================================
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
