You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Kamran Kashanian (JIRA)" <de...@myfaces.apache.org> on 2008/02/20 01:46:43 UTC
[jira] Created: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS FOR
TABLE COLUMN HEADER/FOOTER
NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
-------------------------------------------------------------
Key: TRINIDAD-961
URL: https://issues.apache.org/jira/browse/TRINIDAD-961
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.6-core
Environment: All
Reporter: Kamran Kashanian
If a UIComponent inside the table column header/footer contains a partialTrigger referencing the component ID of a stamped component inside the table. When the partialTrigger is invoked, the client ID that gets added to the partialTargets list for the header/footer UIComponent includes the table "currency" key. So the component inside the column header/footer is incorrectly being treated as a stamped component. This prevents the update of components inside table header/footer (as a result of changes in stamped components in the table body) using partialTriggers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS
FOR TABLE COLUMN HEADER/FOOTER
Posted by Scott O'Bryan <da...@gmail.com>.
Then I think we are in agreement. I think it'll at least be open till
tomorrow anyway to get input from our friends on the other side of the
globe. :)
Scott
Blake Sullivan wrote:
> Scott O'Bryan said the following On 3/10/2008 4:52 PM PT:
>> That's not what I'm saying..
>>
>> Interfaces absolutely have their place. But this is not an
>> interface, it's an abstract class and rightfully so. An interface is
>> good for providing one-way dependencies. That is, for exposing
>> something which always has a well known implementation that may be
>> hidden from the user. One of the "problems" with interfaces,
>> however, is that using them does not provide the flexibility to add
>> apis and remain binary compatible on the implementation side without
>> the use of inheritance. Indeed in Java when its needed to extend an
>> interface, it's added sub-interfaces.
> The point is that it is intended to act as an "interface" as do all
> pure abstract classes.
>>
>> This class (like UIComponent in JSF) it is intended for people to
>> write components against whereas the base class should be a default
>> implementation to make things easier. When Faces needed to extend
>> the functionality of its UIComponent class from 1.1 to 1.2, it did
>> exactly what I'm proposing. So what I'm proposing is not off base.
>> When Adam was more active on this list he was really zen about making
>> sure compatibility wasn't breached. I feel that, in general, its
>> helped us more then hurt us which is why I brought it up here.
>> Correctness and compatibility should always win over beautiful code.
> Do you honestly think that there is a single other implementation of
> this class in the entire world? If I did, I would put the
> implementation in UIXComponent.
>>
>> That said, I totally buy the argument that nobody using Trinidad is
>> currently implementing the UIXComponent interface without using the
>> UIXComponentBase object. In this case, I believe your argument is
>> that it's fine to break contract because we would have a known
>> implementation as the only implementer of this interface because
>> everything else extends the UIXComponentBase. That may be true, but
>> in order for us to know that we need to at least ping the list about
>> it and see if it is going to mess with people in the community at
>> large who would be depending on this API. I don't by the "let's
>> break it and see if anyone complains" attitude, and that is the
>> precedent I was referring to.
> I don't think anyone ever said that we shouldn't ask the list.
>
> -- Blake Sullivan
>>
>> This is why I mentioned that I'm willing to concede the point if
>> nobody on the list has a problem with it.
>>
>> Scott
>>
>>
>> Blake Sullivan wrote:
>>> Scott O'Bryan said the following On 3/10/2008 3:24 PM PT:
>>>> Well you know my vote, I'm concerned about the incompatibility
>>> If I really thought there was much of a chance that anyone had
>>> already subclassed UIXComponent itself, I would be more worried.
>>>> and, frankly, having it only in base provides us nothing but a
>>>> nicer looking class.
>>> I guess you aren't a fan of interfaces for anything other than
>>> co-implementation either, then.
>>>> Ultimately though, if nobody else cares I'm willing to let it
>>>> slide. I just think it sets a bad precedent.
>>> Precedent for what? Weighing long-term cleanliness against the
>>> likelihood of regression? It seems that your disagreement is with
>>> the relative weighting of the advantages and disadvantages in this
>>> case, which is a fair complaint but isn't precedent setting.
>>>
>>> -- Blake Sullivan
>>>
>>>>
>>>> Scott
>>>>
>>>> Max Starets wrote:
>>>>> I'd say leave it in UIXComponentBase.
>>>>>
>>>>> Kamran Kashanian wrote:
>>>>>> Currently UIXComponent is a pure abstract class and does not have
>>>>>> *any* implementation in it (except for a set of static methods
>>>>>> which were recently added).
>>>>>>
>>>>>> Should I:
>>>>>>
>>>>>> 1) Move the implementation for "getContainerClientId(FacesContext
>>>>>> context, UIComponent child)" up to UIXComponent and break the
>>>>>> convention used so far.
>>>>>>
>>>>>> 2) Leave the implementation in UIXComponentBase.
>>>>>>
>>>>>> Please respond if you care.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 10, 2008 at 12:51 PM, Kamran Kashanian
>>>>>> <kamran.faces@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>> Scott,
>>>>>>
>>>>>> I don't have a problem with moving the default implementation
>>>>>> for
>>>>>> "getContainerClientId(FacesContext context, UIComponent
>>>>>> child)" up
>>>>>> into UIXComponent and making it concrete (not abstract).
>>>>>>
>>>>>> I am not sure what the original rationale was for keeping
>>>>>> implementation out of UIXComponent. Looking at the RI code,
>>>>>> looks
>>>>>> like UIComponent is abstract and *does* include default
>>>>>> implemetation for all of the 1.2 APIs.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 10, 2008 at 11:38 AM, Scott O'Bryan (JIRA)
>>>>>> <dev@myfaces.apache.org <ma...@myfaces.apache.org>> wrote:
>>>>>>
>>>>>>
>>>>>> [
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083
>>>>>>
>>>>>>
>>>>>> <https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083>
>>>>>>
>>>>>> ]
>>>>>>
>>>>>> Scott O'Bryan commented on TRINIDAD-961:
>>>>>> ----------------------------------------
>>>>>>
>>>>>> I'm not sure I agree with this patch. This change involves
>>>>>> adding an abstract method to UIXComponent and assumes that
>>>>>> everyone making custom components is going to extend
>>>>>> UIXComponentBase. This is not something that is enforced by
>>>>>> either the contract OR the api.
>>>>>>
>>>>>> Since UIXComponent is already an abstract class (and not an
>>>>>> interface), I think the default implementation of this new
>>>>>> method needs to be on UIXComponent so that custom component
>>>>>> code continues to work. I know the convention in
>>>>>> UIXComponent
>>>>>> has been that this class is totally abstract, but I can't
>>>>>> help
>>>>>> but think that the reason for making this an abstract class
>>>>>> rather then an interface was so that we did NOT run into
>>>>>> these
>>>>>> types of issues as new methods were added.
>>>>>>
>>>>>> What I'm basically proposing is instead of making the new
>>>>>> method and abstract method, that we provide a simple default
>>>>>> implementation so that any code extending this class would
>>>>>> "just work" between 1.2.6 and 1.2.7..
>>>>>>
>>>>>>
>>>>>> > NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN
>>>>>> HEADER/FOOTER
>>>>>> >
>>>>>> -------------------------------------------------------------
>>>>>> >
>>>>>> > Key: TRINIDAD-961
>>>>>> > URL:
>>>>>> https://issues.apache.org/jira/browse/TRINIDAD-961
>>>>>> > Project: MyFaces Trinidad
>>>>>> > Issue Type: Bug
>>>>>> > Components: Components
>>>>>> > Affects Versions: 1.2.6-core
>>>>>> > Environment: All
>>>>>> > Reporter: Kamran Kashanian
>>>>>> > Attachments: trinidad_1.2.x.patch
>>>>>> >
>>>>>> >
>>>>>> > If a UIComponent inside the table column header/footer
>>>>>> contains a partialTrigger referencing the component ID of a
>>>>>> stamped component inside the table. When the
>>>>>> partialTrigger is
>>>>>> invoked, the client ID that gets added to the
>>>>>> partialTargets
>>>>>> list for the header/footer UIComponent includes the table
>>>>>> "currency" key. So the component inside the column
>>>>>> header/footer is incorrectly being treated as a stamped
>>>>>> component. This prevents the update of components inside
>>>>>> table
>>>>>> header/footer (as a result of changes in stamped
>>>>>> components in
>>>>>> the table body) using partialTriggers.
>>>>>>
>>>>>> --
>>>>>> This message is automatically generated by JIRA.
>>>>>> -
>>>>>> You can reply to this email to add a comment to the issue
>>>>>> online.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [jira] Commented: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS
FOR TABLE COLUMN HEADER/FOOTER
Posted by Blake Sullivan <bl...@oracle.com>.
Scott O'Bryan said the following On 3/10/2008 4:52 PM PT:
> That's not what I'm saying..
>
> Interfaces absolutely have their place. But this is not an interface,
> it's an abstract class and rightfully so. An interface is good for
> providing one-way dependencies. That is, for exposing something which
> always has a well known implementation that may be hidden from the
> user. One of the "problems" with interfaces, however, is that using
> them does not provide the flexibility to add apis and remain binary
> compatible on the implementation side without the use of inheritance.
> Indeed in Java when its needed to extend an interface, it's added
> sub-interfaces.
The point is that it is intended to act as an "interface" as do all pure
abstract classes.
>
> This class (like UIComponent in JSF) it is intended for people to
> write components against whereas the base class should be a default
> implementation to make things easier. When Faces needed to extend the
> functionality of its UIComponent class from 1.1 to 1.2, it did exactly
> what I'm proposing. So what I'm proposing is not off base. When Adam
> was more active on this list he was really zen about making sure
> compatibility wasn't breached. I feel that, in general, its helped
> us more then hurt us which is why I brought it up here. Correctness
> and compatibility should always win over beautiful code.
Do you honestly think that there is a single other implementation of
this class in the entire world? If I did, I would put the
implementation in UIXComponent.
>
> That said, I totally buy the argument that nobody using Trinidad is
> currently implementing the UIXComponent interface without using the
> UIXComponentBase object. In this case, I believe your argument is
> that it's fine to break contract because we would have a known
> implementation as the only implementer of this interface because
> everything else extends the UIXComponentBase. That may be true, but
> in order for us to know that we need to at least ping the list about
> it and see if it is going to mess with people in the community at
> large who would be depending on this API. I don't by the "let's break
> it and see if anyone complains" attitude, and that is the precedent I
> was referring to.
I don't think anyone ever said that we shouldn't ask the list.
-- Blake Sullivan
>
> This is why I mentioned that I'm willing to concede the point if
> nobody on the list has a problem with it.
>
> Scott
>
>
> Blake Sullivan wrote:
>> Scott O'Bryan said the following On 3/10/2008 3:24 PM PT:
>>> Well you know my vote, I'm concerned about the incompatibility
>> If I really thought there was much of a chance that anyone had
>> already subclassed UIXComponent itself, I would be more worried.
>>> and, frankly, having it only in base provides us nothing but a nicer
>>> looking class.
>> I guess you aren't a fan of interfaces for anything other than
>> co-implementation either, then.
>>> Ultimately though, if nobody else cares I'm willing to let it
>>> slide. I just think it sets a bad precedent.
>> Precedent for what? Weighing long-term cleanliness against the
>> likelihood of regression? It seems that your disagreement is with
>> the relative weighting of the advantages and disadvantages in this
>> case, which is a fair complaint but isn't precedent setting.
>>
>> -- Blake Sullivan
>>
>>>
>>> Scott
>>>
>>> Max Starets wrote:
>>>> I'd say leave it in UIXComponentBase.
>>>>
>>>> Kamran Kashanian wrote:
>>>>> Currently UIXComponent is a pure abstract class and does not have
>>>>> *any* implementation in it (except for a set of static methods
>>>>> which were recently added).
>>>>>
>>>>> Should I:
>>>>>
>>>>> 1) Move the implementation for "getContainerClientId(FacesContext
>>>>> context, UIComponent child)" up to UIXComponent and break the
>>>>> convention used so far.
>>>>>
>>>>> 2) Leave the implementation in UIXComponentBase.
>>>>>
>>>>> Please respond if you care.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 10, 2008 at 12:51 PM, Kamran Kashanian
>>>>> <kamran.faces@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> Scott,
>>>>>
>>>>> I don't have a problem with moving the default implementation for
>>>>> "getContainerClientId(FacesContext context, UIComponent
>>>>> child)" up
>>>>> into UIXComponent and making it concrete (not abstract).
>>>>>
>>>>> I am not sure what the original rationale was for keeping
>>>>> implementation out of UIXComponent. Looking at the RI code, looks
>>>>> like UIComponent is abstract and *does* include default
>>>>> implemetation for all of the 1.2 APIs.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 10, 2008 at 11:38 AM, Scott O'Bryan (JIRA)
>>>>> <dev@myfaces.apache.org <ma...@myfaces.apache.org>> wrote:
>>>>>
>>>>>
>>>>> [
>>>>>
>>>>> https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083
>>>>>
>>>>>
>>>>> <https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083>
>>>>>
>>>>> ]
>>>>>
>>>>> Scott O'Bryan commented on TRINIDAD-961:
>>>>> ----------------------------------------
>>>>>
>>>>> I'm not sure I agree with this patch. This change involves
>>>>> adding an abstract method to UIXComponent and assumes that
>>>>> everyone making custom components is going to extend
>>>>> UIXComponentBase. This is not something that is enforced by
>>>>> either the contract OR the api.
>>>>>
>>>>> Since UIXComponent is already an abstract class (and not an
>>>>> interface), I think the default implementation of this new
>>>>> method needs to be on UIXComponent so that custom component
>>>>> code continues to work. I know the convention in
>>>>> UIXComponent
>>>>> has been that this class is totally abstract, but I can't
>>>>> help
>>>>> but think that the reason for making this an abstract class
>>>>> rather then an interface was so that we did NOT run into
>>>>> these
>>>>> types of issues as new methods were added.
>>>>>
>>>>> What I'm basically proposing is instead of making the new
>>>>> method and abstract method, that we provide a simple default
>>>>> implementation so that any code extending this class would
>>>>> "just work" between 1.2.6 and 1.2.7..
>>>>>
>>>>>
>>>>> > NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN
>>>>> HEADER/FOOTER
>>>>> >
>>>>> -------------------------------------------------------------
>>>>> >
>>>>> > Key: TRINIDAD-961
>>>>> > URL:
>>>>> https://issues.apache.org/jira/browse/TRINIDAD-961
>>>>> > Project: MyFaces Trinidad
>>>>> > Issue Type: Bug
>>>>> > Components: Components
>>>>> > Affects Versions: 1.2.6-core
>>>>> > Environment: All
>>>>> > Reporter: Kamran Kashanian
>>>>> > Attachments: trinidad_1.2.x.patch
>>>>> >
>>>>> >
>>>>> > If a UIComponent inside the table column header/footer
>>>>> contains a partialTrigger referencing the component ID of a
>>>>> stamped component inside the table. When the
>>>>> partialTrigger is
>>>>> invoked, the client ID that gets added to the partialTargets
>>>>> list for the header/footer UIComponent includes the table
>>>>> "currency" key. So the component inside the column
>>>>> header/footer is incorrectly being treated as a stamped
>>>>> component. This prevents the update of components inside
>>>>> table
>>>>> header/footer (as a result of changes in stamped
>>>>> components in
>>>>> the table body) using partialTriggers.
>>>>>
>>>>> --
>>>>> This message is automatically generated by JIRA.
>>>>> -
>>>>> You can reply to this email to add a comment to the issue
>>>>> online.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [jira] Commented: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS
FOR TABLE COLUMN HEADER/FOOTER
Posted by Scott O'Bryan <da...@gmail.com>.
That's not what I'm saying..
Interfaces absolutely have their place. But this is not an interface,
it's an abstract class and rightfully so. An interface is good for
providing one-way dependencies. That is, for exposing something which
always has a well known implementation that may be hidden from the
user. One of the "problems" with interfaces, however, is that using
them does not provide the flexibility to add apis and remain binary
compatible on the implementation side without the use of inheritance.
Indeed in Java when its needed to extend an interface, it's added
sub-interfaces.
This class (like UIComponent in JSF) it is intended for people to write
components against whereas the base class should be a default
implementation to make things easier. When Faces needed to extend the
functionality of its UIComponent class from 1.1 to 1.2, it did exactly
what I'm proposing. So what I'm proposing is not off base. When Adam
was more active on this list he was really zen about making sure
compatibility wasn't breached. I feel that, in general, its helped us
more then hurt us which is why I brought it up here. Correctness and
compatibility should always win over beautiful code.
That said, I totally buy the argument that nobody using Trinidad is
currently implementing the UIXComponent interface without using the
UIXComponentBase object. In this case, I believe your argument is that
it's fine to break contract because we would have a known implementation
as the only implementer of this interface because everything else
extends the UIXComponentBase. That may be true, but in order for us to
know that we need to at least ping the list about it and see if it is
going to mess with people in the community at large who would be
depending on this API. I don't by the "let's break it and see if anyone
complains" attitude, and that is the precedent I was referring to.
This is why I mentioned that I'm willing to concede the point if nobody
on the list has a problem with it.
Scott
Blake Sullivan wrote:
> Scott O'Bryan said the following On 3/10/2008 3:24 PM PT:
>> Well you know my vote, I'm concerned about the incompatibility
> If I really thought there was much of a chance that anyone had already
> subclassed UIXComponent itself, I would be more worried.
>> and, frankly, having it only in base provides us nothing but a nicer
>> looking class.
> I guess you aren't a fan of interfaces for anything other than
> co-implementation either, then.
>> Ultimately though, if nobody else cares I'm willing to let it
>> slide. I just think it sets a bad precedent.
> Precedent for what? Weighing long-term cleanliness against the
> likelihood of regression? It seems that your disagreement is with the
> relative weighting of the advantages and disadvantages in this case,
> which is a fair complaint but isn't precedent setting.
>
> -- Blake Sullivan
>
>>
>> Scott
>>
>> Max Starets wrote:
>>> I'd say leave it in UIXComponentBase.
>>>
>>> Kamran Kashanian wrote:
>>>> Currently UIXComponent is a pure abstract class and does not have
>>>> *any* implementation in it (except for a set of static methods
>>>> which were recently added).
>>>>
>>>> Should I:
>>>>
>>>> 1) Move the implementation for "getContainerClientId(FacesContext
>>>> context, UIComponent child)" up to UIXComponent and break the
>>>> convention used so far.
>>>>
>>>> 2) Leave the implementation in UIXComponentBase.
>>>>
>>>> Please respond if you care.
>>>>
>>>>
>>>>
>>>> On Mon, Mar 10, 2008 at 12:51 PM, Kamran Kashanian
>>>> <kamran.faces@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> Scott,
>>>>
>>>> I don't have a problem with moving the default implementation for
>>>> "getContainerClientId(FacesContext context, UIComponent child)" up
>>>> into UIXComponent and making it concrete (not abstract).
>>>>
>>>> I am not sure what the original rationale was for keeping
>>>> implementation out of UIXComponent. Looking at the RI code, looks
>>>> like UIComponent is abstract and *does* include default
>>>> implemetation for all of the 1.2 APIs.
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Mar 10, 2008 at 11:38 AM, Scott O'Bryan (JIRA)
>>>> <dev@myfaces.apache.org <ma...@myfaces.apache.org>> wrote:
>>>>
>>>>
>>>> [
>>>>
>>>> https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083
>>>>
>>>>
>>>> <https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083>
>>>>
>>>> ]
>>>>
>>>> Scott O'Bryan commented on TRINIDAD-961:
>>>> ----------------------------------------
>>>>
>>>> I'm not sure I agree with this patch. This change involves
>>>> adding an abstract method to UIXComponent and assumes that
>>>> everyone making custom components is going to extend
>>>> UIXComponentBase. This is not something that is enforced by
>>>> either the contract OR the api.
>>>>
>>>> Since UIXComponent is already an abstract class (and not an
>>>> interface), I think the default implementation of this new
>>>> method needs to be on UIXComponent so that custom component
>>>> code continues to work. I know the convention in UIXComponent
>>>> has been that this class is totally abstract, but I can't help
>>>> but think that the reason for making this an abstract class
>>>> rather then an interface was so that we did NOT run into these
>>>> types of issues as new methods were added.
>>>>
>>>> What I'm basically proposing is instead of making the new
>>>> method and abstract method, that we provide a simple default
>>>> implementation so that any code extending this class would
>>>> "just work" between 1.2.6 and 1.2.7..
>>>>
>>>>
>>>> > NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN
>>>> HEADER/FOOTER
>>>> >
>>>> -------------------------------------------------------------
>>>> >
>>>> > Key: TRINIDAD-961
>>>> > URL:
>>>> https://issues.apache.org/jira/browse/TRINIDAD-961
>>>> > Project: MyFaces Trinidad
>>>> > Issue Type: Bug
>>>> > Components: Components
>>>> > Affects Versions: 1.2.6-core
>>>> > Environment: All
>>>> > Reporter: Kamran Kashanian
>>>> > Attachments: trinidad_1.2.x.patch
>>>> >
>>>> >
>>>> > If a UIComponent inside the table column header/footer
>>>> contains a partialTrigger referencing the component ID of a
>>>> stamped component inside the table. When the partialTrigger is
>>>> invoked, the client ID that gets added to the partialTargets
>>>> list for the header/footer UIComponent includes the table
>>>> "currency" key. So the component inside the column
>>>> header/footer is incorrectly being treated as a stamped
>>>> component. This prevents the update of components inside table
>>>> header/footer (as a result of changes in stamped components in
>>>> the table body) using partialTriggers.
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> You can reply to this email to add a comment to the issue
>>>> online.
>>>>
>>>>
>>>>
>>>
>>
>
Re: [jira] Commented: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS
FOR TABLE COLUMN HEADER/FOOTER
Posted by Blake Sullivan <bl...@oracle.com>.
Scott O'Bryan said the following On 3/10/2008 3:24 PM PT:
> Well you know my vote, I'm concerned about the incompatibility
If I really thought there was much of a chance that anyone had already
subclassed UIXComponent itself, I would be more worried.
> and, frankly, having it only in base provides us nothing but a nicer
> looking class.
I guess you aren't a fan of interfaces for anything other than
co-implementation either, then.
> Ultimately though, if nobody else cares I'm willing to let it
> slide. I just think it sets a bad precedent.
Precedent for what? Weighing long-term cleanliness against the
likelihood of regression? It seems that your disagreement is with the
relative weighting of the advantages and disadvantages in this case,
which is a fair complaint but isn't precedent setting.
-- Blake Sullivan
>
> Scott
>
> Max Starets wrote:
>> I'd say leave it in UIXComponentBase.
>>
>> Kamran Kashanian wrote:
>>> Currently UIXComponent is a pure abstract class and does not have
>>> *any* implementation in it (except for a set of static methods which
>>> were recently added).
>>>
>>> Should I:
>>>
>>> 1) Move the implementation for "getContainerClientId(FacesContext
>>> context, UIComponent child)" up to UIXComponent and break the
>>> convention used so far.
>>>
>>> 2) Leave the implementation in UIXComponentBase.
>>>
>>> Please respond if you care.
>>>
>>>
>>>
>>> On Mon, Mar 10, 2008 at 12:51 PM, Kamran Kashanian
>>> <kamran.faces@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> Scott,
>>>
>>> I don't have a problem with moving the default implementation for
>>> "getContainerClientId(FacesContext context, UIComponent child)" up
>>> into UIXComponent and making it concrete (not abstract).
>>>
>>> I am not sure what the original rationale was for keeping
>>> implementation out of UIXComponent. Looking at the RI code, looks
>>> like UIComponent is abstract and *does* include default
>>> implemetation for all of the 1.2 APIs.
>>>
>>>
>>>
>>>
>>> On Mon, Mar 10, 2008 at 11:38 AM, Scott O'Bryan (JIRA)
>>> <dev@myfaces.apache.org <ma...@myfaces.apache.org>> wrote:
>>>
>>>
>>> [
>>>
>>> https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083
>>>
>>>
>>> <https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083>
>>>
>>> ]
>>>
>>> Scott O'Bryan commented on TRINIDAD-961:
>>> ----------------------------------------
>>>
>>> I'm not sure I agree with this patch. This change involves
>>> adding an abstract method to UIXComponent and assumes that
>>> everyone making custom components is going to extend
>>> UIXComponentBase. This is not something that is enforced by
>>> either the contract OR the api.
>>>
>>> Since UIXComponent is already an abstract class (and not an
>>> interface), I think the default implementation of this new
>>> method needs to be on UIXComponent so that custom component
>>> code continues to work. I know the convention in UIXComponent
>>> has been that this class is totally abstract, but I can't help
>>> but think that the reason for making this an abstract class
>>> rather then an interface was so that we did NOT run into these
>>> types of issues as new methods were added.
>>>
>>> What I'm basically proposing is instead of making the new
>>> method and abstract method, that we provide a simple default
>>> implementation so that any code extending this class would
>>> "just work" between 1.2.6 and 1.2.7..
>>>
>>>
>>> > NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
>>> > -------------------------------------------------------------
>>> >
>>> > Key: TRINIDAD-961
>>> > URL:
>>> https://issues.apache.org/jira/browse/TRINIDAD-961
>>> > Project: MyFaces Trinidad
>>> > Issue Type: Bug
>>> > Components: Components
>>> > Affects Versions: 1.2.6-core
>>> > Environment: All
>>> > Reporter: Kamran Kashanian
>>> > Attachments: trinidad_1.2.x.patch
>>> >
>>> >
>>> > If a UIComponent inside the table column header/footer
>>> contains a partialTrigger referencing the component ID of a
>>> stamped component inside the table. When the partialTrigger is
>>> invoked, the client ID that gets added to the partialTargets
>>> list for the header/footer UIComponent includes the table
>>> "currency" key. So the component inside the column
>>> header/footer is incorrectly being treated as a stamped
>>> component. This prevents the update of components inside table
>>> header/footer (as a result of changes in stamped components in
>>> the table body) using partialTriggers.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue
>>> online.
>>>
>>>
>>>
>>
>
Re: [jira] Commented: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS
FOR TABLE COLUMN HEADER/FOOTER
Posted by Scott O'Bryan <da...@gmail.com>.
Well you know my vote, I'm concerned about the incompatibility and,
frankly, having it only in base provides us nothing but a nicer looking
class. Ultimately though, if nobody else cares I'm willing to let it
slide. I just think it sets a bad precedent.
Scott
Max Starets wrote:
> I'd say leave it in UIXComponentBase.
>
> Kamran Kashanian wrote:
>> Currently UIXComponent is a pure abstract class and does not have
>> *any* implementation in it (except for a set of static methods which
>> were recently added).
>>
>> Should I:
>>
>> 1) Move the implementation for "getContainerClientId(FacesContext
>> context, UIComponent child)" up to UIXComponent and break the
>> convention used so far.
>>
>> 2) Leave the implementation in UIXComponentBase.
>>
>> Please respond if you care.
>>
>>
>>
>> On Mon, Mar 10, 2008 at 12:51 PM, Kamran Kashanian
>> <kamran.faces@gmail.com <ma...@gmail.com>> wrote:
>>
>> Scott,
>>
>> I don't have a problem with moving the default implementation for
>> "getContainerClientId(FacesContext context, UIComponent child)" up
>> into UIXComponent and making it concrete (not abstract).
>>
>> I am not sure what the original rationale was for keeping
>> implementation out of UIXComponent. Looking at the RI code, looks
>> like UIComponent is abstract and *does* include default
>> implemetation for all of the 1.2 APIs.
>>
>>
>>
>>
>> On Mon, Mar 10, 2008 at 11:38 AM, Scott O'Bryan (JIRA)
>> <dev@myfaces.apache.org <ma...@myfaces.apache.org>> wrote:
>>
>>
>> [
>>
>> https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083
>>
>>
>> <https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083>
>>
>> ]
>>
>> Scott O'Bryan commented on TRINIDAD-961:
>> ----------------------------------------
>>
>> I'm not sure I agree with this patch. This change involves
>> adding an abstract method to UIXComponent and assumes that
>> everyone making custom components is going to extend
>> UIXComponentBase. This is not something that is enforced by
>> either the contract OR the api.
>>
>> Since UIXComponent is already an abstract class (and not an
>> interface), I think the default implementation of this new
>> method needs to be on UIXComponent so that custom component
>> code continues to work. I know the convention in UIXComponent
>> has been that this class is totally abstract, but I can't help
>> but think that the reason for making this an abstract class
>> rather then an interface was so that we did NOT run into these
>> types of issues as new methods were added.
>>
>> What I'm basically proposing is instead of making the new
>> method and abstract method, that we provide a simple default
>> implementation so that any code extending this class would
>> "just work" between 1.2.6 and 1.2.7..
>>
>>
>> > NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
>> > -------------------------------------------------------------
>> >
>> > Key: TRINIDAD-961
>> > URL:
>> https://issues.apache.org/jira/browse/TRINIDAD-961
>> > Project: MyFaces Trinidad
>> > Issue Type: Bug
>> > Components: Components
>> > Affects Versions: 1.2.6-core
>> > Environment: All
>> > Reporter: Kamran Kashanian
>> > Attachments: trinidad_1.2.x.patch
>> >
>> >
>> > If a UIComponent inside the table column header/footer
>> contains a partialTrigger referencing the component ID of a
>> stamped component inside the table. When the partialTrigger is
>> invoked, the client ID that gets added to the partialTargets
>> list for the header/footer UIComponent includes the table
>> "currency" key. So the component inside the column
>> header/footer is incorrectly being treated as a stamped
>> component. This prevents the update of components inside table
>> header/footer (as a result of changes in stamped components in
>> the table body) using partialTriggers.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue
>> online.
>>
>>
>>
>
Re: [jira] Commented: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS
FOR TABLE COLUMN HEADER/FOOTER
Posted by Max Starets <ma...@oracle.com>.
I'd say leave it in UIXComponentBase.
Kamran Kashanian wrote:
> Currently UIXComponent is a pure abstract class and does not have
> *any* implementation in it (except for a set of static methods which
> were recently added).
>
> Should I:
>
> 1) Move the implementation for "getContainerClientId(FacesContext
> context, UIComponent child)" up to UIXComponent and break the
> convention used so far.
>
> 2) Leave the implementation in UIXComponentBase.
>
> Please respond if you care.
>
>
>
> On Mon, Mar 10, 2008 at 12:51 PM, Kamran Kashanian
> <kamran.faces@gmail.com <ma...@gmail.com>> wrote:
>
> Scott,
>
> I don't have a problem with moving the default implementation for
> "getContainerClientId(FacesContext context, UIComponent child)" up
> into UIXComponent and making it concrete (not abstract).
>
> I am not sure what the original rationale was for keeping
> implementation out of UIXComponent. Looking at the RI code, looks
> like UIComponent is abstract and *does* include default
> implemetation for all of the 1.2 APIs.
>
>
>
>
> On Mon, Mar 10, 2008 at 11:38 AM, Scott O'Bryan (JIRA)
> <dev@myfaces.apache.org <ma...@myfaces.apache.org>> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083
> <https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083>
> ]
>
> Scott O'Bryan commented on TRINIDAD-961:
> ----------------------------------------
>
> I'm not sure I agree with this patch. This change involves
> adding an abstract method to UIXComponent and assumes that
> everyone making custom components is going to extend
> UIXComponentBase. This is not something that is enforced by
> either the contract OR the api.
>
> Since UIXComponent is already an abstract class (and not an
> interface), I think the default implementation of this new
> method needs to be on UIXComponent so that custom component
> code continues to work. I know the convention in UIXComponent
> has been that this class is totally abstract, but I can't help
> but think that the reason for making this an abstract class
> rather then an interface was so that we did NOT run into these
> types of issues as new methods were added.
>
> What I'm basically proposing is instead of making the new
> method and abstract method, that we provide a simple default
> implementation so that any code extending this class would
> "just work" between 1.2.6 and 1.2.7..
>
>
> > NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
> > -------------------------------------------------------------
> >
> > Key: TRINIDAD-961
> > URL:
> https://issues.apache.org/jira/browse/TRINIDAD-961
> > Project: MyFaces Trinidad
> > Issue Type: Bug
> > Components: Components
> > Affects Versions: 1.2.6-core
> > Environment: All
> > Reporter: Kamran Kashanian
> > Attachments: trinidad_1.2.x.patch
> >
> >
> > If a UIComponent inside the table column header/footer
> contains a partialTrigger referencing the component ID of a
> stamped component inside the table. When the partialTrigger is
> invoked, the client ID that gets added to the partialTargets
> list for the header/footer UIComponent includes the table
> "currency" key. So the component inside the column
> header/footer is incorrectly being treated as a stamped
> component. This prevents the update of components inside table
> header/footer (as a result of changes in stamped components in
> the table body) using partialTriggers.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
>
Re: [jira] Commented: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
Posted by Kamran Kashanian <ka...@gmail.com>.
Currently UIXComponent is a pure abstract class and does not have *any*
implementation in it (except for a set of static methods which were recently
added).
Should I:
1) Move the implementation for "getContainerClientId(FacesContext context,
UIComponent child)" up to UIXComponent and break the convention used so far.
2) Leave the implementation in UIXComponentBase.
Please respond if you care.
On Mon, Mar 10, 2008 at 12:51 PM, Kamran Kashanian <ka...@gmail.com>
wrote:
> Scott,
>
> I don't have a problem with moving the default implementation for
> "getContainerClientId(FacesContext context, UIComponent child)" up into
> UIXComponent and making it concrete (not abstract).
>
> I am not sure what the original rationale was for keeping implementation
> out of UIXComponent. Looking at the RI code, looks like UIComponent is
> abstract and *does* include default implemetation for all of the 1.2 APIs.
>
>
>
>
> On Mon, Mar 10, 2008 at 11:38 AM, Scott O'Bryan (JIRA) <
> dev@myfaces.apache.org> wrote:
>
> >
> > [
> > https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083]
> >
> > Scott O'Bryan commented on TRINIDAD-961:
> > ----------------------------------------
> >
> > I'm not sure I agree with this patch. This change involves adding an
> > abstract method to UIXComponent and assumes that everyone making custom
> > components is going to extend UIXComponentBase. This is not something that
> > is enforced by either the contract OR the api.
> >
> > Since UIXComponent is already an abstract class (and not an interface),
> > I think the default implementation of this new method needs to be on
> > UIXComponent so that custom component code continues to work. I know the
> > convention in UIXComponent has been that this class is totally abstract, but
> > I can't help but think that the reason for making this an abstract class
> > rather then an interface was so that we did NOT run into these types of
> > issues as new methods were added.
> >
> > What I'm basically proposing is instead of making the new method and
> > abstract method, that we provide a simple default implementation so that any
> > code extending this class would "just work" between 1.2.6 and 1.2.7..
> >
> >
> > > NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
> > > -------------------------------------------------------------
> > >
> > > Key: TRINIDAD-961
> > > URL:
> > https://issues.apache.org/jira/browse/TRINIDAD-961
> > > Project: MyFaces Trinidad
> > > Issue Type: Bug
> > > Components: Components
> > > Affects Versions: 1.2.6-core
> > > Environment: All
> > > Reporter: Kamran Kashanian
> > > Attachments: trinidad_1.2.x.patch
> > >
> > >
> > > If a UIComponent inside the table column header/footer contains a
> > partialTrigger referencing the component ID of a stamped component inside
> > the table. When the partialTrigger is invoked, the client ID that gets
> > added to the partialTargets list for the header/footer UIComponent includes
> > the table "currency" key. So the component inside the column header/footer
> > is incorrectly being treated as a stamped component. This prevents the
> > update of components inside table header/footer (as a result of changes in
> > stamped components in the table body) using partialTriggers.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>
Re: [jira] Commented: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
Posted by Kamran Kashanian <ka...@gmail.com>.
Scott,
I don't have a problem with moving the default implementation for
"getContainerClientId(FacesContext context, UIComponent child)" up into
UIXComponent and making it concrete (not abstract).
I am not sure what the original rationale was for keeping implementation out
of UIXComponent. Looking at the RI code, looks like UIComponent is abstract
and *does* include default implemetation for all of the 1.2 APIs.
On Mon, Mar 10, 2008 at 11:38 AM, Scott O'Bryan (JIRA) <
dev@myfaces.apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083]
>
> Scott O'Bryan commented on TRINIDAD-961:
> ----------------------------------------
>
> I'm not sure I agree with this patch. This change involves adding an
> abstract method to UIXComponent and assumes that everyone making custom
> components is going to extend UIXComponentBase. This is not something that
> is enforced by either the contract OR the api.
>
> Since UIXComponent is already an abstract class (and not an interface), I
> think the default implementation of this new method needs to be on
> UIXComponent so that custom component code continues to work. I know the
> convention in UIXComponent has been that this class is totally abstract, but
> I can't help but think that the reason for making this an abstract class
> rather then an interface was so that we did NOT run into these types of
> issues as new methods were added.
>
> What I'm basically proposing is instead of making the new method and
> abstract method, that we provide a simple default implementation so that any
> code extending this class would "just work" between 1.2.6 and 1.2.7..
>
>
> > NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
> > -------------------------------------------------------------
> >
> > Key: TRINIDAD-961
> > URL: https://issues.apache.org/jira/browse/TRINIDAD-961
> > Project: MyFaces Trinidad
> > Issue Type: Bug
> > Components: Components
> > Affects Versions: 1.2.6-core
> > Environment: All
> > Reporter: Kamran Kashanian
> > Attachments: trinidad_1.2.x.patch
> >
> >
> > If a UIComponent inside the table column header/footer contains a
> partialTrigger referencing the component ID of a stamped component inside
> the table. When the partialTrigger is invoked, the client ID that gets
> added to the partialTargets list for the header/footer UIComponent includes
> the table "currency" key. So the component inside the column header/footer
> is incorrectly being treated as a stamped component. This prevents the
> update of components inside table header/footer (as a result of changes in
> stamped components in the table body) using partialTriggers.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Updated: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS FOR
TABLE COLUMN HEADER/FOOTER
Posted by "Matt Cooper (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Cooper updated TRINIDAD-961:
---------------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
1.2.8-core was not a listed unreleased version to select yet. I believe the 1.2.7-core release was already built so I don't believe I can mark this issue as resolved in that release.
> NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
> -------------------------------------------------------------
>
> Key: TRINIDAD-961
> URL: https://issues.apache.org/jira/browse/TRINIDAD-961
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.6-core
> Environment: All
> Reporter: Kamran Kashanian
> Assignee: Matt Cooper
> Attachments: trinidad_1.2.x.patch
>
>
> If a UIComponent inside the table column header/footer contains a partialTrigger referencing the component ID of a stamped component inside the table. When the partialTrigger is invoked, the client ID that gets added to the partialTargets list for the header/footer UIComponent includes the table "currency" key. So the component inside the column header/footer is incorrectly being treated as a stamped component. This prevents the update of components inside table header/footer (as a result of changes in stamped components in the table body) using partialTriggers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS FOR
TABLE COLUMN HEADER/FOOTER
Posted by "Kamran Kashanian (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kamran Kashanian updated TRINIDAD-961:
--------------------------------------
Status: Patch Available (was: Reopened)
> NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
> -------------------------------------------------------------
>
> Key: TRINIDAD-961
> URL: https://issues.apache.org/jira/browse/TRINIDAD-961
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.6-core
> Environment: All
> Reporter: Kamran Kashanian
> Assignee: Matt Cooper
> Fix For: 1.2.8-core
>
> Attachments: trinidad_1.2.x.patch
>
>
> If a UIComponent inside the table column header/footer contains a partialTrigger referencing the component ID of a stamped component inside the table. When the partialTrigger is invoked, the client ID that gets added to the partialTargets list for the header/footer UIComponent includes the table "currency" key. So the component inside the column header/footer is incorrectly being treated as a stamped component. This prevents the update of components inside table header/footer (as a result of changes in stamped components in the table body) using partialTriggers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS FOR
TABLE COLUMN HEADER/FOOTER
Posted by "Andrew Robinson (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570520#action_12570520 ]
Andrew Robinson commented on TRINIDAD-961:
------------------------------------------
Could you try building the latest trunk (try 1.2.7-SNAPSHOT). There were some partialTrigger changes.
> NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
> -------------------------------------------------------------
>
> Key: TRINIDAD-961
> URL: https://issues.apache.org/jira/browse/TRINIDAD-961
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.6-core
> Environment: All
> Reporter: Kamran Kashanian
>
> If a UIComponent inside the table column header/footer contains a partialTrigger referencing the component ID of a stamped component inside the table. When the partialTrigger is invoked, the client ID that gets added to the partialTargets list for the header/footer UIComponent includes the table "currency" key. So the component inside the column header/footer is incorrectly being treated as a stamped component. This prevents the update of components inside table header/footer (as a result of changes in stamped components in the table body) using partialTriggers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS FOR
TABLE COLUMN HEADER/FOOTER
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083 ]
Scott O'Bryan commented on TRINIDAD-961:
----------------------------------------
I'm not sure I agree with this patch. This change involves adding an abstract method to UIXComponent and assumes that everyone making custom components is going to extend UIXComponentBase. This is not something that is enforced by either the contract OR the api.
Since UIXComponent is already an abstract class (and not an interface), I think the default implementation of this new method needs to be on UIXComponent so that custom component code continues to work. I know the convention in UIXComponent has been that this class is totally abstract, but I can't help but think that the reason for making this an abstract class rather then an interface was so that we did NOT run into these types of issues as new methods were added.
What I'm basically proposing is instead of making the new method and abstract method, that we provide a simple default implementation so that any code extending this class would "just work" between 1.2.6 and 1.2.7..
> NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
> -------------------------------------------------------------
>
> Key: TRINIDAD-961
> URL: https://issues.apache.org/jira/browse/TRINIDAD-961
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.6-core
> Environment: All
> Reporter: Kamran Kashanian
> Attachments: trinidad_1.2.x.patch
>
>
> If a UIComponent inside the table column header/footer contains a partialTrigger referencing the component ID of a stamped component inside the table. When the partialTrigger is invoked, the client ID that gets added to the partialTargets list for the header/footer UIComponent includes the table "currency" key. So the component inside the column header/footer is incorrectly being treated as a stamped component. This prevents the update of components inside table header/footer (as a result of changes in stamped components in the table body) using partialTriggers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS FOR
TABLE COLUMN HEADER/FOOTER
Posted by "Kamran Kashanian (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kamran Kashanian reopened TRINIDAD-961:
---------------------------------------
I need to reopen this issue and provide a new patch.
Some profiling of the table and treeTable component performances with this patch indicate that the getContainerClientId() method in the patch can potentially get called a large number of times. This method is called during the table/treeTable stamping process for every stamped child in the body of the table during decode/validate/update/render-response phases. It is also called for non-stamped children in the table/column header/footer facets.
The implementation of getContainerClientId method in the patch was inefficient. It avoided any caching of child components in order to handle any dynamically (programmatically) added child components (child columns etc) between lifecycle phases. So in effect it built a list of child columns every time the method was called. Profiling data indicated that this was slow and memory intensive.
Providing a new patch which creates a cache of child components in the table/column header/footer facets. The getContainerClientId implementation, performs a lookup in the cache to determine if a given child component is stamped. The cache is updated at the start of each lifecycle phase in order to account for any dynamically added children between phases.
> NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
> -------------------------------------------------------------
>
> Key: TRINIDAD-961
> URL: https://issues.apache.org/jira/browse/TRINIDAD-961
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.6-core
> Environment: All
> Reporter: Kamran Kashanian
> Assignee: Matt Cooper
> Fix For: 1.2.8-core
>
> Attachments: trinidad_1.2.x.patch
>
>
> If a UIComponent inside the table column header/footer contains a partialTrigger referencing the component ID of a stamped component inside the table. When the partialTrigger is invoked, the client ID that gets added to the partialTargets list for the header/footer UIComponent includes the table "currency" key. So the component inside the column header/footer is incorrectly being treated as a stamped component. This prevents the update of components inside table header/footer (as a result of changes in stamped components in the table body) using partialTriggers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS FOR
TABLE COLUMN HEADER/FOOTER
Posted by "Kamran Kashanian (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kamran Kashanian updated TRINIDAD-961:
--------------------------------------
Status: Patch Available (was: Open)
> NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
> -------------------------------------------------------------
>
> Key: TRINIDAD-961
> URL: https://issues.apache.org/jira/browse/TRINIDAD-961
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.6-core
> Environment: All
> Reporter: Kamran Kashanian
>
> If a UIComponent inside the table column header/footer contains a partialTrigger referencing the component ID of a stamped component inside the table. When the partialTrigger is invoked, the client ID that gets added to the partialTargets list for the header/footer UIComponent includes the table "currency" key. So the component inside the column header/footer is incorrectly being treated as a stamped component. This prevents the update of components inside table header/footer (as a result of changes in stamped components in the table body) using partialTriggers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS FOR
TABLE COLUMN HEADER/FOOTER
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott O'Bryan updated TRINIDAD-961:
-----------------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
> NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
> -------------------------------------------------------------
>
> Key: TRINIDAD-961
> URL: https://issues.apache.org/jira/browse/TRINIDAD-961
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.6-core
> Environment: All
> Reporter: Kamran Kashanian
> Assignee: Scott O'Bryan
> Fix For: 1.2.8-core
>
> Attachments: Trinidad.1.2.8.1.patch, trinidad_1.2.x.patch, trunk.1.2.x.patch
>
>
> If a UIComponent inside the table column header/footer contains a partialTrigger referencing the component ID of a stamped component inside the table. When the partialTrigger is invoked, the client ID that gets added to the partialTargets list for the header/footer UIComponent includes the table "currency" key. So the component inside the column header/footer is incorrectly being treated as a stamped component. This prevents the update of components inside table header/footer (as a result of changes in stamped components in the table body) using partialTriggers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.