Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Beta2
-
Component/s: Framework, ICE-Components
-
Labels:None
-
Environment:icefaces2, ace
Description
With AJAX, there are problems when modifying the <head>, that necessitate techniques to avoid doing so. With ICE-6047, we solved an issue where a postback could cause an ice:gmap component to become rendered, and in doing so, modify the head, as its javascript resources become added to the head. The solution for that was to recognise when the ice:gmap component was in a JAR in the WAR, and thus had the potential for being in the application, then, via a config param, allow for its resources to always be in the head. This was done by annotating the GMapRenderer, so it's self-describing, and there's no central list of components being reflectively sought.
Now, consider the ace components, which each have many resource dependencies, which would modify the head if the components were dynamically ui:included, or their rendered property were toggled. So, we want to annotate them so that when the ACE JAR is in the WAR, their @ResourceDependency annotations will always be processed, whether they're in the view yet or not.
Now, consider the ace components, which each have many resource dependencies, which would modify the head if the components were dynamically ui:included, or their rendered property were toggled. So, we want to annotate them so that when the ACE JAR is in the WAR, their @ResourceDependency annotations will always be processed, whether they're in the view yet or not.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
One lingering question is whether all the Class.forName() code should be done once in the DOMRenderKit, instead of per lifecycle in BridgeSetup. Just not sure if we want to classload the component during the RenderKit processing. If it's alright, it would be more efficient. Perhaps if that logic were moved into DOMRenderKit, then it would be easy to switch when it happened, on list creation, or list retrieval.
Show
Mark Collette
added a comment - One lingering question is whether all the Class.forName() code should be done once in the DOMRenderKit, instead of per lifecycle in BridgeSetup. Just not sure if we want to classload the component during the RenderKit processing. If it's alright, it would be more efficient. Perhaps if that logic were moved into DOMRenderKit, then it would be easy to switch when it happened, on list creation, or list retrieval.
Committed the ace component Renderer classes, with their @MandatoryResourceComponent annotations.
Subversion 22827
Show
Mark Collette
added a comment - Committed the ace component Renderer classes, with their @MandatoryResourceComponent annotations.
Subversion 22827
There should be no problem with classloading the components in the DOMRenderKit – this is a small number of classes compared to what is otherwise required to start the application.
Show
Ted Goddard
added a comment - There should be no problem with classloading the components in the DOMRenderKit – this is a small number of classes compared to what is otherwise required to start the application.
Added processing in DOMRenderKit to scan for new MandatoryResourceComponent annotation on Renderer objects. If they're found, add the component class name from the annotation to a list, which BridgeSetup retrieves on each lifecycle.
Original strategy was to instantiate a dummy instance of each component, and temporarily add it into the component tree, hoping that would trigger its @ResourceDependency / @ResourceDependencies processing, so the internal JSF mechanisms would handle the resource adding. This didn't work. I didn't really have time to investigate why. So, I fell back to Plan B, which was to process the @ResourceDependency / @ResourceDependencies annotations right in BridgeSetup. Found out that our code had to handle the case where the target is null, and needs to be defaulted to "head". Also found a way to get JSF to automatically handle javascript and CSS files, without us having to parse that out ourselves. Finally, added redundancy culling, so that all the redundant resources, which multiple components require, will only be added once.
Subversion 22825