Hi Bas, On Thu, 16 Jan 2020 at 10:41, Bas Gooren <b...@iswd.nl> wrote:
> Hi all! > > I’m currently working on an editing system which has composite elements; > > For example: > > We store Products (e.g. an iPod 64GB) and those Products have Variants > (Blue). > Since a variant cannot exist without a product, and we want to enforce that > every product has at least one variant, we want to implement this in a > single screen. > So here the Product is a composite which contains one or more Variants. > > To extend my example: a Variant has pricing based on Country, Website etc. > So the Variant is also a composite; > > In all previous projects we either > a) relaxed the requirements, like don’t require a product to have at least > one variant, which means the creation of variants happens when the Product > already exists > b) perform all editing in a single form, so everything is committed in one > go > I would avoid b) if at all possible, users don’t like being bamboozled with overly complex forms. My approach to this is similar option a) but with an added work flow. 1) Present the “Add product” form to the user. Once its been created, ensure the product has a status of “Editing” so cannot used/seen etc. 2) On the “Product detail” page show the empty list of variants, with actions to CRUD variants. Rinse and repeat for all sub lists of data. Once the product info is complete and meets business rules, allow the products status to be changed to “Live/Active/etc”. This has worked well for me, as it keeps the number of fields on a form small, so users are always making progress and data is saved early and often. Peter. > > But since our composites are more complex in this project, the UI becomes a > bit crazy, so we want to break out the nested editors. > Essentially this requires us to build some sort of change tracking feature, > like a set of custom models that remembers what was provided in “setObject” > and can later replay this. > We can then track all changes that happen in editors, and replay those > changes later (e.g. when the Product editor is submitted). > > Given that we want to support nested composites (Product -> List of Variant > -> List of VariantPrice), this can get quite complex. > > So before embarking on this, I’d like to ask if others have implemented a > similar system, or if they have other suggestions. > > I seem to recall that a long time ago there was discussion about this as > well, perhaps it was regarding a really complex > NestedPropertyChangeListenerModel (;-)) at topicus or hippo or similar. > I think it was ultimately refactored into something much simpler due to the > difficulty in maintaining it. > But alas, I cannot seem to find any mention of it anymore. > > Thank you all for reading and any input you can provide. > > Met vriendelijke groet, > Kind regards, > > Bas Gooren > -- Peter Henderson
