Frank,
Thanks again. I ran around into another problem trying to implement this
delete functionality. My member details (single delete) screen actually has
3 buttons for Update, Delete, Cancel. On this JSP my default action is
/update in the form tag. But when I display my Delete button I am saying
onclick call a Javascript function and trying to submit the form to a
different action (i.e., /delete). Apparently, its not picking up the action
and throwing a Webgroup not found error.
My JS function is
function callDelete()
{
document.forms[0].action="/deleteRegistration.do";
document.forms[0].action.submit();
//alert("delete called");
}
and my jsp part is
<html:form action="/editRegistration"
onsubmit="validateRegistrationForm(this)">
.
so on..
.
<html:submit property="submit">
<bean:message key="button.update" />
</html:submit>
<html:submit onclick="javascipt:callDelete();">
<bean:message key="button.delete" />
</html:submit>
</html:form>
I've seen solutions saying adopt LookupDispatch Action and all, but I think
it can be acheived using JS too. Just wondering if Struts allow this or not.
Gnan
-----Original Message-----
From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 29, 2004 12:59 PM
To: Shabada, Gnaneshwer
Subject: RE: R: Detecting the previous JSP
Yes, I think two different mappings is not only a good idea, but is
required. If we assume there's no way (aside from manually passing some
flag in with the request) of determining which JSP it came from (and I'm
almost completely certain that's the case), then the only way I believe to
differentiate where the request came from is by looking at the mapping
that was called. If you call the same mapping from both screens,
obviously you can't make that determination. There's of course no problem
with two different screens referencing the same mapping, but for your
purposes I think they do have to be different.
If you really do want to use the same mapping for whatever reason, you
could simply add a query string to your form submissions (or link targets,
whichever your using). That way it's slightly more obvious what your
doing. For instance, you could have in your JSP's:
<a href="doDelete.do?srcJSP=page1">
and on the other:
<a href="doDelete.do?srcJSP=page2">
Then you can point your mapping to the same Action for both, and just grab
the srcJSP parameter from the request, do your comparison and delegate
appropriately. I'd personally have the two different mappings because
then if you need to change something later it's just a config file entry
rather than touching code (even if it is just a JSP). On the other hand,
doing it in the JSP like that means you can make the change without
restarting your app, which you'd have to do for the config file change to
take effect... <sarcasm>Don't you just love when a simple question has
such a straight-forward answer?!?</sarcasm>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, September 29, 2004 12:46 pm, Shabada, Gnaneshwer said:
>
> Ok. I totally agree with you. I like your idea better than DispatchAction
> bcuz first I am delegating my delete functionality to a facade based on
> the
> delete type and that runs only a couple lines of code. Making it Dispatch
> Action is a whole new ball game I think..
> So, but now in my config I have only one Action Mapping say "/delete"
> pointing to my DeleteAction class. I was under assumption that I could
> call
> the same mapping from both the single delete screen and multiple delete
> screen. Do you think it's a good idea to have another mapping pointing to
> the the same DeleteAction class for multiple deletes and then use your
> logic
> to determine the mapping although the action they both point to is the
> same.
>
> Thanks much.
>
> -----Original Message-----
> From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 29, 2004 12:24 PM
> To: [EMAIL PROTECTED]
> Subject: Re: R: Detecting the previous JSP
>
>
> Thanks for forwarding to the list. There is a problem with the webmail
> interface I am forced to use from work, and my posts to the list get stuck
> in moderation, so I appreciate it!
>
> The DispatchAction might work, true enough, but to me it feels a little
> heavier than it needs to be...
>
> I am making the accumption that you have a single Action (I think you said
> that actually), but you have two different Action Mappings that point to
> it, one for the single delete and one for the multiple delete... It seems
> to me, assuming that is correct, that what I suggested might be easier. I
> personally prefer to see code in front of me when it's only a couple of
> lines, rather than having to look through a class hierarchy to find
> functionality in a parent class.
>
> With that in mind, just doing a quick IF based on the value of the path
> variable you get from my line of code, to me, feels more straight-forward.
>
> I guess what might make a different is what your Action really looks
> like... What I mean is, if it's just delegating to a bean to do the actual
> deletion, and maybe it delegates to one vs. another depending on whether
> it's a single or multiple delete, I would personally definitely go with my
> suggestion. But, if you instead have all your functionality in the Action
> (ignoring for a moment whether that's a good idea or not in the first
> place!), and your going to switch between one code block or another, then
> the DispatchAction might actually yield a more elegant solution.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> On Wed, September 29, 2004 12:05 pm, Amleto Di Salle said:
>> Hi,
>> As i wrote before may be the solution is to use DispatchAction.
>>
>> BR
>> /Amleto
>>
>>
>> -----Messaggio originale-----
>> Da: Shabada, Gnaneshwer [mailto:[EMAIL PROTECTED]
>> Inviato: mercoledì 29 settembre 2004 18.00
>> A: '[EMAIL PROTECTED]'
>> Oggetto: RE: Detecting the previous JSP
>>
>>
>>
>> Frank,
>> Thanks for your input. Thought I'd forward this back to the mailing list
>> so that others can view..
>>
>> Coming back to my problem. I would call the same action from two screens
>> because, they both are delete functionality. It's just I need to
>> determine in my deleteAction class if its a multiple delete or a single
>> delete based on where I am coming from. Any ideas?
>>
>> Thanks
>>
>> -----Original Message-----
>> From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, September 29, 2004 11:25 AM
>> To: [EMAIL PROTECTED]
>> Subject: Re: Detecting the previous JSP
>>
>>
>> I seem to be having trouble posting to the mailing list, so I thought
>> I'd send this directly to you...
>>
>>
>> I'm not sure you can tell what JSP you came from without passing some
>> hidden variable, but what you CAN do, wich might be just as good, is
>> determine what mapping was executed...
>>
>> In your Action's execute() method, use:
>>
>> String path = mapping.getPath();
>>
>> This will be something like "/deleteUser" if your Action Mapping was
>> "/deleteUser.do" for instance. Assuming you aren't calling the same
>> mapping from both places, this might give you what you need.
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>>
>> On Wed, September 29, 2004 11:02 am, Shabada, Gnaneshwer said:
>>>
>>> Hi.
>>>
>>> Is there any way in Struts I could determine dynamically what
>>> JSP/screen/action am coming from when I am in a certain screen. I have
>>
>>> a scenario where I can delete users from a result list page or a
>>> member details page. I want to use one action to do both. But to code
>>> my action easier I want to determine what page I am invoking the
>>> delete action. Is there anything inbuilt in Struts to determine that?
>>>
>>> Thanks
>>> Gnan
>>>
>>> =====================================================================>
>>> => This email message is for the sole use of the intended recipient (s)
>> and
>>> may
>>> contain confidential and privileged information. Any unauthorized
>> review,
>>> use, disclosure or distribution is prohibited. If you are not the
>> intended
>>> recipient, please contact the sender by reply email and destroy all
>> copies
>>> of the original message. To reply to our email administrator directly,
>>> send
>>> an email to [EMAIL PROTECTED]
>>> Toys "R" Us, Inc.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
======================================================================This
>> email message is for the sole use of the intended recipient (s) and
>> may contain confidential and privileged information. Any unauthorized
>> review, use, disclosure or distribution is prohibited. If you are not
>> the intended recipient, please contact the sender by reply email and
>> destroy all copies of the original message. To reply to our email
>> administrator directly, send an email to [EMAIL PROTECTED]
>> Toys "R" Us, Inc.
>>
>> ---------------------------------------------------------------------
>> 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]
>>
>>
>
> ========================================================================
> This email message is for the sole use of the intended recipient (s) and
> may
> contain confidential and privileged information. Any unauthorized review,
> use, disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message. To reply to our email administrator directly,
> send
> an email to [EMAIL PROTECTED]
> Toys "R" Us, Inc.
>
========================================================================
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message. To reply to our email administrator directly, send
an email to [EMAIL PROTECTED]
Toys "R" Us, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
