Hi Sven, Thank you for your input.
Agreed - change tracking is hard and having simple models is always key. It also means everything is much simpler to reason about. This actually leads me to a new way to investigate: perhaps I can simply detach the entity for editing and merge on saving. That would make my use-case possible. In all my 13? years of wicket development I have always used EntityModels (LoadableDetachableModel subclass) to (a) load a fresh entity from the database to update, or (b) create a new instance on the fly. And a little more complex things for editing nested lists in-place in an entity editor screen, by tracking additions and deletions. But I guess those cases could be handled with detached entities, too. How are others managing this? Same like me - so with some kind of EntityModel, or do you also work with detached entities? Met vriendelijke groet, Kind regards, Bas Gooren Op 17 januari 2020 bij 21:42:54, Sven Meier (s...@meiers.net) schreef: 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
