Dealing with editing of nested objects in a multiple screens for a single entity

[Bas Gooren <ba...@iswd.nl>]

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

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

Re: Dealing with editing of nested objects in a multiple screens for a single entity

[Peter Henderson <pe...@starjar.com>]

Hi Bas,

On Thu, 16 Jan 2020 at 10:41, Bas Gooren <ba...@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

Re: Dealing with editing of nested objects in a multiple screens for a single entity

[Sven Meier <sv...@meiers.net>]

Hi Bas,

 >set of custom models that remembers what was provided in “setObject” 
and can later replay this

in my experience most attempts on putting to much logic into model 
implementations have failed.
Long class names (ahem NestedPropertyChangeListenerModel) or deeply 
nested model delegations are warning signs for me.

Change tracking is hard, so I'd advice to work directly on your entities.
I'd go with a) or c) "always keep a default variant in the product".

Have fun
Sven



On 16.01.20 11:41, Bas Gooren 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
>
> 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org