Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Beta2
-
Fix Version/s: 2.0.0
-
Component/s: ACE-Components
-
Labels:None
-
Environment:ICEFaces ACE components
Description
I've noticed this issue on the LinkButton, but it should manifest in all ACE components under the right circumstances.
The HTML structure built by the renderer encapsulating a LinkButton looks like this:
<div>
<span id="xxx_span" >
<span class="first-child">
<a> A child node </a>
</span>
</span>
<span id="xxx_script">
<script> Yadda </script>
</span>
</div>
The problem occurs when there is some behaviour that changes the markup in the span with the id "xxx_span", "first-child", or the anchor tag. The reason is that our dom-diffing algorithm finds the first parent element with an id and applies an update to that element. This excludes the javascript span and the <script> element is not reevaluated by the client.
In the case of LinkButton, my test page changes the style string on one of the inner spans of the anchor hierarchy. It's necessary to change the style on this level or it wont override the default Sam or Rime styling, and this sends an update of just the inner <span> tags which causes the YUI component that was created on the initial update to be replaced with simple html since the initialize method in the javascript is not re-executed. This manifests most visibly when the linkButton value attribute is replaced on the link with the normal html value of: "A child node", in the above case.
The component renderer is going to need to keep track of elements and attributes which are on the innermost elements of a nested component structure, and if they change, going to have to write something in the javascript layer to get it to be updated as well, so the entire structure can be re-bound to a YUI component.
As a first pass we might be able to pass these elements into jsfProps directly, ensuring the javascript changes as well. If this gets to be too large, a concept similar to the JSONBuilder class might be used to accumulate all the string changes into one long string which then we take a hash of to make it a reasonable size.
The HTML structure built by the renderer encapsulating a LinkButton looks like this:
<div>
<span id="xxx_span" >
<span class="first-child">
<a> A child node </a>
</span>
</span>
<span id="xxx_script">
<script> Yadda </script>
</span>
</div>
The problem occurs when there is some behaviour that changes the markup in the span with the id "xxx_span", "first-child", or the anchor tag. The reason is that our dom-diffing algorithm finds the first parent element with an id and applies an update to that element. This excludes the javascript span and the <script> element is not reevaluated by the client.
In the case of LinkButton, my test page changes the style string on one of the inner spans of the anchor hierarchy. It's necessary to change the style on this level or it wont override the default Sam or Rime styling, and this sends an update of just the inner <span> tags which causes the YUI component that was created on the initial update to be replaced with simple html since the initialize method in the javascript is not re-executed. This manifests most visibly when the linkButton value attribute is replaced on the link with the normal html value of: "A child node", in the above case.
The component renderer is going to need to keep track of elements and attributes which are on the innermost elements of a nested component structure, and if they change, going to have to write something in the javascript layer to get it to be updated as well, so the entire structure can be re-bound to a YUI component.
As a first pass we might be able to pass these elements into jsfProps directly, ensuring the javascript changes as well. If this gets to be too large, a concept similar to the JSONBuilder class might be used to accumulate all the string changes into one long string which then we take a hash of to make it a reasonable size.
Issue Links
- depends on
-
ICE-6418 PushButton updateProperties javascript call never applied
- Closed
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion