struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <shirishchandra.sakh...@ubs.com>
Subject RE: Back to the originating screen...
Date Fri, 13 Feb 2004 17:22:29 GMT
Hi,
Had almost forgetten about your mail :-((

We have following action hierarchy.
     AbstractApplicationAction(As per struts best ├╝ractice 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 that 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 is 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 presses update,UseDetailsUpdateAction  will
be called.It will update the details 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 tomorrow if after some other
functionality(Placing an order for example),the suer needs to be shown his details page,then
just make that other actions success forward to point to UserDetailsOpenAction .And if the
actions are so atomic, changing teh screen flow is just like attaching together different
actions is struts-config by using proper forwards(the assumption 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 having them as attributes) and the same can be  passed to jsp either
as text 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 paradigm, and the general
GET/POST philosophy you applied. The "Changing Language" functionality would be a good example,
although I've thought about another one that I'm also interested in:

There is a login screen. The user logs into the system, gets "redirected" to the "List of
Products" screen where the paginated list of products is shown. That screen allows the user
to filter the list by specifying 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 meeting the search criteria.
The last setting for all search parameters MUST be visible AFTER the search 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 Action. 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.com] 
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 Language 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=struts-user&m=104427309720653&w=2

This thread might be of interest to you.Especially the defference between action chainning
and Action relay...

A bit under pressure today.But definately send a detail mail by tomorrow.

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.com] 
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 careful not to redo the
last posts.

Luckily for us, the desin we had solved the problem.We have a concept of OpenAction(Actions
that prepare data for view) and Save action(Post actions,actions that update DB).So in AbstractOpenAction,
the called URL is saved in session under a specific key(Open actions always use GET.So 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 session and just forward to last action called.And
as the last action called will be always be the OpenAction which created the last screen seen
by user.So chance of a post being done again.

Some users have pointed out that having such Reusable small actions lends itself to action
chaining(e.g. To complete a user Preference save request, you will first call SaveUserPrefrrenceAction
which will then forward to UserdetaislOpenAction,assuming you are showing user details after
he saves them) And qwe had a long discussion on this forum about action 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 the 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 action 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 preserving
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 presented
         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 secondary
  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


Mime
View raw message