@Andrew: I value your contributions as very important to finally try to find ways to make JSF component libraries more compatible. The current state, and that we all agree upon, is a state we as JSF users can't take much longer.
I will not reiterate Adam's point about discussions first - discussions are absolutely necessary in an OS setting. So it is a good thing that discussions have been started. In the end, coding needs to be done, too - so it is also good that you provided some code as a base for discussion. @Adam: I have read through this mailing thread very carefully, and I do think that Andrew has some points. renderAlways: If you use renderAlways internally for the trinidad messages (even though you call it a hack now), Andrew is definitely right when he says he might want to use other message components as well and needs the same functionality there. You can't force him to use Trinidad-components only, and we all should make sure we don't do so. You might also be able to provide this functionality in a partial life-cycle setting, too - if you can rerender the triggered components, why can't you render a list of always triggered components as well? It might be more work to find a solution for this, though. partialTriggerering by parent component id: I believe this might help users who find it overly complicated to write an action/actionListener/valueChangeListener to queue a list of regions for partial re-rendering using the render-context, as they currently would have to do as a work-around. I also think it would make the Trinidad PPR approach generally more flexible. generic UIXPartialRendered/UIXPartialTrigger: the most used PPR library currently out there is AJAX4JSF - AJAX4JSF uses this paradigm. I wonder why you are so much against using a similar concept in Trinidad. Andrew is absolutely right, it would help a lot to convince people to use Trinidad PPR fully, also with other components, and wouldn't cost much, also not in maintenance. For the UIXPartialRendered, you could surely win me over with argueing that you could always use a tr:panelGroup (if there is one) as a UIXPartialRendered which (at least the standard h:panelGroup doesn't do so) won't render a <SPAN/> if not necessary. But hey, I've always found it a bit strange to use something like an <h:panelGroup> for anything else but layouting. regards, Martin On 9/7/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > Adam, > > To put it a little more politically correct, I think it is very > important to have the PPR/AJAX function of Trinidad viewed as > completely separate functionality from the Trinidad components. In the > same way that decisions by RichFaces developers does not limit > Ajax4JSF functionality, I don't feel that Trinidad components should > limit Trinidad PPR functionality. > > If a user must choose RichFaces+A4J, ICEFaces or Trinidad to get PPR > functionality since the libraries really are not compatible, I think > it is extremely important to ensure that the AJAX functionality that > Trinidad uses should be as portable and feature rich as possible to > allow users to integrate more than one library at a time (facelets and > seam are examples of very popular frameworks that have components). > > I think this is also a very good reason why I proposed, and at the > time you agreed, that the PPR/AJAX functionality should be extracted > from Trinidad and made part of a MyFaces AJAX commons library. > > With this in mind, I think the PPR functionality in Trinidad should be > designed for all JSF development scenarios, and not just ones that > only apply to Trinidad components. > > So when you said that it wasn't important that seam:validation, > seam:validateAll and seam:decorate functionality should not be > supported by Trinidad PPR, because Trinidad components would not > benefit from that functionality just because most users that use > Trinidad components, use client-side validation, it is almost like you > are saying that users have to choose either 100% Trinidad components, > or not to use Trinidad at all as the message that is coming across is > that the Trinidad developers will not support functionality that > doesn't apply to most of the Trinidad component use cases. > > The tr:partialTrigger component's functionality is primarily for usage > with server-side validation, not JavaScript validation. It is very > important to have this functionality for users that will be using 3rd > party validators, and 3rd party components, as witnessed by the Seam > components I just listed. > > Also, I have mentioned several times a use case of requiring server > side validation for validation of database uniqueness of fields (like > user name), but you have never responded to that, but instead keep > going back to client-side validation. How do you propose to handle > database-based JSF validators with PPR? > > In summary, my point is that I believe tr:partialTrigger provides > required functionality for a complete AJAX library. I also would like > this project to invest some time and research into providing more > robust AJAX support that is similar in nature to some of the A4J > functionality (like the A4J support component's attributes in > particular). > > If we could get to more of a model of: > > MyFaces AJAX > - used by: > - Trinidad components > - Oracle rich client > - Tomahawk > - Sandbox > - Tobago? > > I think that a MyFaces custom component solution will become a lot > more appealing to people wishing to build a new JSF project. There has > been a lot of evidence that users do not feel that the PPR in Trinidad > is on the same playing field as A4J. Adding the missing functionality, > and making Trinidad's PPR functionality usable by all component > frameworks that wish to use it would go a very long way to making > Trinidad more ubiquitous. > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
