myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Robinson" <>
Subject Re: [jira] Resolved: (TRINIDAD-663) Idea for a new component to enhance PPR
Date Thu, 25 Sep 2008 19:07:16 GMT
That would break the public API of addPartialTarget, my code does not
change that. addPartialTarget is documented in the developer guide as
the recommended way to PPR components in a table, therefore it must be


On Thu, Sep 25, 2008 at 11:27 AM, Blake Sullivan
<> wrote:
> That assumes that you want to use the presence of any non-auto-generated id
> as an indication that the id should be rendered on the client.  However,
> there are a number of cases--for example test automation, where it is nice
> to set an id in the page definition and only have the id rendered to the
> client when test automation is actually occurring.  Also, there are cases
> where an id is necessary on the component for logic that will only execute
> on the server, so we would like the renderer to have the option of not
> rendering the clientId even in cases where the id is explicitly set.
> -- Blake Sullivan
> Andrew Robinson said the following On 9/25/2008 6:19 AM PT:
> This clearly doesn't work well with partialTriggers or partialTargets, but a
> Renderer can override this to always render the id if any partial triggers
> are set (and in fact, the rich client does).  However, the Renderer knows
> nothing about other partial targets.
> The renderer doesn't need to know about partial targets. The very
> nature of a partial target means that the target has a non-generated
> ID. Therefore, the ID will always be rendered on the client. So
> therefore, this code is actually safer than the partialTriggers code
> which may have a partially updated component that does not render an
> ID.
> I have been using this code for a while now, and have never had a
> problem with it. Check out the demo and the code to see you find a
> bug, but as I mentioned, it is working.
> Example:
> <tr:inputText id="updateMe" />
> <tr:commandLink>
>   <trs:partialTrigger partialTargets="updateMe" />
> </tr:commandLink>
> As you can see, the input text is gaurunteed by "normal" Trinidad
> renderers to have an ID, since its ID is not generated. Therefore
> "updateMe" will always be there, so there should be no use cases when
> this code will fail. In order to fail, the target would have to
> purposely not render an ID to the client. Now take the normal Trinidad
> example of PPR:
> <tr:inputText partialTriggers="theButton" />
> <tr:commandLink id="theButton" />
> This code can easily fail since the inputText has a generated ID and
> therefore the renderer may not give the HTML element an id, and
> therefore PPR would fail. So as far as I can tell, the partialTargets
> is more stable and fits the Trinidad design better than
> partialTriggers. Partial targets also has the benefit of being more
> efficient as there are no listeners to register. The code only has to
> be evaluated when the event is broadcast. The partialTriggers code
> must be processed for every component every time the component
> decodes, a solution with far greater overhead.
> It seems to me like you have not fully reviewed the code. If you
> could, please review the source in the sandbox that I committed and
> the RequestContextImpl code. If you then find a bug, please file one.
> I have studied this, and have used it in applications I have written,
> as I mentioned above, and it has been very stable for me. Thanks for
> checking into it though, I would prefer to find any bugs earlier
> rather than later.
> -Andrew

View raw message