hi, Simon,
Thanks for the vote. Please see my comments inline.
On 4/9/2010 8:01 PM, Simon Lessard wrote:
+0, see below for the why.
Blake,
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 anything;
- 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.
You are right. This is to handle the change manager part of the whole
primary key change story.JIRA is here:
https://issues.apache.org/jira/browse/TRINIDAD-1613
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 method.
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.
We are aware of the other workarounds. For example, we can recommend our
users to pre-populate the primary key fields. We just want to cover more
cases.
2) How do you detect that change since you need to if you are to
notify the ChangeManager?
FacesCtrlHierBinding gets the notification from the lower layers
bindings. In ADF the model layer is capable of firing pk change events.
Thanks,
-Yuan
Regards,
~ Simon
On Fri, Apr 9, 2010 at 7:17 PM, Blake Sullivan
<[email protected] <mailto:[email protected]>> 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<[email protected]>
<mailto:[email protected]> wrote:
hi,
For JIRA 1761 (https://issues.apache.org/jira/browse/TRINIDAD-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
