myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Lessard <>
Subject Re: proposed API change on ChangeManager
Date Sat, 10 Apr 2010 03:01:50 GMT
+0, see below for the why.


Let see if I understand the issue correctly. We have:

- Detect a row key change (can happen if the rowKey is the PK and the PK
changes during the request processing). See 1) & 2) below please
  - Now, if the selectedRowKeys attribute, or any other attribute with a
rowKey value, was persisted within the ChangeManager, you need to update
that reference as well;
  - However, if the attribute was NOT persisted, then you don't need to do
  - So, the issue is that we have no way to know if the attribute was
persisted or not, hence why you want the new method, replacing the change if
it was previously added.

If this is correct, then what will we do when the same issue show up, but
someone has created a special AddChildComponentChange creating a component
instance with a non null selectedRowKeys attribute? We could tell him to
split his change in two I guess, or we could have a replaceComponentChange

Although I love the ChangeManager feature, I'm starting to feel like we have
opened a Pandora box. If it was still possible, I would have redesigned it
from scratch with a finite set of possible changes and a method for each of
them so that reverse operation could be detected more easily. However, both
MDS and ADF Faces Rich Client and its persisted attribute are too advanced
and big for that, not to mention unknown implementations by various users.
For our project, an empty method in the abstract class won't hurt, let hope
the same holds true for others. I still don't like that request at all, but
since I have nothing better to suggest other than prohibiting persistence of
any rowKey based attributes, I'll turn my vote to a +0.

1) I assume your issue show up with FacesCtrlHierNodeBinding when using an
Entity object with a primary key attribute set to refresh after insert and
populated by a trigger from a sequence? If so, there are other cleaner way
around this using a better CollectionModel implementation, we have that on
our project too, but that might not fix the problem if the temporary rowKey
has been persisted within the ChangeManager however.

2) How do you detect that change since you need to if you are to notify the


~ Simon

On Fri, Apr 9, 2010 at 7:17 PM, Blake Sullivan <>wrote:

>  Simon,
> The use case is this:
> Say I have a table with a selectedRowKeys attribute that contains the
> identifiers for the currently selected rows.  If my application allows a row
> key to change (perhaps during creation or because the application actually
> allows the fields that make up the primary key to be edited), we have a
> problem because we have a stale key reference.  We would like to update that
> reference with the new key, but the table doesn't know if some other piece
> of code has added the table's selectedRowKeys attribute.  So the table wants
> to check if the selectedRowKeys are already in the ChangeManager and if they
> are, add a new change.  You are right that whether the change actually
> replaces the old change or not is irrelevant as long as the result is that
> the new achange eclipses the old.  So, we have one function that does
> everything, but we could also add a new function to see if the ChangeManager
> contains an attribute change instead.
> -- Blake Sullivan
> Simon Lessard said the following On 4/8/2010 6:17 AM PT:
> -1. I really don't like it. It should be an implementation detail of the
> ChangeManager to either replace/chain the attribute change in the
> addComponentChange (or any other change for that matter). We have an
> implementation on our project doing just that. That method would make no
> sense for our use case and would introduce backward compatibility issues. I
> could change my opinion, but I'd like a detailed use case as of why this
> cannot be just an implementation detail before I do.
> Regards,
> ~ Simon
> On Wed, Apr 7, 2010 at 5:17 PM, Yuan Gao <> <>
>  hi,
> For JIRA 1761 (, we
> propose to add this API to the ChangeManager interface:
>  /**
>   * Replace an AttributeComponentChange if it's present.
>   *
>   * @param facesContext
>   * @param uiComponent
>   * @param attributeComponentChange
>   * @return the old change instance
>   */
>  public AttributeComponentChange
> replaceAttributeChangeIfPresent(FacesContext facesContext,
>    UIComponent uiComponent,
>    AttributeComponentChange attributeComponentChange);
> Let me know what do you think about it.
> Thanks,
> -Yuan

View raw message