Return-Path: Delivered-To: apmail-jakarta-struts-user-archive@www.apache.org Received: (qmail 11313 invoked from network); 13 Feb 2004 17:33:44 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 13 Feb 2004 17:33:44 -0000 Received: (qmail 54819 invoked by uid 500); 13 Feb 2004 17:33:17 -0000 Delivered-To: apmail-jakarta-struts-user-archive@jakarta.apache.org Received: (qmail 54792 invoked by uid 500); 13 Feb 2004 17:33:15 -0000 Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list struts-user@jakarta.apache.org Received: (qmail 54771 invoked from network); 13 Feb 2004 17:33:15 -0000 Received: from unknown (HELO loninmrp6.uk.db.com) (160.83.52.98) by daedalus.apache.org with SMTP; 13 Feb 2004 17:33:15 -0000 Received: from sdbo1003.db.com by loninmrp6.uk.db.com id i1DHXDn3015311; Fri, 13 Feb 2004 17:33:14 GMT Subject: RE: Back to the originating screen... To: "Struts Users Mailing List" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: "Paul-J Woodward" Date: Fri, 13 Feb 2004 17:33:12 +0000 X-MIMETrack: Serialize by Router on sdbo1003/DMGUK/DeuBaInt/DeuBa(5012HF499 | November 14, 2003) at 13/02/2004 05:33:14 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N I agree. I have several 'wizards' in my site. The only sensible way I c= ould do this was to have a separate prepare and complete action. If you= want to do an operation and return to the same screen, simply define a= 'repost' action forward for the completion that forwards to the prepar= e action. Paul ------------------------------------------------------------ Global Equity Derivatives Technology Deutsche Bank [/] ------------------------------------------------------------ = = =20 To: = =20 cc: = =20 13/02/2004 17:22 Subject: RE: Back t= o the originating screen... = =20 Please respond to = = =20 "Struts Users Mailing = = =20 List" = = =20 = = =20 = = =20 Hi, Had almost forgetten about your mail :-(( We have following action hierarchy. AbstractApplicationAction(As per struts best =FCractice guidelines= ...) | |--------------------------------------| | | AbstractOpenAction AbstractSaveAction (Any action that gets data (Any action that performs update in DB= .) for some screen) The important point is the Save actions will never perform a get.So in = any action, when user updates something, then there will be generraly 2= actions involved.One action that does the update and another action th= at will get the data to be shown to the user after update screen. Usecase:UserPreferencesUpdate screen.The user is shown HisDetails after= login and he can update those by pressing update button.After update i= s successful, he will be shown same details. a:UserDetailsOpenAction extends AbstractOpenAction. This will get the user details for given user id and forward it to user= details JSP. which will show the user details to user. b:UseDetailsUpdateAction extends AbstractSaveAction This will update the user details passed and forward to success forward= (which in this case wil point to UserDetailsOpenAction ). The complete implementation will be as follows. The login action will forward to UserDetailsOpenAction upon successful = login .The user will see his details on screen aftter login.When he pre= sses update,UseDetailsUpdateAction will be called.It will update the d= etails for user and forward to UserDetailsOpenAction again, which will= show the user his updated details. As you can see, the atomic actions become realy reusable units.So tomor= row if after some other functionality(Placing an order for example),the= suer needs to be shown his details page,then just make that other acti= ons success forward to point to UserDetailsOpenAction .And if the actio= ns are so atomic, changing teh screen flow is just like attaching toget= her different actions is struts-config by using proper forwards(the ass= umption being all required parameters are being passed around) But I think the scenerio you have explained do not need 2 actions.It is= the case for just one OpenAction.(ProductListOpenAction).And the form= for this action can keep record of teh search criteria entered(by havi= ng them as attributes) and the same can be passed to jsp either as tex= t fields or hidden parameters. HTH. regards, Shirish. -----Original Message----- From: Villalba Arias, Fredy [BILBOMATICA] [mailto:fvillalba@mailext.com= ] Sent: Monday, February 09, 2004 6:59 PM To: Sakhare, Shirishchandra Subject: RE: Back to the originating screen... Yes, indeed. To be precise, I'm (more) interested in the OpenAction/SaveAction parad= igm, and the general GET/POST philosophy you applied. The "Changing Lan= guage" functionality would be a good example, although I've thought abo= ut another one that I'm also interested in: There is a login screen. The user logs into the system, gets "redirecte= d" to the "List of Products" screen where the paginated list of product= s is shown. That screen allows the user to filter the list by specifyin= g one or more filtering parameters (on that same screen) and submitting= them (by clicking a "Search" - submit - button). Initially, there will= appear all products. After clicking on "Search", that same screen is "= reloaded"; however, this time the list contains only those products mee= ting the search criteria. The last setting for all search parameters MUST be visible AFTER the se= arch has returned (i.e. the screen has been reloaded). I've already been thinking and working on this very same example and I'= ve already managed to solve it by implementing everything in the same A= ction. However, if I understood you (and the thread you told me to give= a look at), it should preferably be implemented in 2 different Actions= . Anyway, won't distract you any further. I look forward to hearing from = you again. Kind Regards, Freddy. -----Mensaje original----- De: shirishchandra.sakhare@ubs.com [mailto:shirishchandra.sakhare@ubs.c= om] Enviado el: lunes, 09 de febrero de 2004 15:57 Para: Villalba Arias, Fredy [BILBOMATICA] Asunto: RE: Back to the originating screen... Hi Freddy, I will definately glad to share my experience.If i am not mistaken, you= will like to know more about how we have implemented the Changing Lang= uage Functionality? including the concept of OpenAction/SaveAction? I will send you a detail mail.But I will also urge you to read the post= about chainning actions from struts archive. http://marc.theaimsgroup.com/?l=3Dstruts-user&m=3D104427309720653&w=3D2= This thread might be of interest to you.Especially the defference betwe= en action chainning and Action relay... A bit under pressure today.But definately send a detail mail by tomorro= w. regards, Shirish -----Original Message----- From: Villalba Arias, Fredy [BILBOMATICA] [mailto:fvillalba@mailext.com= ] Sent: Monday, February 09, 2004 3:41 PM To: Sakhare, Shirishchandra Subject: RE: Back to the originating screen... Hi Shirish, I'm really interested in this approach you mentioned. I'm a experienced= architect, yet kind of new to the Struts FWK. Therefore, I'm still in = that early stage when you try to figure out the best designs patterns /= strategies for architecting a Struts-based system. Would you be willing to share this knowledge with me? Regards, Freddy. -----Mensaje original----- De: shirishchandra.sakhare@ubs.com [mailto:shirishchandra.sakhare@ubs.c= om] Enviado el: viernes, 06 de febrero de 2004 16:40 Para: struts-user@jakarta.apache.org Asunto: RE: Back to the originating screen... Hi, We have implemented similar concept.And you are right.You have to be ca= reful not to redo the last posts. Luckily for us, the desin we had solved the problem.We have a concept o= f OpenAction(Actions that prepare data for view) and Save action(Post a= ctions,actions that update DB).So in AbstractOpenAction, the called URL= is saved in session under a specific key(Open actions always use GET.S= o the saved URL can always recreate the request if you forward to it :-= ))) and when the user changes the language, we change the language in s= ession and just forward to last action called.And as the last action ca= lled will be always be the OpenAction which created the last screen see= n by user.So chance of a post being done again. Some users have pointed out that having such Reusable small actions len= ds itself to action chaining(e.g. To complete a user Preference save re= quest, you will first call SaveUserPrefrrenceAction which will then for= ward to UserdetaislOpenAction,assuming you are showing user details aft= er he saves them) And qwe had a long discussion on this forum about act= ion chainning. So you may want to review all of this before you take this route. HTH. regards, Shirish -----Original Message----- From: Villalba Arias, Fredy [BILBOMATICA] [mailto:fvillalba@mailext.com= ] Sent: Friday, February 06, 2004 4:26 PM To: Struts Users Mailing List Subject: RE: Back to the originating screen... Hi, IMHO, this is a difficult problem to solve (100%, that is). Including t= he redo-URL on the language link is the most practical of those options= , if you are able to generate "redo-URLs" that do not "redo" the last a= ction itself but only "recompose" the current view (not that simple, I = know). Remember to be careful with issues such as redo-ing posts that, = for instance, involve persistency-related tasks. Say: "saveNewProduct".= Hth, Freddy. -----Mensaje original----- De: Jesse Alexander (KAID 11) [mailto:alexander.jesse@credit-suisse.com= ] Enviado el: viernes, 06 de febrero de 2004 16:07 Para: 'Mailing List struts-user@jakarta.apache.org' Asunto: Back to the originating screen... Hi I need a hint on how to return always to the originating action preserv= ing all input-parameters to that originating action... problem: From any screen in my application the user is allowed to change the language of the UI. He should be immediately presen= ted the same screen again in the new UI-language. So far I think I create an action (and a global forward) to change the UI-language. That's the easy part. But what strategy to use in order to be able to redo the last action before the change of language? The possibilities I thought of are: - on the language link, include always the "redo"-URL - on each primary action (actions called from the UI, opposed to second= ary actions called from primary actions...) I store the "redo"-URL in the= session. What do you do in such a case? thanks in advance Alexander --------------------------------------------------------------------- To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: struts-user-help@jakarta.apache.org --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/2003 --------------------------------------------------------------------- To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: struts-user-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: struts-user-help@jakarta.apache.org --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/2003 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/2003 --------------------------------------------------------------------- To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: struts-user-help@jakarta.apache.org -- This e-mail may contain confidential and/or privileged information. If = you are not the intended recipient (or have received this e-mail in err= or) please notify the sender immediately and destroy this e-mail. Any u= nauthorized copying, disclosure or distribution of the material in this= e-mail is strictly forbidden. = --------------------------------------------------------------------- To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: struts-user-help@jakarta.apache.org