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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Enviado el: viernes, 06 de febrero de 2004 16:40
Para: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
Enviado el: viernes, 06 de febrero de 2004 16:07
Para: 'Mailing List [EMAIL PROTECTED]'
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
