On 9/7/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > 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.
Yeah, true, but it doesn't seem like adding a Trinidad component
because people aren't willing to use the Trinidad tr:message component
is pushing things. I'd be vastly less concerned about seeing such
a component appear in a generic MyFaces PPR/AJAX library, when
we get around to that, 'cause then things are eminently balanced -
the base library has a lot of primitives, individual consumers
(like Trinidad) can make those primitives unnecessary. This is
a lot like how I imagine things will be with ICEFaces in JSF 2.0,
FWIW - core AJAX primitives that ICEFaces makes unnecessary
'cause of its cool diffing approach.
> 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?
Yes, as long as this isn't a really common requirement that
hits most developers, at which point the phase listener
becomes a bit of a pain.
> > > 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.
Yep.
> > > 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.
Yep, though it lacks the prettiness of something more automatic.
> 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.
I'd love easier APIs for tree-walking; but a full tree walk
is always going to be potentially expensive, since walking
into components like tables can trigger model queries. We
also have some components inside Oracle called regions
(little sub-applications within pages) that you'd have to walk
into, and those aren't cheap. Not saying that we *don't*
want these APIs, but we have to be really careful about
how they designed. For instance, I suspect we'd want
to make it easy to allow multiple requests for tree walking
to be aggregated into a single walk.
> > > 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?
A special syntax would be very worth considering. The
parent-of-unknown-contents is the one I'm most convinced
deserves a solution.
> > > 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.
I guess my component naming concern is that I can't remember which
is which. :) I'd rather think of this as a basket of requirements, which
we could then allocate to components (or to new partialTriggers
syntax, new JSP tags, etc.) once we've agreed on a list of
requirements that we have to nail. So far, I think Andrew's list is:
- Trigger PPR from a parent when any child is a "PPR trigger"
General agreement that this is valuable.
- Trigger PPR when a message is queued for a component
I want to rely on DHTML for this instead of PPR, at least
for the Trinidad components.
- Push triggering instead of pull ("partialTargets" instead
of "partialTriggers")
Very interesting question, I'm toying with the idea
of a tag that can be attached for any event.
- Trigger PPR for a component on every request
I dislike this, as you probably have surmised. :)
Have I omitted an item from this list?
-- Adam
>
> regards,
>
> Martin
>
