You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Andrew Robinson (JIRA)" <de...@myfaces.apache.org> on 2007/08/29 23:32:30 UTC
[jira] Created: (TRINIDAD-663) Idea for a new component to enhance
PPR
Idea for a new component to enhance PPR
---------------------------------------
Key: TRINIDAD-663
URL: https://issues.apache.org/jira/browse/TRINIDAD-663
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 1.0.2-core
Reporter: Andrew Robinson
It is not currently possible out of the box to control when in the JSF lifecycle a Trinidad component triggers its partial notification outside of actually changing the phase ID of the events, which is not always possible.
Also, it is very difficult to have a component listen to many components. For example, someone may want to say, re-render component x when any child of y is triggered.
There is also no functionality for a push type of PPR. Meaning that right now components specify that they want to be triggered, but there is no way to say for a component to target other components (for example, specify on a button to re-render a text box, instead of specifying on a text-box to re-render on that button).
I will attach code that I am using in my private project for a component that makes this relatively easy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-663) Idea for a new component to
enhance PPR
Posted by "Andrew Robinson (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523707 ]
Andrew Robinson commented on TRINIDAD-663:
------------------------------------------
Example usages:
Trigger immediately, useful for re-rendering on validation/conversion failures:
<tr:inputText required="true" partialTriggers="myTrigger" />
<cw:partialTrigger id="myTrigger" immediate="true">
<tr:commandLink partialSubmit="true" text="Test" />
</cw:partialTrigger>
Force other components to trigger:
<tr:inputText id="mytext" />
<cw:partialTrigger partialTargets="mytext">
<tr:commandLink partialSubmit="true" text="Test" />
</cw:partialTrigger>
Support triggering on multiple components with less work:
<tr:inputText partialTriggers="myTrigger" />
<cw:partialTrigger id="myTrigger">
<tr:commandLink partialSubmit="true" text="Test" />
<tr:commandLink partialSubmit="true" text="Test2" />
<tr:commandLink partialSubmit="true" text="Test3" />
<tr:commandLink partialSubmit="true" text="Test4" />
<tr:commandLink partialSubmit="true" text="Test5" />
<tr:commandLink partialSubmit="true" text="Test6" />
</cw:partialTrigger>
> Idea for a new component to enhance PPR
> ---------------------------------------
>
> Key: TRINIDAD-663
> URL: https://issues.apache.org/jira/browse/TRINIDAD-663
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Components: Components
> Affects Versions: 1.0.2-core
> Reporter: Andrew Robinson
> Attachments: PartialTriggerEvent.java, PartialTriggerListener.java, UIPartialTrigger.java
>
>
> It is not currently possible out of the box to control when in the JSF lifecycle a Trinidad component triggers its partial notification outside of actually changing the phase ID of the events, which is not always possible.
> Also, it is very difficult to have a component listen to many components. For example, someone may want to say, re-render component x when any child of y is triggered.
> There is also no functionality for a push type of PPR. Meaning that right now components specify that they want to be triggered, but there is no way to say for a component to target other components (for example, specify on a button to re-render a text box, instead of specifying on a text-box to re-render on that button).
> I will attach code that I am using in my private project for a component that makes this relatively easy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TRINIDAD-663) Idea for a new component to enhance
PPR
Posted by "Andrew Robinson (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Robinson reopened TRINIDAD-663:
--------------------------------------
Assignee: (was: Andrew Robinson)
Code backed out of trunk
It is now archived in branch:
https://svn.apache.org/repos/asf/myfaces/trinidad/branches/arobinson-ppr-components
> Idea for a new component to enhance PPR
> ---------------------------------------
>
> Key: TRINIDAD-663
> URL: https://issues.apache.org/jira/browse/TRINIDAD-663
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Components: Components
> Affects Versions: 1.0.2-core
> Reporter: Andrew Robinson
> Fix For: 1.0.3-core
>
> Attachments: PartialTriggerEvent.java, PartialTriggerListener.java, UIPartialTrigger.java
>
>
> It is not currently possible out of the box to control when in the JSF lifecycle a Trinidad component triggers its partial notification outside of actually changing the phase ID of the events, which is not always possible.
> Also, it is very difficult to have a component listen to many components. For example, someone may want to say, re-render component x when any child of y is triggered.
> There is also no functionality for a push type of PPR. Meaning that right now components specify that they want to be triggered, but there is no way to say for a component to target other components (for example, specify on a button to re-render a text box, instead of specifying on a text-box to re-render on that button).
> I will attach code that I am using in my private project for a component that makes this relatively easy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (TRINIDAD-663) Idea for a new component to enhance
PPR
Posted by Scott O'Bryan <da...@gmail.com>.
This code is in sandbox isn't it? IMO, if it's in sandbox it is
experimental. This seems to be a good stop-gap measure for something
that is lacking in the current famework. I've talked to quite a few
people who have stopped using Trinidad because we don't have a solution
for this, and while I'm not sure this solution will work in all cases
(which is why I didn't support it in the base Trinidad either), it's
certainly worth sandboxing it and letting people use it if they want
to. At the very least it may prevent them from abandoning Trindiad and
moving to RichFaces.
As for other optimizations which may be coming, there is no saying that
an extension to trinidad has to work with the sandbox. For now I think
it has merit to letting people try to use it.
Just my 2 cents. :)
Scott
Andrew Robinson wrote:
> 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
> <bl...@oracle.com> 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
>>
>>
>>
Re: [jira] Resolved: (TRINIDAD-663) Idea for a new component to enhance PPR
Posted by Andrew Robinson <an...@gmail.com>.
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
<bl...@oracle.com> 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
>
>
Re: [jira] Resolved: (TRINIDAD-663) Idea for a new component to enhance
PPR
Posted by Blake Sullivan <bl...@oracle.com>.
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
>
Re: [jira] Resolved: (TRINIDAD-663) Idea for a new component to enhance PPR
Posted by Andrew Robinson <an...@gmail.com>.
> 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
Re: [jira] Resolved: (TRINIDAD-663) Idea for a new component to enhance
PPR
Posted by Blake Sullivan <bl...@oracle.com>.
Andrew Robinson said the following On 9/24/2008 9:38 PM PT:
> Partial target support already exists in Trinidad, not just
> declaratively. So I am not sure why the distinction.
It only works programmatically and programmatic changes are not
guaranteed to cause the component's clientId to be rendered. The
ability to suppress rendering of clientIds is a useful optimization and
one Trinidad should take better advantage of in the future.
> Either way it is
> done RequestContextImpl.addPartialTarget(UIComponent) gets called. In
> the case of partialTriggers, UIXComponentBase builds up a list of
> components and then if an event is broadcast, it loops through these,
> calling (not directly, but eventually) addPartalTarget. The
> partialTargets simply finds the components and calls addPartialTarget,
> passing those components. So since the code is the same in the end,
> what is the problem? I am not sure of the problem, I guess I am
> missing something. Is there some code that only adds ID attributes
> onto HTML only when their partialTriggers attribute is set?
>
Here is the CoreRenderer implementation of shouldRenderId():
protected boolean shouldRenderId(
FacesContext context,
UIComponent component)
{
String id = component.getId();
// Otherwise, if ID isn't set, don't bother
if (id == null)
return false;
// ... or if the ID was generated, don't bother
if (id.startsWith(UIViewRoot.UNIQUE_ID_PREFIX))
return false;
return true;
}
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.
-- Blake Sullivan
> -Andrew
>
> On Wed, Sep 24, 2008 at 10:29 PM, Blake Sullivan
> <bl...@oracle.com> wrote:
>
>> Andrew,
>>
>> One disadvantage of specifying partial targets is that the component can no
>> longer know at the point it is being rendered whether it will need to
>> potentially re-render itself (as opposed to partial triggers). How would a
>> renderer know whether it needs to render an id when partial triggers exist?
>>
>> -- Blake Sullivan
>>
>> Andrew Robinson (JIRA) said the following On 9/24/2008 7:55 PM PT:
>>
>> [
>> https://issues.apache.org/jira/browse/TRINIDAD-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Andrew Robinson resolved TRINIDAD-663.
>> --------------------------------------
>>
>> Resolution: Fixed
>> Fix Version/s: (was: 1.0.4-core)
>> 1.2.10-core
>> Assignee: Andrew Robinson
>>
>> Added to the 1.2 Trinidad sandbox
>>
>>
>>
>> Idea for a new component to enhance PPR
>> ---------------------------------------
>>
>> Key: TRINIDAD-663
>> URL: https://issues.apache.org/jira/browse/TRINIDAD-663
>> Project: MyFaces Trinidad
>> Issue Type: Improvement
>> Components: Components
>> Affects Versions: 1.0.2-core
>> Reporter: Andrew Robinson
>> Assignee: Andrew Robinson
>> Fix For: 1.2.10-core
>>
>> Attachments: PartialTriggerEvent.java, PartialTriggerListener.java,
>> UIPartialTrigger.java
>>
>>
>> It is not currently possible out of the box to control when in the JSF
>> lifecycle a Trinidad component triggers its partial notification outside of
>> actually changing the phase ID of the events, which is not always possible.
>> Also, it is very difficult to have a component listen to many components.
>> For example, someone may want to say, re-render component x when any child
>> of y is triggered.
>> There is also no functionality for a push type of PPR. Meaning that right
>> now components specify that they want to be triggered, but there is no way
>> to say for a component to target other components (for example, specify on a
>> button to re-render a text box, instead of specifying on a text-box to
>> re-render on that button).
>> I will attach code that I am using in my private project for a component
>> that makes this relatively easy.
>>
>>
>>
>>
>>
Re: [jira] Resolved: (TRINIDAD-663) Idea for a new component to enhance PPR
Posted by Andrew Robinson <an...@gmail.com>.
Partial target support already exists in Trinidad, not just
declaratively. So I am not sure why the distinction. Either way it is
done RequestContextImpl.addPartialTarget(UIComponent) gets called. In
the case of partialTriggers, UIXComponentBase builds up a list of
components and then if an event is broadcast, it loops through these,
calling (not directly, but eventually) addPartalTarget. The
partialTargets simply finds the components and calls addPartialTarget,
passing those components. So since the code is the same in the end,
what is the problem? I am not sure of the problem, I guess I am
missing something. Is there some code that only adds ID attributes
onto HTML only when their partialTriggers attribute is set?
-Andrew
On Wed, Sep 24, 2008 at 10:29 PM, Blake Sullivan
<bl...@oracle.com> wrote:
> Andrew,
>
> One disadvantage of specifying partial targets is that the component can no
> longer know at the point it is being rendered whether it will need to
> potentially re-render itself (as opposed to partial triggers). How would a
> renderer know whether it needs to render an id when partial triggers exist?
>
> -- Blake Sullivan
>
> Andrew Robinson (JIRA) said the following On 9/24/2008 7:55 PM PT:
>
> [
> https://issues.apache.org/jira/browse/TRINIDAD-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Andrew Robinson resolved TRINIDAD-663.
> --------------------------------------
>
> Resolution: Fixed
> Fix Version/s: (was: 1.0.4-core)
> 1.2.10-core
> Assignee: Andrew Robinson
>
> Added to the 1.2 Trinidad sandbox
>
>
>
> Idea for a new component to enhance PPR
> ---------------------------------------
>
> Key: TRINIDAD-663
> URL: https://issues.apache.org/jira/browse/TRINIDAD-663
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Components: Components
> Affects Versions: 1.0.2-core
> Reporter: Andrew Robinson
> Assignee: Andrew Robinson
> Fix For: 1.2.10-core
>
> Attachments: PartialTriggerEvent.java, PartialTriggerListener.java,
> UIPartialTrigger.java
>
>
> It is not currently possible out of the box to control when in the JSF
> lifecycle a Trinidad component triggers its partial notification outside of
> actually changing the phase ID of the events, which is not always possible.
> Also, it is very difficult to have a component listen to many components.
> For example, someone may want to say, re-render component x when any child
> of y is triggered.
> There is also no functionality for a push type of PPR. Meaning that right
> now components specify that they want to be triggered, but there is no way
> to say for a component to target other components (for example, specify on a
> button to re-render a text box, instead of specifying on a text-box to
> re-render on that button).
> I will attach code that I am using in my private project for a component
> that makes this relatively easy.
>
>
>
>
Re: [jira] Resolved: (TRINIDAD-663) Idea for a new component to enhance
PPR
Posted by Blake Sullivan <bl...@oracle.com>.
Andrew,
One disadvantage of specifying partial targets is that the component can
no longer know at the point it is being rendered whether it will need to
potentially re-render itself (as opposed to partial triggers). How
would a renderer know whether it needs to render an id when partial
triggers exist?
-- Blake Sullivan
Andrew Robinson (JIRA) said the following On 9/24/2008 7:55 PM PT:
> [ https://issues.apache.org/jira/browse/TRINIDAD-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Andrew Robinson resolved TRINIDAD-663.
> --------------------------------------
>
> Resolution: Fixed
> Fix Version/s: (was: 1.0.4-core)
> 1.2.10-core
> Assignee: Andrew Robinson
>
> Added to the 1.2 Trinidad sandbox
>
>
>> Idea for a new component to enhance PPR
>> ---------------------------------------
>>
>> Key: TRINIDAD-663
>> URL: https://issues.apache.org/jira/browse/TRINIDAD-663
>> Project: MyFaces Trinidad
>> Issue Type: Improvement
>> Components: Components
>> Affects Versions: 1.0.2-core
>> Reporter: Andrew Robinson
>> Assignee: Andrew Robinson
>> Fix For: 1.2.10-core
>>
>> Attachments: PartialTriggerEvent.java, PartialTriggerListener.java, UIPartialTrigger.java
>>
>>
>> It is not currently possible out of the box to control when in the JSF lifecycle a Trinidad component triggers its partial notification outside of actually changing the phase ID of the events, which is not always possible.
>> Also, it is very difficult to have a component listen to many components. For example, someone may want to say, re-render component x when any child of y is triggered.
>> There is also no functionality for a push type of PPR. Meaning that right now components specify that they want to be triggered, but there is no way to say for a component to target other components (for example, specify on a button to re-render a text box, instead of specifying on a text-box to re-render on that button).
>> I will attach code that I am using in my private project for a component that makes this relatively easy.
>>
>
>
[jira] Resolved: (TRINIDAD-663) Idea for a new component to enhance
PPR
Posted by "Andrew Robinson (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Robinson resolved TRINIDAD-663.
--------------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.0.4-core)
1.2.10-core
Assignee: Andrew Robinson
Added to the 1.2 Trinidad sandbox
> Idea for a new component to enhance PPR
> ---------------------------------------
>
> Key: TRINIDAD-663
> URL: https://issues.apache.org/jira/browse/TRINIDAD-663
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Components: Components
> Affects Versions: 1.0.2-core
> Reporter: Andrew Robinson
> Assignee: Andrew Robinson
> Fix For: 1.2.10-core
>
> Attachments: PartialTriggerEvent.java, PartialTriggerListener.java, UIPartialTrigger.java
>
>
> It is not currently possible out of the box to control when in the JSF lifecycle a Trinidad component triggers its partial notification outside of actually changing the phase ID of the events, which is not always possible.
> Also, it is very difficult to have a component listen to many components. For example, someone may want to say, re-render component x when any child of y is triggered.
> There is also no functionality for a push type of PPR. Meaning that right now components specify that they want to be triggered, but there is no way to say for a component to target other components (for example, specify on a button to re-render a text box, instead of specifying on a text-box to re-render on that button).
> I will attach code that I am using in my private project for a component that makes this relatively easy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-663) Idea for a new component to enhance
PPR
Posted by "Andrew Robinson (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Robinson resolved TRINIDAD-663.
--------------------------------------
Resolution: Fixed
Fix Version/s: 1.0.3-core
SVN Rev #571531
Added the UIXPartialTrigger component
Demo available in the page: demos/pprDemos.jspx
> Idea for a new component to enhance PPR
> ---------------------------------------
>
> Key: TRINIDAD-663
> URL: https://issues.apache.org/jira/browse/TRINIDAD-663
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Components: Components
> Affects Versions: 1.0.2-core
> Reporter: Andrew Robinson
> Assignee: Andrew Robinson
> Fix For: 1.0.3-core
>
> Attachments: PartialTriggerEvent.java, PartialTriggerListener.java, UIPartialTrigger.java
>
>
> It is not currently possible out of the box to control when in the JSF lifecycle a Trinidad component triggers its partial notification outside of actually changing the phase ID of the events, which is not always possible.
> Also, it is very difficult to have a component listen to many components. For example, someone may want to say, re-render component x when any child of y is triggered.
> There is also no functionality for a push type of PPR. Meaning that right now components specify that they want to be triggered, but there is no way to say for a component to target other components (for example, specify on a button to re-render a text box, instead of specifying on a text-box to re-render on that button).
> I will attach code that I am using in my private project for a component that makes this relatively easy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.