> > 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.
> ...
> > 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.
> > 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.
>
> > 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. 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.
