Lookup(Picker)Field Loses Drop-Down List When Parent Not Saved

Support
#1

I’m using a composition: Consignment → NoPalletItem. The NoPalletItem points to Location and SpaceCode entities.

The NoPalletItem editor has slightly complicated logic that allows the SpaceCode to be calculated by specifying 2 different locations that are part of a “zone” (attribute of the Location entity) or entered manually when a single Location is selected that is not part of a zone.

From Consignment browse tab I can successfully create a NoPalletItem that has 2 locations in a zone and auto-calculate the SpaceCode.

I don’t hit save on the Consignment.

I select and edit the NoPalletItem to change the second location field – the drop down now only contains the already present single entry (in fact this happens for ANY NoPalletItem selected from the list).

I cancel the edit and go back to the Consignment browse and save it.

I edit the NoPalletItem and the second location drop-down is now fully populated.

I can browse the NoPalletItems directly (not via the Consignment browser) and edit any NoPalletItem as many times as a like and the drop-down field for the second location is always populated correctly.

I suspect this behaviour is caused by the data-integrity checks carried out when working with compositions however I’m not sure why as I’m only trying to lookup a sublist of locations in the second lookup based on the entry in the first lookup. Also I thought the version/integrity checking really only happened during commit processing so I’m not sure what the connection is here (if any).

A further point to note is that I can edit a NoPalletItem successfully with an un-saved Consignment by simply changing the first location to a “non-zoned” one and back to a zoned one, then the second location drop-down gets the full list again. The parent consignment is still not saved so this may help identify the cause.

I’m using platform 7.2.4 and Cuba Studio 13. The problem is the same for LookupField and LookupPickerField.

I’ve managed to create a sub-project of my real project and using hsqldb created a test case which hopefully you should be able to open up and run and see the issue I see (default admin user).

#2

I’ve just found a way around the issue by not reloading the existing collection loader but by creating my own OptionsList and passing that into the LookupField:

// create a LoadContext
LoadContext<Location> loadContext = LoadContext.create(Location.class)
        .setQuery(LoadContext.createQuery("select l from warehouse7_WarehouseLocation l where l.zone = :zone")
                .setParameter("zone", event.getValue().getZone()))
        .setView(View.LOCAL);
// load list using DataManager
List<Location> locations = dataManager.loadList(loadContext);
locationField2.setOptionsList(locations);

This works and maybe the correct/better way to do it, but I still think there is a bug in the platform.

#3

Hi,
Perhaps you forgot to attach the test project.

#4

The problem is in the sequence of loading data to the data loader of the second location field.

When you open the NoPalletItem editor for a saved item, it first set the loader parameter in onBeforeShow(), loads the empty list, then reloads it with another parameter in onLocationFieldValueChange() and gets a non-empty list of options. When the screen is opened for a newly created item, the sequence is different - first it loads for actual parameter in the field change listener and then for the default in the “before show” listener. This is because the newly created item is not reloaded from the database and is set to the container right away, causing field change listeners to trigger before BeforeShowEvent is sent.

You could fix the problem by simply checking if the data is already loaded in before show:

    if (locationsDc2.getItems().isEmpty()) {
        locationsDl2.setParameter("zone", "NOT-EXIST");
    }

But then the loading is still performed twice, which is not optimal. A better solution would be to use InstanceContainer.ItemPropertyChangeEvent instead of the UI field value change listener:

@Subscribe(id = "noPalletItemDc", target = Target.DATA_CONTAINER)
public void onNoPalletItemDcItemPropertyChange(InstanceContainer.ItemPropertyChangeEvent<NoPalletItem> event) {
    if (!event.getProperty().equals("location")) {
        return;
    }
    Location prevLocation = (Location) event.getPrevValue();
    Location location = (Location) event.getValue();
    // ...

Also, the loading parameter in “before show” listener should get the value from the entity property:

@Subscribe
protected void onBeforeShow(BeforeShowEvent event) {

    locationsDl2.setParameter("zone", getEditedEntity().getLocation().getZone());

Data container’s ItemPropertyChangeEvent is not sent when the item is first set to the container (unlike UI component change event), which leads to the correct sequence of events in your case and a single load on opening the screen.

#5

Hi Konstantin,
Sounds like I’ve not checked my code correctly beforereporting the “problem”. I apolgise for that and will take a look at your suggestions to fix and improve my code.

Thank you for analysing and providing a solution for a user error!

Andrew

#6

Hi Konstantin,

I followed your suggestions at it works perfectly. Thank you once again.

Andrew