i’ve found two problems when using the bulkEditor component in the case of composition usage.
The example:
Customer --(composition)–> Order
Customer.edit has a table with Orders. I added a bulkEditor to the table.
Now the two following problems occur:
When i create a new user and add two orders (the customer is not persisted yet). When i use the bulkEditor to change the orderDate for both newly created orders, the bulk editor says: “it will update 0 orders” - and act accordingly. So it just doesn’t seem to work at all when the entities are not persisted.
When i store the customer and reopen it, then use the bulkEditor for both orders in order to change its orderDate, the bulkEditor will say “it will update 2 orders”. This is correct and it will actually update the entities. But this is only displayed if i hit save on the customer and reopen it once again. Until then, the table does contain the orders with their old values.
Attached you’ll find the described example. Perhaps you might want to have a look at it.
Thank you for reporting these issues, but currently BulkEditor does not support work with non-persisted entities. It commits all the data directly to the database. I think that it can be implemented but I don’t see enough demand on that. Could you elaborate a bit on this topic and reveal your needs for these cases?
thanks for the answer. Sure i can. Let’s say that you have a master entity (Customer) and there are Composite Entities (Order) (as in the example).
You create a user interface which just has a browse screen for customers, not for Orders. The reason might be, that you want to display certain information about the customer or customer related attributes (not the orders, but say customer.customerType.name, customer.customerTurnoverGruop.minTurnover etc.) on the top of the customer editor in order to give the user some more information about the customer.
So, basically after choosing a particular customer, the customer editor is the starting point of the UI.
In this case the only way to create Orders is in the customer editor. Now it is required to use everything within the customer editor.
The alternative would be to create a normal browse screen that can be accessed through the related entites (or just as a normal menu entry) where the customer has to be selected first. In this case, it would work as expected.
So the underlying question is, if you would advice to go more into the direction of using plain browse screens (and put the customer information on top) to now have some of the problems that occur when using it from within the customer editor.
This actually brings me to another question that i have though of: Lets assume we go that route of using a normal browse screen. Can you imagine if is possible to somehow drill down in your entity graph so that you cut of one dimension for a particular time (which is done by selecting a specific customer) and then the whole software acts as if the customer selection is a transparent filter. This would mean, all browse screens will transparently filter for the customer etc. Actually this is probably part of another topic, but i just want to mention it here because it would also solve the problem…