> > 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.
ok, from your later answers to Andrew I understand now how you want to do this - je suis d'accord, sounds like a very good solution. This won't help Andrew again, if he doesn't use Trinidad messaging. Couldn't Andrew queue the message region in a phase-listener using the renderContext as a partial region, bingo, he wouldn't need his custom component anymore? > > 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). I think my suggestion above might help. > > 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. and again, see above - if he manually queues it, nobody has to list the components. By the way: it should be easy to visit the tree in JSF, then this wouldn't be so much of a hack, only costing a bit performance. I've added an issue on this to the spec issue tracker an age ago, we have to fix this for 2.0. > > 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. the parent thing is still interesting for me - I wonder if this would require a new component, or if we could eventually use special syntax in partialTriggers="id/*" or so? > > 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. Ok, I think with my above suggestions, Andrew will conclude that he doesn't need UIXPartialRendered - I think the partialTrigger component will still be necessary. regards, Martin
