>
> Would you mind to elaborate on this a bit? What do you do in your forms?
> How do you handle state there? Do you use view models that are
> serializable? Do you keep state in local variables and propagate it to the
> domain object in every request after it is reloaded?


Sure.

We use DTOs/View Models for most of our forms. We started out with
manipulating domain objects directly, but it caused too many headaches with
serialization and detaching/re-attaching entities etc.
Domain objects are only used as Wicket (loadable detachable) models when
the manipulation is just a single step that can be persisted to the DB
right away. Your ajax link is a good example. Also single-page forms where
the final "Save/Next" button persists the changes to the DB. Whenever we
have a multi-step process (like a wizard) for creating or editing domain
objects, we use custom view models.

Thomas

On Sun, Aug 4, 2019 at 11:53 AM mscoon <[email protected]> wrote:

> Hi,
>
> If you don't mind me following up on your comment...
>
>
> > Personally, I rarely encounter serialization issues. None of our domain
> > objects implement Serializable. They can only be used with
> > LoadableDetachableModels that only store the identifier.
> >
> >>
> >>
> Would you mind to elaborate on this a bit? What do you do in your forms?
> How do you handle state there? Do you use view models that are
> serializable? Do you keep state in local variables and propagate it to the
> domain object in every request after it is reloaded?
>
> We often use serializable domain objects so that keeping state on the
> object is simple. For example if you have an ajax link that increments a
> property of the domain object, you simply increment the property and rely
> on the object being serialized for keeping state.
>
> Cheers
> Marios
>

Reply via email to