On 9/7/07, Martin Marinschek <[EMAIL PROTECTED]> wrote: > @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.
I want to get rid of that hack on messages; we have the underlying technology to do so. > You can't force him to > use Trinidad-components only, and we all should make sure we don't do > so. I'm underwhelmed by claims that this is solely Trinidad's fault; it's not as if A4J's PPR solution doesn't break Trinidad in some major ways! And Trinidad's general solutions are in fact *really, really good* at supporting third-party components - any component can be added as a partial target as long as it follows some trivial and reasonable JSF guidelines (basically appropriate use of ResponseWriter). > 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. You'd have to find such components, which would generally involve a full walk of the tree, unless you'd pre-gathered them on the prior render, which is quite a hack. > 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. I agree there's some value, but I'm trying to boil this all down to *exactly* the functionality required, as it's felt to me like at least 50% of what's asked for here is not the right way to go. Once we know exactly what is really, truly the right set of functionality to add, then we can design how it best belongs. > 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. We have a tr:group component that has no layout at all, but could very plausibly be used for some of this. -- Adam > > 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 >
