Hi,
>Craig gave some pseudocode for an action class that had the perform method:
>
> public interface Action {
> public void perform(HttpServlet servlet, HttpServletRequest
>request, HttpServletResponse response)
> throws IOException, ServletException;
> } // ends interface Action
>
>(thanks Craig)
>
>Now my questions are, what is the advantage is passing an HttpServlet
>object? I understand HttpServletRequest and HttpServletResponse, but why
>HttpServlet? Also, assuming you answer this, HOW do you pass this inside
>the servlet (sounds trivial but I have never tried any such thing)?
I had the same question, and for my purposes, it doesn't apply. However, the
HttpServlet allows your action classes to gain access to the ServletContext,
among other things. When your Action class needs to forward to a page,
you'll need to get the RequestDispatcher (unless you use the
response.sendRedirect), which the HttpServlet allows access to via the
Context object.
>
>There was mention of 2 HashTables (or HashMaps) used in the controller
>Servlet. If I am understanding correctly, the first maps the requestURI to
>the appropriate action class, and the second is used to store an
>instance of
>the appropriate action class? So, in theory, you would grab the requestURI
>and look it up in the first HashTable. Once the appropriate class is
>determined, you look for an instance of that class in the second HashTable?
>You would then call the perform method on that class (if it exists) or
>instantiate the class and call the perform method? I have not worked a lot
>with dynamic class loading so a little help here would be greatly
>appreciated. Maybe a little pseudocode to get me over the hump?
Hey..good question. This is what I wanted to know as well. How do you create
only a single instance of the action class and then guarantee once its
created, it isn't created again. I have been using the
Class.forName(actionName).newInstance() call, but as stated in one of these
posts..that always creates a new instance. I would like to avoid that if at
all possible.
I do know that you definitely need to create ALL variables inside the
perform() method itself, and have no instance variables for this to work
correctly.
Ofcourse..you could use a "single" instance variable, say, COUNTER, to keep
count of the number of accesses to the particular action. It would at least
provide decent statistical information as to what actions/pages were being
used. Craig..is this plausible?
>
>I had some concern about something craig mentioned in the brevity of his
>action classes (being 50 - 100 line mostly performing setXXX()). In my
>servlet, I am doing all my setXXX() error checking where it seems you are
>performing this in the bean (or maybe I am just not writing as concise
>code?). If this is the case, how do you know when the data is
>inappropriate
>for the field (ie, characters were found in a social security number?). In
>my case, I do this checking in the servlet. If an error has occured, I set
>the bean to an appropriate value (sometimes to null, and sometimes to the
>input value so that it can be easily modified by the user). Otherwise I
>just set the bean property. Could you go into a little more detail on this
>please? As I mentioned earlier, it is hard to learn alternative design
>strategies when there are little to no examples to learn from =).
I can't speak for Craig, but the way I had planned on doing it was using the
JavaBean (per "form", not per action, so that a multi-page form used a
single JavaBean) to "model" that form data, and act on that data. I had a
similar question that I recently read about. You have entity beans (not
referring to EJB entity beans in particular..just in general), and you have
session beans. The entity bean models the database, and has methods that act
on the data. The session beans would contain a reference to this entity and
contain the methods that perform logic using the data in the entity. This
could be applied to EJB if you using it, or not. In my opinion, I am setting
up our classes this way so that when we move to EJB it is a lot less
rewriting and mostly just moving the classes around to where they need to be
(ejb container instead of servlet container). I am not totally clear yet if
this will work, but I believe the action class should be nothing more than a
gateway to the "session" logic code, and the session code should make use of
the entity code. For the most part, it seems to me the entity beans would
contain the fields (properties) and the getter/setter methods, as well as
say, translation methods. For example, we created a PhoneNumber class.
PhoneNumber contains area code, prefix, suffix and extension fields, along
with getter/setter methods. But, it also has methods that will convert the 4
fields into a single string, and vice versa. We store phone numbers as a
single string in the database in the form of 123-456-7890 x12345. So, the
"entity" object, PhoneNumber, stores the data. The SESSION object, say, a
"User" session would consist of a reference to say an Address object that
would contain Name, Address, City, State and Zip as String objects along
with the PhoneNumber object for Home and Fax phones. The session would then
have the logic methods that work on the Address entity.
Craig/Daniel, jump in any time. ;) I am not sure if this is correct. I
realize every developer has thier own way of doing things..but I too could
use pointers on this analogy. I am not quite clear if what I have described
above is infact the right way to describe it. Help it if you feel otherwise.
>One more thing (as if this email isnt long enough). . . I read mention of
>using yet a public HashTable (or was it a method)? to determine which page
>the action class should forward to instead of hardcoding the value within
>the action class. Is this really all that advantageous?
It is, yes, because you can have more than one action forward to the same
page, and you can modify the page names, among other things in the .xml
config file, instead of the code. Imagine for any reason at all something
changed and you had the link hard-coded. You have to recompile the code and
upload it. Where-as, by putting it in a config file, you simply change it
and restart the server. Ofcourse..when I think about what I just said..it
seems to me you'll have to upload the .xml config file too..but I believe
the point is, you can change all the links in one single file, the .xml
config file, instead of looking through the various code and chaning and
recompiling there. Plus, if you have 10 action classes all using the same
hard-coded link, and that link changes for some reason..say a site redesign,
you have to change it in all those places. By using it in a config file, you
only change it once.
===========================================================================
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
