ERXDisplayGroup.selectedObjects() returns empty array after ERXDisplayGroup.setSelectedObjects()

[a-l-a-n-z]

EOEditingContext ec = ERXEC.newEditingContext();
EOFetchSpecification fs = new EOFetchSpecification(ERAttachment.ENTITY_NAME, null, null);
NSArray<ERAttachment> attachments = ec.objectsWithFetchSpecification(fs);
EODatabaseDataSource ds = new EODatabaseDataSource(ec, ERAttachment.ENTITY_NAME);
ds.setFetchSpecification(fs);
ERXDisplayGroup group = new ERXDisplayGroup<ERAttachment>();
group.setDataSource(ds);
group.setSelectedObjects(new NSArray<ERAttachment>(attachments.get(0)));
System.err.println(group.selectedObjects());

This will print an empty array.

Prior to the merge of pull request #535 ( commit c62ea95), this would print an array of the selectedObjects.

This is particularly causing a problem with D2W, where it would be common to do something such as

ERDPickPageInterface ppi = (ERDPickPageInterface) D2W.factory().pageForConfigurationNamed("Manage_SomeEntity_PickList", session);
ppi.setDataSource(ds);
ppi.setSelectedObjects(selectedObjects);
return ppi;

Prior to this change, the pick list page would show the selected objects.
After this commit, it shows no objects as being selected.

[darkv]

Your code is missing a fetch on the display group after setting the datasource. Without a fetch (or using setObjectArray(array)) your display group is empty and thus cannot select an object it doesn't contain:

ERXDisplayGroup group = new ERXDisplayGroup();
group.setDataSource(ds);
group.fetch();
group.setSelectedObjects(new NSArray(attachments.get(0)));

[a-l-a-n-z]

I agree, that's fine for a DG, but for D2W, it means that I'd have to do this for every single place in all my code where I use a Pick List Page.

ERDPickPageInterface ppi = (ERDPickPageInterface) D2W.factory().pageForConfigurationNamed("Manage_SomeEntity_PickList", session);
ppi.setDataSource(ds);
((ERD2WListPage) ppi).displayGroup().fetch();
ppi.setSelectedObjects(selectedObjects);
return ppi;

[darkv]

I am not familiar with the D2W workflows but the "old" behavior of ERXDisplayGroup (i.e. the current one of WODisplayGroup) is illogical. Selecting elements in a container that is empty doesn't make sense. Either fetching or explicitly setting an object array would be the correct way to go.

How is your ERDPickPageInterface implementing class handling the fetch? Is it fetching at all? Looking at that interface you probably should do:

ERDPickPageInterface ppi = (ERDPickPageInterface) D2W.factory().pageForConfigurationNamed("Manage_SomeEntity_PickList", session);
ppi.setChoices(selectedObjects);
ppi.setSelectedObjects(selectedObjects);
return ppi;

[a-l-a-n-z]

It's using ERD2WPickListPage. It's clearly fetching at some point as the EOs are being retrieved and the data is being displayed. This code has worked for years until this change was made to wonder.

[darkv]

That brings up the old question: should we keep broken things in WO unchanged to support old code without modifications, or should those get fixed in Wonder?

Adding another property to the already existing trillions of properties in Wonder to control ERXDisplayGroup's behavior is not a good solution as it either would let the old logic active leaving the now fixed bug open for new developments or enabling the new logic making it necessary to manually switch it off for legacy projects. Doing the latter one you could just go ahead and fix the app instead. So a property would only solve part of the problem, either old or new projects will need modifications (setting property or fixing code). I will leave that decision to the other committers.

[paulhoadley]

That brings up the old question: should we keep broken things in WO unchanged to support old code without modifications, or should those get fixed in Wonder?

If you're after general opinions here (I'm not necessarily commenting on this specific case), then I lean heavily towards fixing breakages in Wonder, otherwise what's the point? Backwards compatibility should be preserved where possible, but not at the expense of deliberately leaving broken behaviour unfixed. If you need legacy code to be able to run untouched forever, pick a version in the Wonder timeline where it works, and stop updating. Living on the bleeding edge of Wonder and preserving legacy behaviour are contradictory goals.

Adding another property to the already existing trillions of properties in Wonder to control ERXDisplayGroup's behavior is not a good solution

I completely agree.

[darkv]

This issue has been resolved with merge of #678.