Browser incompatibility issue using JS in taskforms

[gerardo1]

Hello everyone,

I hope that I'm in the right forum. I have a problem concerning the execution of taskforms in different browser.

I have a taskform that contains javascript code and is referenced by a userTask in a test process:

<h1>Handle Form</h1>
Usually the selection box shows "Misuse" at first.<br>
The aim of the javascrippt is to change this selection. After the execution of this form "Settings" should be selected.<br>
But in order to test the compatibility between different browser, we only use the alert-command.
<hr/>

<p>
   <b>Classification:</b><br/>
   <select id="classificationBox" name="issueClassification">
      <option value="misUse" selected>Misuse</option>
       <option value="settings">Settings</option>
       <option value="technicalProblem">Technical problem</option>
      </select>
</p>

<script type="text/javascript">
   alert("Hello");
   
   // To change the selection I use this code.
   // YAHOO.util.Dom.get('classificationBox').selectedIndex = 1;
   
</script>

At first I run the process using the Firefox Browser. When I open the taskform in order to complete the userTask, a new Window appears saying "Hello". That's what I want.

Now I run the same process using Internet Explorer 8. Nothing happens when the taskform open. No new Window. No "Hello" :-(. It seems like the Internet Explorer doesn't evaluates the embedded script.

I also tested the process using IE 7 und Google Chrome. And again. No new Window. No "Hello".

Maybe someone could give me a hint where the problem could be. Or, maybe some of you know how to do it not using javascript.

I attached an eclipse project containing this test.

Thanks a lot,

Gerardo

[davidcognite]

Hi Gerardo,

The reason that your code isn't running is because the forms are loaded via an XHR request (AJAX) and most browsers don't execute script tags contained in an XHR response. That's a general policy from the browser vendors rather than something we're specifically not supporting in Activiti. There are work arounds, but they involve creating a callback method that searches through the nodes in the response body and eval()s each script tag, which isn't something we've got any plans to do.

Returning to the initial problem: are you trying to change the default option in different scenarios, or do you always want "Settings" to be default?
If it's the latter, moving the 'selected' HTML attribute would solve that easily.

HTH,
David.

[gerardo1]

Hello dwebster,

thanks a lot for this advice. I'll try to implement your idea.

Some information concerning the scenario: The preselected option depends on a process variable. The html option tag doesn't have an attribute that defines the preselected option, e.g. <select id="…" selectedIndex="2". That's why I have to use the JS workaround. If you know such an attribute. Then there would be no problem.

Thanks for your help.

Greetings,

Gerardo

[davidcognite]

Hi Gerardo,

I'm not sure how you could use a process variable to manipulate the HTML of the form, which is really what you're after, since the forms are static rather than parsed in any way.

The HTML option tag has the 'selected' attribute, used as either "selected", as in your option above, or "selected='selected'" which indicates that it should be the preselected option, but without the ability to alter the HTML based on the process variable, this attribute is little help in your scenario.

David.

[bernd_ruecker]

Hey guys.

Just as a remark: From the user perspective the selected attribute just means to show some process variable to the user (but in a select box instead of a text box), that should be possible in my opinion. Maybe if that is a hard problem to solve with the form capabilities we should move that thread to the dev forum and discuss there how to do it?

Cheers
Bernd

[gerardo1]

Hi guys,

I find a solution for my problem. I add a JUEL-Expression, which looks like this:

<p>
<select name="issueClassification">
    <option value="misUse" ${(issueClassification == 'misUse' ? 'selected=\'true\'' : ' ' )}>Misuse</option>
        <option value="settings" ${(issueClassification == 'settings' ? 'selected=\'true\'' : ' ' )}>Settings</option>
        <option value="technicalProblem" ${(issueClassification == 'technicalProblem' ? 'selected=\'true\'' : ' ' )}>Technical problem</option>
    </select>
</p>

So, the process variable issueClassification is set before the taskform is presented and contains one of the three values: misUse, settings, technicalProblem.

I must say that I don't like this solution, because the JUEL expression are not intended to be used for the manipulation of html code in this way. But finally it works ;-D.

Thanks for the help David. Greetings,

Gerardo

[bernd_ruecker]

Hmm, why shouldn't that be not be intended to be used for that? I think it is the correct solution to use server side form evaluation with expressions to create a HTML you need for the GUI. Or not?

[tombaeyens]

@Bernd, afaict, at the server side there is only juel rendering.  there is some extra logic at the client side that interprets the extra meta data in the hidden fields and enhances the UI experience a bit with some javascript.  so there is no other server side evaluation then juel rendering of the form.

[bernd_ruecker]

I think the JUEL server side rendering is sufficient for most of the cases. As far as I understood the explanation from Nils we are limited in the form client java script to anything offered/pre-built by the webapp (like the date picker). If that is powerful enough, I think we can live with that limitation for now.

But I still think we need a baseline decision: Fully fledged powerful enterprise ready task list component or prototyping play-around webapp…

[erikwinlof]

What I think we shall support thought is the possibility to use <script> elements and make sure they are executed in all browsers, its a very easy fix to do and will make it possible to provide more advanced functionality if someone wants to go down that route. We shall also think how we can support this type of functionality without turning the .form-definition into a hacky javascript file.