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.
>
> 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.
> 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.
> 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.
- 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 ?
> 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.
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!
--
Kedar
===========================================================================
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
