Re: AjaxModalDialog.close(context()) being ignored
Re: AjaxModalDialog.close(context()) being ignored
- Subject: Re: AjaxModalDialog.close(context()) being ignored
- From: Chuck Hill <email@hidden>
- Date: Fri, 4 Feb 2011 09:59:12 -0800
On Feb 4, 2011, at 3:02 AM, Paul Hoadley wrote:
> On 03/02/2011, at 7:13 AM, Chuck Hill wrote:
>
>>> Meanwhile, I've stumbled across what is presumably the relevant difference in the action methods: the problem button's action method sends some emails using (indirectly) ERMailDelivery. At some point a WOComponent is created (even for plain text mails—good templating system), for example:
>>>
>>> SuccessTextEmail component = ERXApplication.erxApplication().pageWithName(SuccessTextEmail.class);
>>>
>>> Commenting out the component creation (and returning some dummy text instead) lets the AMD close as intended. Is this component creation messing with the operation of AjaxModalDialog.close(WOContext)?
>>
>> As Timo pointed out, that will mess up the current context. It might also mess with the response. That is probably causing this code:
>>
>> currentDialog(context).closeDialog();
>> AjaxUtils.javascriptResponse(AjaxModalDialog.Close, context);
>>
>> to send back an unusable response. I would be interested to know what is getting sent back to see if we can find a way to get the AMD to play nice.
>
> If I'm reading Firebug correctly, clicking the action button sends a POST request, and the server responds with the content generated by the SuccessTextEmail component (!), and finally "AMD.close();". Obviously sending back the email content is completely wrong, and presumably the JS interpreter barfs before it can execute AMD.close(), though interestingly I can't find any complaints about that anywhere.
I think it interprets the "AMD.close();" as text. It depends on what the content-type is. That should be wrapped in <script>...</script> for an text/html content type.
> Chuck, if this is interesting to you, I can certainly do some more testing, though I'm happy with Timo's solution. I'm not really looking at a _bug_ of any sort here anyway, am I? These email-generating components are used completely behind the back of the browser, so I should have known to clone the context in the first place. It's a bit much to expect this _not_ to cause problems the way I was doing it, isn't it?
The bug, if there is one, is that the Ajax framework is not wrapping "AMD.close();" in script tags. The code in question is in AjaxUtils:
public static void appendScriptHeaderIfNecessary(WORequest request, WOResponse response) {
if (AjaxUpdateContainer.hasUpdateContainerID(request)) {
AjaxUtils.appendScriptHeader(response);
}
else {
response.setHeader("text/javascript", "Content-Type");
}
}
It is looking for an update container ID where I thought I was looking for a content-type. We could add a check for existing response content and type, but maybe it is better to just file this under "don't do that!". :-)
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden