oh no, it's Client side. My browser gives Javascript error saying "Object does't support this property or method" on the submit line. I am starting to wonder, bcuz I've used this kind of calls in other non-struts apps so many times..or am making any obvious mistake on my JSP?
-----Original Message----- From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 3:05 PM To: Shabada, Gnaneshwer Subject: RE: FW: R: Detecting the previous JSP When you say it "blows up", do you mean your getting a CLIENT-SIDE error? I had assumed it was a server-side error. Obviously an important distinction :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, September 29, 2004 2:58 pm, Shabada, Gnaneshwer said: > > That alert line was commneted. Now, I moved it to the first line. It still > blows up on > > document.forms[0].submit(); > > -----Original Message----- > From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 29, 2004 2:53 PM > To: Shabada, Gnaneshwer > Subject: Re: FW: R: Detecting the previous JSP > > > One other thing: your diagostic alert message I think has to come BEFORE > the submit() call... I'm not 100% certain, but I'm pretty sure that line > will never be reached when you submit. This might help in figuring out > what's going on it nothing else. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > On Wed, September 29, 2004 2:30 pm, Shabada, Gnaneshwer said: >> >> 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]
