Adam Winer wrote:
On 9/4/07, *Andrew Robinson* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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?
+1
Adding features in too early is a good way to make problems for
ourselves later. Once we are certain that we understand the problem
space, if these components are the best solution, it will be easy to
move them to trunk.
-- Blake Sullivan
-- Adam
