Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Component/s: ICE-Components
-
Labels:None
-
Environment:renderer + effect related JS handlers
Description
Currently the renderer of the component writes the JShandler, and then the following call rewrite them again. Which means it can re-invoke the value binding if exist.
LocalEffectEncoder
.encodeLocalEffects(uiComponent, attributeElement, facesContext);
LocalEffectEncoder
.encodeLocalEffects(uiComponent, attributeElement, facesContext);
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Maybe the renderer could pass in a Map of what it wants to render to LocalEffectEncoder, where a map entry would look like "onclick" -> "iceSubmitPartial(...)". These could be statically defined, or dynamically generated if necessary.
LocalEffectEncoder could iterate over all the typical events, and combine the effect + user + framework Javascript, based on the on*effect attribute, the on* attribute, and the Map, respectively.
Also, it looks like some renderers invoke it directly, while it's also called from PassThruAttributeRenderer.renderHtmlAttributes, so we should probably make we're not double-invoking it that way too.
Show
Mark Collette
added a comment - Maybe the renderer could pass in a Map of what it wants to render to LocalEffectEncoder, where a map entry would look like "onclick" -> "iceSubmitPartial(...)". These could be statically defined, or dynamically generated if necessary.
LocalEffectEncoder could iterate over all the typical events, and combine the effect + user + framework Javascript, based on the on*effect attribute, the on* attribute, and the Map, respectively.
Also, it looks like some renderers invoke it directly, while it's also called from PassThruAttributeRenderer.renderHtmlAttributes, so we should probably make we're not double-invoking it that way too.
This optimization has been made to the following priority components: