Adam and the Trinidad developers, As for these two components, they are simply utility components to provide users more flexibility in the ways they wish to use the trinidad tools. Both of them do not affect the framework of Trinidad and are optional if people want to use them or not.
(As requested by Adam, I'm giving all a chance to vote. Please vote below) 663: The UIXPartialTrigger component does exactly what Adam suggested in one of his responses to my email regarding the inability to partially render a component based on a trigger of a UIXCommand component, but never has a chance to broadcast that event due to a shortening of the JSF lifecycle. His suggestion was to make the FacesEvent immediate in nature so that the event will be broadcast earlier. This new component allows the component user to trigger partial rendering with immediate affect without changing the immediate property of the UIXCommand which would break code by JSF phases that are quite necessary for JSF programs to function correctly (the need for immediate on a command is a very specific use case and should not be over used). By implementing the queuing of its own event when a child component queues an event, users may choose to have parent components ignore the queuing of this event if they so desire. In addition to the immediate flag, it also provides two other helpful functions: 1) The ability to trigger off of one parent component. For example: I have a menu that I am building and I am using the tomahawk panelNavigation2 component. I am using this over the tr:panelNavigation because the Tomahawk one currently provides the extra functionality that I required (static children mingled with dynamic children and multiple level support). In this code, I have many <t:commandNavigation2> components and some dynamic components. Now I could produce something like: <tr:ouputText partialTriggers="menuItem1 menuItem2 menuItem3 ..." /> But this is problematic. For one, there is no way that I can designate the dynamic triggers that are rendered as I do not know their IDs, and two, I have to maintain this list in both places (every time I add a new menu item, I have to fix the partialTriggers all over every one of my pages that listen to the menu items), This new component allows me to: <tr:ouputText partialTriggers="menuItems" /> <tr:partialTrigger id="menuItems"> ... any number of menu items here or other components that will fire events that should cause a partial trigger ... </tr:partialTrigger> 2) The ability to specify a region to update from a component instead of having to specify listeners. Many, if not all the other AJAX libraries use this approach of a "what to re-render when this is clicked" type of functionality. If that isn't reason enough, I submit this use case of why it is desired as a component user: A user of facelets creates a template with a control. Since this template can be used from any other facelets page, there is no way for the author of the template to know the possible component IDs that may trigger it to be partially updated. On the other hand, the developers of the pages that use this template are in full knowledge of what components would need to force this template component to update. For this reason, this piece of functionality is required to have PPR usable in a complex view environment. 664: The UIXPartialRendered gives people the ability to add partialTriggers functionality to any non-Trinidad component. I don't see why this isn't a desired component. This allows quick 3rd party integration of components into a project using Trinidad and give them the ability to support partial updates without the application developer worrying about writing their own component library to wrap a 3rd party one just to be able to re-render. Yes, it would be possible to put a parent component in the hierarchy, but this does not work without affecting the rendered HTML. By using a parent component, a DIV or a SPAN would most likely have to be rendered, which is not necessarily what users will want to have happen. The UIXPartialRendered works with no changes made to the output HTML. The only requirement for these supported components, is the requirement that Trinidad already has for requiring that the component write a client ID in an element so that it can be found in the page and replaced during the partial update on the client. Vote: 663 - UIXPartialTrigger: [ ] +1 - For people that have read the components code and documentation and feel that component should be left in 1.0.3 of Trinidad [ ] 0 - no opinion on the matter [ ] -1 - For people that have read the components code and documentation and see fatal flaws in the design of the component and the reason why this component should not be included in 1.0.3 of Trinidad. 664 - UIXPartialRendered : [ ] +1 - For people that have read the components code and documentation and feel that component should be left in 1.0.3 of Trinidad [ ] 0 - no opinion on the matter [ ] -1 - For people that have read the components code and documentation and see fatal flaws in the design of the component and the reason why this component should not be included in 1.0.3 of Trinidad. Thank you, Andrew
