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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
