Andrew, This is a bit overmuch - it isn't a "thumbs-up/thumbs-down" process, where we take it as is or leave it. It's a collaborative design process. We discuss, we hopefully come to consensus. Calling for a vote up front is unproductive.
And there don't need to be "fatal flaws", and we don't all need to have read the component's source code. We might just think that on the whole we're unhappy with the direction, or would like to be more conservative in adding functionality. Check out how Danny Robinson has been approaching his suggested component additions. More comments embedded. On 9/4/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > 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. That could be used to justify any component being added, and in itself is not a valid reason for adding it. Can you appreciate the advantage in going slow on component additions? > (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. I'd really like to hear a concrete example of where this is absolutely necessary. This is a very abstract description that is mostly "I need functionality X because I need to do X", which is a tautology. It's also very difficult for me to judge why this component needs to support "immediate" at all (should it always be immediate="true"?). > 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), Are you aware that partialTriggers is recursive? So that you could have: <af:group id="pprGroup" partialTriggers="menuItem1 menuItem2 menuItem3"/> <af:outputText partialTriggers="pprGroup"/> IMO, this makes this sub-feature unnecessary. > 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. This is an interesting use case, but couldn't you just expose a partialTriggers attribute on the facelets template and let the template support this? > 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. BTW, looking at the code, there's also in "alwaysRendered" flag that we should talk about. I'm uncomfortable with adding it to this, and only this component, and similarly uncomfortable with adding this to all components. In a complex application, it seems undesirable that you'd always re-render any specific component, since you don't know all reasons why there might be a postback (someone adds a poll, or an autoSubmit, and now you're repainting unnecessarily). There are workarounds for any odd scenarios where this really is absolutely needed (e.g. f:phaseListener and "binding" in JSF 1.2). -- Adam > > 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 >
