As an aside and merely as a suggestion, Joel, you might want to cut out parts of the emails that are not relevant to your point. This cuts down on the size of the output stream and makes things easier to read too. See within:
<SNIP> On Fri, 11 Mar 2005 12:39:49 -0700, Schuster Joel M Contr ESC/NDC <[EMAIL PROTECTED]> wrote: > Ok, I understand. I'm just really trying to understand this. > > http://resonus.net/wiki/uploads/strutsq.jpg </SNIP> Cool. Let me stress that I am not trying to say that you or anyone else is missing in understanding. I am trying to say that there is a page-centric view of things that makes Struts hard to use, because it really is not page-centric. Sometimes I think that Craig went to page-centric JSF not merely because it was a great career move but because people could not easily or generally follow the depth of what was intended by Struts which is anythning but page-centric in my opinion. <SNIP> > Here's a link to a little picture that I put together because that happens > to be how I think. > > Please tell me what I'm missing in my understanding of what struts is all > about. </SNIP> I am not going to "tell" you anything, but here are my thoughts. <SNIP> > 1. Standard login process. > a) request to website from browser, we redirect to the login.jsp via > an action or forward. </SNIP> To be complete, which is not necessary (but why not) the opening HTML page is built by the response of a login servlet provided by a JSP page. The point is that you begin with a login page. Nothing unusual here. The login page has a form for various fields and a submit button. "Standard smandard" and nothing related to Struts here. <SNIP> > b) Submit is clicked </SNIP> The form is sent with a URL invoking a Struts protocol to use an action (i,e., Login.do) to process the request. This Action, apparently, is mapped in the struts-config.xml to an ActionForm called "LoginForm". This means, too, that Login.jsp had <html:form> etc in the JSP and uses Taglibs to automatically inialize the LoginForm from the entries on the Login.jsp page. <SNIP> > and system encapsulates the data from the > request into a form </SNIP> Into an ActionForm, yes, but not really a "form" and it is misleading to think of this as a "form". This is just a class that can be created and initialized by reflection because it follows the Java Bean Pattern. Also, this class will only need to access the data from the request which was specifically directed to this class via the Taglibs mentioned above. We might want some input items to be <html> related and some not. We may use the ActionForm to retrieve only part of the data and use other classes to retrieve other data. We also may build the ActionForm so it can utilize and work with data having nothing to do with the Login.jsp page. It is important to state just what something really is and to not be banboozled by "naming" habits. <SNIP> >which is then given to the action.execute </SNIP> The action which is referenced by Login.do, which you don't even have in your diagram, is then automatically created adn the execute method is called and the input parameters of that method intialized with the request object, the response object, the LoginForm object, and the ActionMapping object created by the <action> tag in the struts-config.xml. It is really telling, I think, that the most important part of the whole business, the Actions, are completely missing from your diagram. <SNIP> > which > c) then determines if the values are correct </SNIP> This is correct if you bypassed the input parameter of your mapping with inputForward. I assume you did, since you are saying this. <SNIP> >and forwards to the > right place depending. </SNIP> The options for forwarding in the struts-config.xml action mapping are merely aids to standard forwards which you can change in the xml but they do not necessarily indicate where the forwarding will go to. You can programmatically do anything inside the execute(...) method. We can discuss what happens here in depth, but I am going to follow your bouncing ball and assume you succeeded and when to the main.jsp which means that you returned the browser an HTML page that the servlet created by the main.jsp page built with its response object. <SNIP> > > 2. Now, If I want to have the main menu simply go from one screen to another > then I have a link. But the second screen needs to be 'populated' (for lack > of a better word) with data. </SNIP> What I don't understand here is what you want to do at the Main.jsp page. Presumably you are going to be friendly and say, "Hi, Dakota" or something acknowledging the recent activity of your successful client? Why did you not ask how to "populate" the Main.jsp page with data? Instead, you are asking about the next page. But, let's follow your example and assume that Main might as well as been Main.html. So far, nothing you have said shows why Main.jsp is not Main.html. <SNIP> > 3. To do it the struts 'way' is to link to an action instead. This action > fills the framework provided form (because it is defined in the mapping) and > forwards to the edit screen. </SNIP> I assume that your discussion here is diverging int he EditSysVars.jsp versus the EditSysVars.do options? RIght? This is not quite right. EditSysVars.jsp, the way you are talking, might as well be EditSysVars.html. Right? Just because EditSysVars.jsp is not a .do is irrelvant to most of what you are saying. We can, if we are "dumb" enough, get an ActionForm right in EditSysVars.jsp without a .do. That is what Joe was talking about, only not in the "dumb" way. At this stage, I am really getting confused, because the main pieces of the puzzle, the Actions, are missing in action. ///;-) I have no idea why GetSysVars.do is forwarding to EditSysVars.jsp. Does this mean that, I hope, that there is an UpdateAction somewhere in this mix? Where? Why is it not in the diagram? I will assume that you went to the UpdateAction from the Main.jsp html page. Why you did not discuss "populating" the page that called UpdateAction is a mystery. Do you see how I am thinking? Anyway, you used a main.jsp page to get to an UpdateAction which presumably is mapped to SysVarsForm. Is this right? Or, is the UpdateAction an EditSysVarsAction? Do you see how you continually see Actions as between forms, i.e. Main.jsp ---> GetSysVarsAction.java --> EditSysVars.jsp ???? This is really not helpful. This is really not related to the functionality. Imagine for a moment that the action is ForwardAction.java or DispatchAction.java. These actions might "stand between" numerous JSP pages. That is really not what they do. If you look at the picture I drew, which is really horrible compared to yours, that is the point, again. <SNIP> > 4. The update action uses the same form which is now filled with changed > values from the jsp. </SNIP> By now I don't know what is happening. Whare is the update action. What is the same "form". A form is not an ActionForm, you know? <SNIP> > --- I keep getting the impression that I've missed something in my > understanding of how and more importantly why --- I want to understand, not > just do things blindly. > > I understand that the ActionForm is intended to STORE and VALIDATE > USER-ENTERED data (off the struts page)... but then there seems to be a big > hole in the functionality of struts. How do you get to the point of having a > person select inventory and purchase it if you can't first display that > inventory? </SNIP> "[O]ff the struts page" really should be "from Struts tags". There may be lots of data from the page that is not stored or even related to the action. I know that generally I use non-ActionForm classes to store and to manipulate navigation data even though off-times this data comes from hidden or other input tags not related to <html> tags. I don't think that the ActionForm, either, is intended to "STORE" data. Rather, the ActionForm merely is passed the data from the request object via the code of the framework initiated by the <html> tags, etc. You can have one ActionForm and one Action do all the work we are talking about. And, on occasion, this might be the best thing to do. For login and update system administration things, I often use a single subclass of something like DispatchAction to farm out work to helper classes called by various methods with a single ActionForm as well relating to these helper classes. If you start counting Actions and ActionForms by the number of pages or anything else to do with the pages inherently as seen in some simple time flow, then you are treating them in a very PROCEDURAL fashion which is way too limiting. Does this help? Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
