Our Ajax UIs are by default asynchronously. That is, rendering the page or executing scripts does not stop when calling a service to get some data. Most of the time this is very useful but it might sometimes be very confusing as well our support cases show again and again.
For example, assume a service is called in a script (serviceCallByScript=true) and the service call binds its output to a controller attribute. Right after the call we want to use this attribute and wonder why it’s undefined. If isAsynchronous is true – which happens to be the default value – the reason might be that the service call didn’t return yet. This problem might be solved by just setting isAsynchronous to false (for more details see http://wiki.e2e.ch/E2EDOC/Service+Calls).
Does anybody know other pitfalls we should be aware of?
I stumbled over a pitfall that cost me some valuable time during a proof of concept:
A comma-separated file is processed within the E2E Bridge. If any error happens during validation or processing, an operator may edit the file within an E2E User Interface.
The full file content is displayed in a text area. The operator can edit and submit the content.
When submitting, the browser removes any linefeeds in the file – the content arriving on server side is all in one single line, thus the flat file adapter has troubles parsing it into a useful structure.
Solution (proposed by Marcel – thanks again):
this.editedPayload = $("#ID::textArea").val().replace(/r?n|r/g,"EOL");
Postprocess the content before feeding the flatfile adapter using an ActionScript:
local lineFeedsRedone= editedPayload.replace("EOL", text("n"));