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 supported.
-Andrew On Thu, Sep 25, 2008 at 11:27 AM, Blake Sullivan <[EMAIL PROTECTED]> 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 > >
