Re: Model 2: multi-page and multi-button details
We're using (client-side) javascript to perform the submit to the proper
action class. So, for example, here's a coupla' buttons on the same form:
input type="Button" name="Save"
value="Save"
onClick='javascript:doSubmit("SaveCustomer.do")'
input type="Button" name="New"
value="New"
onClick='javascript:doSubmit("NewCustomer.do")'
And here's the javascript for the submit/click:
function doSubmit(myAction) {
document.forms.query.submit(myAction)
}
I'm *definitely* curious as to how others are doing this
HTH,
Mike
At 4/19/2000 10:34 AM -0400, Seibert, Dan wrote:
Hi all,
We are designing a new enterprise app and are sold on the
jsp-servlet-bean/ejb model 2 approach. I am working on some prototypes to
figure out some of the details. I have been following the
Kevin/Craig/Dan/et.al Model 2 architecture thread very closely and applying
the techniques discussed to my prototype. I have a couple of details to
throw out to the crowd.
* Some of our forms have multiple submit buttons for a single form
(ex. Save, Delete, Find, Add, Remove, etc). My dilemma here is if I have one
action per form, my actions are not as specific as I would like them to be.
(Having FindCustomer and SaveCustomer handled by the same action). What I
have tried in the prototype is giving the buttons the same NAME (Button)
and assigning different VALUES (Find,Save,Delete). My controller servlet
then retrieves the Button value into a prefix (prefix =
request.getParameter("Button") ) and adds the prefix to the URL. So
"/Customer.do" becomes a "SaveCustomer" or "FindCustomer" action. Then use
this action in the Hashtable/Property List to get the specific action class.
Am I way off base here? Is there a more straightforward approach?
Are there some drawbacks I'm missing?
* Also, we have multi-page forms using a "Next" button. However, we
also provide tabs along the top to give the user the flexibility to go to
the pages in any order. My problem here is keeping the complexity down for
determining the Next page in the Action class. I've batted around a few
different solutions which all seem to have their own drawbacks. The one I
like best today also uses the value of "Button": Have the Button value take
the form of action.nextpageKey (Next.Order, Next.DestinationAddress, etc)
where "Next" is the prefix to apply to the URL as described above, and
"Order" is the key into my HashTable/PropertyList to find the next page in
the "happy" scenario.
What I don't like about this is that I'm relying too heavily on the
value of Button for multiple purposes.
Any suggestions or comments are appreciated.
Thanks,
Dan
===
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
Re: Model 2 questions basic
At 4/17/2000 03:48 PM -0700, Kevin Duffey wrote:
snip
I will say, even if you do load it all up during the init method, if there
is a way to "reload" the XML config file without restarting the server, its
possible you can "add" new action classes and thus add new forms/pages to
use those actions without shutting down the server...one advantage to having
the code you wrote..plus, if the object isn't null, it never uses the code
you have anyways..so your safe.
/snip
Let's assume that the Hashxxx you use to store your list of request URIs is
stored as an attribute of your servlet context. Then:
HashTable uriList = (HashTable)
servlet.getServletContext().getAttribute("urilist");
Since you can get set attributes this way into your servlet context (and
the servlet we are talking about here is your controller servlet), then you
could easily write an action class that reloads this object from your xml
configuration file; thus achieving dynamic reloading. Naturally, the uri
used to do this (ReloadConfig.do) would be part of your admin area with
security restrictions
Just a thought,
Mike
===
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
Re: Model 2 questions basic
At 4/18/2000 10:53 AM -0700, Kevin Duffey wrote:
Hi,
Let's assume that the Hashxxx you use to store your list of
request URIs is
stored as an attribute of your servlet context. Then:
HashTable uriList = (HashTable)
servlet.getServletContext().getAttribute("urilist");
Since you can get set attributes this way into your servlet context (and
the servlet we are talking about here is your controller servlet),
then you
could easily write an action class that reloads this object from your xml
configuration file; thus achieving dynamic reloading. Naturally, the uri
used to do this (ReloadConfig.do) would be part of your admin area with
security restrictions
Just a thought,
A good one indeed.
Interesting too. My worry is..what if you do it during the day? Two
scenarios come to mind..I am sure there are more. One is..you add a new
action, and add the action.. tags to the xml config file. Through your
admin .do action, you reload the xml file, like you said..using the servlet
context to store the Hashset (Sorry..set for me. ;). I agree with Craig
too..in passing the THIS as the Servlet to pass on to every action. This is
what makes your Admin possible..passing the servlet to gain access to the
context. So, in Scenario #1, you would simply reload the xml file, and it
would just "add" the new actions..and they should be ready to be used even
while your server is running during the day. The only thing to worry about
is somehow making sure requests don't come in during the process of
replacing the Hashset config information..thus it might be more plausible to
use a Hashtable for this?
Scenario #2 is you modify an existing action. This might mean the .java
source, or you may change an existing action to point to a new action class.
The problem in my mind is how do you do this while users are using your
actions at the same moment? You don't want to lose their session
information, or have them submit a request while the server is
"re-initializing", or they may end up seeing some nasty error messages, and
lose their info too. So what is the course of action to reload modified and
new actions (classes, xml config, etc) while maintaining current sessions?
Thanks.
Well, it seems to me that in either case you are only accessing one object
instance (your Hashxxx object). So adding a new object to it would make
that new action (.do) immediately available to all users. Replacing the
attributes associated with a specific requested URI (e.g.
RegistrationStepTwo.do) would seem to be a very fast process. E.g. here's
the code I use to load the configuration file:
ActionObjectWrapper obj = new ActionObjectWrapper();
obj.theRequestUri = requestUri;
obj.theClassname = className;
obj.theTargetPage = targetPage;
uriList.put(requestUri, obj);
Where ActionObjectWrapper is:
public class ActionObjectWrapper {
public String theRequestUri;
public String theClassname;
public String theTargetPage;
public Action theObject = null;
} // ends inner class ActionObjectWrapper
So, again, replacing a single action object (and it's associated data) is
quick and painless. But what if you are making broad changes that affect a
workflow, for example, which affects many classes and default target
pages?? One possibility might be to ignore this and allow your error
handling to kick in when users make requests for actions/pages that are no
longer supported. It seems to me that creating a whole new Hashtable object
and replacing it in the servlet context
with servlet.getServletContext().setAttribute("urilist", uriList);
would not solve this problem; since users currently actively involved in a
specific workflow might be "orphaned." I guess, if you need to modify the
app that radically, then some sort of controlled shutdown/startup might be
better
Just my 2c.
Mike
===
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
Re: Model 2 questions basic
Jeff:
I'll try to give you some pointers, based on *my* implementation of model 2
architecture
snip
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)
/snip
Here's my action interface:
/* Action.java */
import java.io.IOException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;
public interface Action {
public void perform(HttpServlet servlet,
HttpServletRequest request,
HttpServletResponse response,
String targetPage)
throws IOException, ServletException;
} // ends interface Action
In my controller servlet configuration file, I specify the "default target
page" which is supposed to represent the happy days scenario. Naturally,
each individual class that implements the Action interface is free to
override/ignore the default target page if necessary.
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 did it 'cause Craig did it this way!" Seriously, I don't recall the
specific reasons, but in a nutshell, it facilitates accessing HttpServlet
methods (and you could always cast this to your controller's class name to
do something special).
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?
Within my controller servlet I have the following:
/**
* declare inner classes.
*/
class ActionObjectWrapper {
String theRequestUri;
String theClassname;
String theTargetPage;
Action theObject = null;
} // ends inner class ActionObjectWrapper
/**
* declare member (instance) variables.
*/
HashSet m_objectCache = null;
So, the object cache is loaded up at initialization time from the
configuration file. When a request comes in I search thru the HashSet using
the request URI as the key. If theObject is null, then you need to
instantiate it before calling perform().
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 =).
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? I like the idea of
having logic names mapped to a specific file name, but otherwise, this seems
to be overhead in projects that dont span hundreds of pages (or dont have
the possibility of spanning that large). I assume, in this strategy, the
action class would lookup the logical name prior to forwarding to the .jsp
refered to in the controller servlet?
I hope this all makes sense.
Thanks to everyone for helping me in understanding some of these basic
issues I am having. I look forward to your replies :).
Thanks
Jeff
Hope I've answered *some* of your questions - don't have time for more
right now
Mike
session.invalidate() causes internal servlet error
I'm trying to invalidate the session object (to effect a logout). When I do it causes the following error: snip java.lang.IllegalStateException: removeAttribute: Session already invalidated at org.apache.tomcat.session.StandardSession.removeAttribute(StandardSession.ja va, Compiled Code) at _0002findex_0002ejspindex_jsp_2._jspService(_0002findex_0002ejspindex_jsp_2. java:63) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:126) at javax.servlet.http.HttpServlet.service(HttpServlet.java:865) at org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.ja va:172) /snip Does anybody know what I'm doing wrong/how to accomplish this? TIA, Mike /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ Michael H. La Budde email: [EMAIL PROTECTED] Prosoft, Inc. phone: 414-860-6509 [EMAIL PROTECTED] fax:414-860-7014 /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ === 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
Re: Model 2 and multi-page techniques
I'm reposting this with a different subject heading, since I got zero responses from my first posting. I've seen so many messages from people that were replied to quite quickly, I guess I've come to expect the same. Hopefully the new subject line will prompt others to read/respond Thanks, Mike All: Govind Seshadri had an excellent article on advanced form processing located here: http://www.javaworld.com/javaworld/jw-03-2000/f_jw-0331-ssj-forms_p.html Other posts to this list have talked about multi-screen (page) forms, e.g. a wizard type interface with back/next/finish/cancel buttons. I'm having a little trouble envisioning how this would all fit together. Using Govind's article as a baseline: * Would multiple forms/pages require a different validation bean for each page? (This assumes that you want to validate the user's input on a per page basis, rather than, or in addition to, when he/she chooses the finish option.) * Choosing the finish option would (naturally!) post to the UserRegistration.do according to good model 2 design. Is it OK to have the back/next "events" directly navigate to the previous/next .jsp page? (I don't want to have to create UserRegistrationStepOne.do thru UserRegistrationStepTen.do! (Do I?) * Finally, doesn't this lead to too high a degree of coupling between the view the controller(s)? Or, what I mean is, haven't we prevented our page designers from exercising their creative freedom to place which fields on which form, since that will always require "back-end" coding changes? Thoughts? Other people's implementations/suggestions would be greatly appreciated! TIA, Mike /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ Michael H. La Budde email: [EMAIL PROTECTED] Prosoft, Inc. phone: 414-860-6509 [EMAIL PROTECTED] fax:414-860-7014 /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ === 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
Multi-form processing
All: Govind Seshadri had an excellent article on advanced form processing located here: http://www.javaworld.com/javaworld/jw-03-2000/f_jw-0331-ssj-forms_p.html Other posts to this list have talked about multi-screen (page) forms, e.g. a wizard type interface with back/next/finish/cancel buttons. I'm having a little trouble envisioning how this would all fit together. Using Govind's article as a baseline: * Would multiple forms/pages require a different validation bean for each page? (This assumes that you want to validate the user's input on a per page basis, rather than, or in addition to, when he/she chooses the finish option.) * Choosing the finish option would (naturally!) post to the UserRegistration.do according to good model 2 design. Is it OK to have the back/next "events" directly navigate to the previous/next .jsp page? (I don't want to have to create UserRegistrationStepOne.do thru UserRegistrationStepTen.do! (Do I?) * Finally, doesn't this lead to too high a degree of coupling between the view the controller(s)? Or, what I mean is, haven't we prevented our page designers from exercising their creative freedom to place which fields on which form, since that will always require "back-end" coding changes? Thoughts? Other people's implementations/suggestions would be greatly appreciated! TIA, Mike === 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
http 405 error (resource not allowed)
I have a combined query criteria + results jsp page. This allows the user to enter/modify the criteria in the top half of the page and view the results in the lower portion. I'm (successfully) using InventoryQuery.do (my model 2 controllerServlet handles all *.do posts) to get there the first time. However, the submit button on the page, which is just supposed to link back to InventoryQuery.do doesn't work (it gives the http 405 error - resource not allowed) Any help would be greatly appreciated! TIA, Mike === 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
Re: http 405 error (resource not allowed)
Kevin: Someone responded to me (but I don't think to the list) that this usually arises when issuing a POST, while your class only implements the doGet() method (or, issuing a GET when your class only implements the doPost()). I have fixed this (only temporarily, 'til I get a better handle on all this stuff) by putting a doGet() method in my controllerServlet that simply calls doPost(). In the future I will implement Craig's suggestion of redirecting doGet() to an error page HTH, Mike At 3/29/2000 12:33 PM -0800, Kevin Duffey wrote: Hi, I too am having a similar problem. All .do are mapped to my ControllerServlet, and as soon as I hit the submit button, instantly it tells me the method is not allowed error. I posted about this earlier as well. Any help would be great in resolving this. Thanks. ps: I've copied some of Craig's earlier response below: I do have another concern though. What happens if someone bookmarks the Enroll.do URL, and then goes back to it? Wont it try to enroll them by going to the servlet, but without any form data? What to do in this case? Well, one thing you could do in the action procedure that Enroll.do executes is make sure the request method was a POST. That way, an attempt to do a GET (as a result of returning from a bookmark) will fail. If this is generally the case for all action procedures (i.e. they MUST be processing a form), the simplest thing to do is implement only doPost() in your controller servlet -- have doGet() return some nice error message saying that you can't return to this page. Another thing you'll probably want to do is have the controller servlet (or the servlet container if you're using 2.2 security) check for is a valid login when a *.do URL is requested. You'll probably want this anyway, to prevent malicious attempts to bypass any security you've coded into the JSP pages themselves. /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ Michael H. La Budde email: [EMAIL PROTECTED] Prosoft, Inc. phone: 414-860-6509 [EMAIL PROTECTED] fax:414-860-7014 /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ === 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
Re: Model 2, take 2
I, too, am closely following the Model 2 discussions. I greatly appreciate
everybody's input. Thank you!
At 3/28/2000 08:59 AM +0200, Daniel Lopez wrote:
snip, snip
In my case, I added some more
complexity in here because, as I want my controller servlet to handle
various applications, I store a hastable per application. I choose the
appropriate application depending on the suffix.
So "Enroll.do", I first get the application corresponding to the ".do"
suffix and then I got the action factory corresponding to the "Enroll"
operation from the selected application. Then I get the action from the
factory.
Would another option be to check the current context (instead of having
multiple suffixes)? (This way everything still routes thru your single
controllerServlet.)
Or, possibly, you could clone your controllerServlet - once for each
application/context - and achieve your separation that way?
Of course, I'm making the assumption that your use of "application" can be
interchanged with a context - is this correct?
I agree with Craig´s in this one, I also let the Action class (I call it
Operation) to forward itself to the appropriate place. This option
allows me to leave the controller servlet code clean of UI redirecting
code and this allows me to have different Operation classes that behave
differently. For example, in case I want a special Operation that does
not use forward but creates the UI itself (useful for some rare cases).
Does it make sense to add a parameter to the perform() function to
represent the target Page? E.g.
public interface Action {
public void perform(HttpServlet servlet,
HttpServletRequest request,
HttpServletResponse response
String targetPage)
throws IOException, ServletException;
} // ends interface Action
{BTW, thank you Craig for the above!}
This way the target page is (more) open to configuration (specifically, the
configuration file that links request uri's with java class names, would
also specify the target page. And, of course, only under exceptional
circumstances would the user be redirected back to the request uri, an
error uri, etc.
When using Model 2, you already are
forced to write the code that gets all the form parameters out of the
request object when it comes in (part of the action class I
believe..right?)
Yes, some people tend to use the Model 1'5 because it automagically
populates your beans from the data inside the forms. But that´s a
personal choice.
, and thus, by populating the bean and putting it in the
request, the JSP page will most likely use the bean at the request scope,
fill in the values of another form (or possibly the same form if say an
error occured and the page is being redisplayed) so that a subsequent
request will contain those values where need be.
Yes, the idea is to "communicate" the action class(business logic) and
the JSP(UI view) by putting objects in the request, the session and the
context.
I think of the action class objects as still part of the controller level
(from Model - View - Controller). Since their role in life is to mediate
between the UI the Model (your EJB objects, or, as in my case, our Corba
objects, whatever). If your business logic objects have method signatures
including HttpServletRequest and the like, then you're only going to be
accessing them thru a web-based frontend. (Not necessarily a bad thing if
you're a web developer!)
Thanks so much for all of your emails. I know its taught me alot and
enlightened me on a number of topics I was unclear about. I hope its doing
the same for others reading this ongoing discussion.
I hope so as well. It´s also useful for us as there´s no such a thing as
the perfect design and rationalizing it to explain it to others, and
compare it to other viable solutions are very good ways of "revisiting"
your design choices. And it also gives me the chance to see that Craig
and I agree sometimes ;), basically because I learnt most of it from his
posts and followed his recommended readings :).
I hope this helps,
Dan
Yes, this helps big time!! Thank you!
Mike
===
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
Re: Model 2, take 2
At 3/28/2000 01:04 PM -0800, Kevin Duffey wrote: Would another option be to check the current context (instead of having multiple suffixes)? (This way everything still routes thru your single controllerServlet.) Not quite sure what you mean by this. I have to admit there are still things I dont quite understand in the whole servlet model. Does the context refer to EVERY application running? Or when you get the servlet context during the init() method, is that specific to the application the init method is called in? I'm using tomcat, which comes with three contexts configured to run "out of the box." They are: 1. /examples(examples) 2. /(ROOT) 3. /test(test) I think you may be using JRun, which I haven't (really) used Does it make sense to add a parameter to the perform() function to represent the target Page? E.g. snip, snip I would think not, because how is the controller servlet going to pass the right forwarding URL to each action? I mean, what if the logic of one action class may forward to many different pages depending on the outcome of the logic? I would think the forwarding page should be defined or figured out in the action class, EJB, whatever is doing the logic. An example would be..what if you needed to go to a different page based on a STATE drop-down on a form. Each state has its own page. The controller servlet I guess could read this in from an XML file..but I think this is "logic" that shouldn't be done in the controller servlet. I was thinking that under normal circumstances there would be one (and only one) preferred next page. (The use case modelling "Happy Days" (primary) scenario.) All that you say is true and none of that would be prevented by specifying a preferred next page. Again, my goal here was to make things more configurable, rather than embedding application flow logic within a compiled Action class. Hmmmh, I can see that I'll have to give this whole area a lot more thought. Comments, anyone, on how you do this? I think of the action class objects as still part of the controller level (from Model - View - Controller). Since their role in life is to mediate between the UI the Model (your EJB objects, or, as in my case, our Corba objects, whatever). If your business logic objects have method signatures including HttpServletRequest and the like, then you're only going to be accessing them thru a web-based frontend. (Not necessarily a bad thing if you're a web developer!) Thats a good point. I am curious as to how you pass, say, the values of a form field on to the EJB (or business) layer. Do you just pass it the request object, or do you parse the request object into some intermediary object, pass that on to the business layer, and it works with it that way? Yup! The Action objects simply parse out the data and plug it in to a business object (what everybody is referring to as the bean, which gets stored in the session object). Each business object provides a thin layer over a corba object (the model components). HTH to clarify what I/we are doing. Enjoy! Mike === 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
Please help w/ Model 2 Architecture confusion!
I'm a bit confused about the implementation details of the model 2 architecture. I've read posts where people advocate the use of only one servlet, which acts as the interaction controller (a router/traffic cop). This obviously provides a centralized hook for security, error handling, etc. (Side Note: The IBM Redbook "Developing an eBusiness Application..." (SG24-5423) shows a use case model mapping to multiple servlets. Basically, each use case had its own servlet (acting as an interaction controller). This seems to have the advantage of chunking the application along use case lines allowing for good separation etc. It also doesn't preclude the redirection model) If I understand the single servlet Model 2 approach, then a single user interaction looks like this: 1. User fills out form in a jsp page (I'll call this the SourcePage). 2. User submits the page... (an http request) 3. ...to the single servlet (the routingServlet). 4. The routingServlet creates an ActionBean (if it didn't already exist). 5. The routingServlet invokes myActionBean.doWork(). 6a. If doWork() failed, then create error object, add it to the request and redirect back to SourcePage. 6b. If doWork() succeeded, then the routingServlet redirects the request to a jsp page. (I'll call this the TargetPage). My confusion lies in Who is responsible for knowing what? My guess is that the SourcePage should specify both what ActionBean will be used to process it (which was probably already instantiated with default values coming in, anyway) as well as the TargetPage. So each jsp page needs just a coupla' hidden fields, e.g. actionBean="com.foo.orderentry.OrderLineEdit" and targetPage="com.foo/OrderEntry/DisplayOrder.jsp". The TargetPage then represents the "Happy Days" scenario (where the page designer intends the application flow to go next) while allowing for the routingServlet and the TargetPage to redirect, if necessary. (Perhaps, the actionBean could be architected to specify exception page targets when not simply redirecting back to the SourcePage w/ an error) So, where have I missed the boat? Any help/comments would be greatly appreciated! TIA, Mike === 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
