myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
Date Wed, 05 Sep 2007 20:45:34 GMT
On 9/4/07, Andrew Robinson <andrew.rw.robinson@gmail.com> wrote:
>
> > > 663 ....
> > 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"?).
>
> <tr:partialTrigger partialTargets="myLink" /> In this case, the user
> may not want to partially update "myLink" unless there phase of the
> event being queued is fired.
>
> If this were to always be immediate, the argument could be made that
> all partialTriggers should applied immediately.


That's not a concrete example.  What UI functionality are you
trying to achieve that you cannot achieve today?

> > In addition to the immediate flag, it also provides two other helpful
> functions:
>
> > 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.
> >
>
> Yes I am aware of this feature, but with the combination of the
> partialTargets and immediate functionality that is provided that the
> tr:group component, and other Trinidad components lack. The usefulness
> of the tr:partialTrigger component can be seen for this reason. So
> yes, this sub-feature is implied by Trinidad components, but it is one
> I felt worth mentioning.


It's not a specific benefit of this component is my point;  the
framework already has this feature.  It does point out that
we should document this (the PPR documentation doesn't
currently describe it.)

> > 2) ...
> > 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?
>
> That would be true only for very simplistic facelets applications. It
> is very common to have facelets including facelets including other
> facelets and so forth. This makes the ability to use a facelets
> parameter unusable in all use cases. For example:
> A.xhtml;
> <html>
>   <tr:myComponent id="updateMe" partialTriggers="#{partialTriggers}" />
> </html>
>
> B.xhtml:
> <ui:composition>
>   <ui:decorate src="/A.xhtml">
>     <ui:param name="partialTriggers" value="blah" />
>   </ui:decorate>
>   <ui:include src="/C.xhtml">
>   </ui:include>
> </ui:composition>
>
> C.xhtml:
> <ui:composition>
>   <tr:commandLink id="myLink" partialSubmit="true" />
> </ui:composition>
>
> Now in this example, I would have to know in B that I should add
> "myLink" to the partialTriggers argument. If I am writing more complex
> code than the above example I may have to be aware of tens of
> components in various include files that should all be updating the
> "updateMe" component. It is much more maintainable to have the
> "myLink" update the "updateMe" instead of having to know all the
> components that should update "updateMe" in the including view. This
> use case could easily arise from page headers, page footers, common
> components on web pages, like help sections (like a
> contents/index/search type of help component).
>
> I am not saying that this would be the main use case for updating
> components, I do feel that partialTriggers should be used when it
> makes sense, but that doesn't mean there are not uses cases that make
> partialTargets functionality better and more easily maintainable in a
> large project in certain situations.


OK, so we can scope out that specific sub-issue as something
worth solving.

> > 664: ...
> >
> > 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).
> >
> You already have alwaysRendered functionality in Trinidad, it is just
> not exposed, the tr:messages is always rendered / updated. Who is to
> say that users may very well have a very good reason why they may need
> alwaysRendered set to true.


The rationale for adding a feature like this has to be better
than "why not?"!  You need to argue convincingly that users
frequently have a very good reason, not ask me to prove that
no user will ever need it.

Since alwaysRendered supports EL
> expressions, it doesn't have to be true/false, it can be a function or
> other EL piece of code that would be smart enough to know not to
> render for a poll response for example.


The tr:messages thing was a hack, basically as a half-hearted
workaround for all the issues in getting error messages displayed

One reason I *really* don't want alwaysRendered added is that
in JSF 1.2 I want to introduce partial AJAX lifecycles,
where only the components being processed are actually
decoded/etc.  That'd break alwaysRendered.  Ergo, I don't
want it to exist at all without an overwhelmingly good reason to
require it.

Could you move the code for these two components over
to a branch and out of trunk?

-- Adam

Mime
View raw message