OK, I've done a first-pass implementation of both: * ISIS-781: editable view models, and * ISIS-800: wizards
for the first, the view model must implement ViewModel.Cloneable. The way it works is that the view model is immutable so far as the rest of the framework is concerned, but (by implementing the Cloneable interface) when the view model is next re-rendered it is actually the clone. for the second, the view model must implement Wizard. This is actually a sub-interface of ViewModel.Cloneable that defines next, previous and finish methods. The todo/quickstart app has been updated to use this feature; see ToDoItemWizard. See also the cool use of contributed actions through the "Categorized" interface that contributes both to ToDoItemWizard and also the ToDoItem entity. ~~~ The design as it stands does mean there's a little bit of boilerplate to implement these various methods, but what we now have is probably good enough to ship in the next release. Any feedback welcome Dan On 10 June 2014 13:16, Dan Haywood <d...@haywood-associates.co.uk> wrote: > > > > On 10 June 2014 13:09, Erik de Hair <e...@pocos.nl> wrote: > >> The action (on a domain object) has the following code: >> >> CreateSubscriptionViewModel viewModel = new >> CreateSubscriptionViewModel(); // or getContainer.newViewModelInstance.... >> viewModel.viewModelInit(newSubscription.title()); >> viewModel.setSubscription(newSubscripiton); // newSubscription is a >> newTransientObject created earlier >> return viewModel; >> >> > > > >> I put the newSubscription in the viewmodel because I need this >> subscription in a later step to add some more data to it. But getting the >> subscription (or a property) for the ViewModel rendering gives a null >> pointer exception. >> >> > A stack trace would be useful. > > But just to check: you have configured the MementoServiceDefault and the > BookmarkServiceDefault ? > > > > >> I looked at the ToDoItem examples and Dileepa's code. I can see no >> conceptual difference except that ToDoItem uses persisted entities and >> Dileepa only sets the memento and does not pass more 'complex' objects in >> the ViewModel. Do the objects have to be serializable or do I miss >> something else? >> >> > This is probably the issue. Making the object serializable might solve > things, but it's rather unpalatable. > > Rather than creating a transient object, instead have the wizard store the > state (ie the builder pattern), and only create (and persist) the object > when done. > > ~~~ > Isis does, in fact, have the ability to create serializable mementos even > from non-serializable transient objects (a left over from the days when > Isis' architecture was client/server); but this isn't currently exposed in > a user-friendly applib service. > > We could look to doing so if the above approach is unpalatable, eg as an > extension of MementoService. > > Dan > > > > > > >> Any idea? >> >> On 06/10/2014 12:07 PM, Dan Haywood wrote: >> >> On 10 June 2014 10:52, Erik de Hair <e...@pocos.nl><mailto:e...@pocos.nl> >> wrote: >> >> >> >> Hi Dan, >> >> That's not the answer I hoped for ;-) >> >> >> >> >> sorry bout that! >> >> >> >> >> It looks like the ViewModels only work with persisted entities. Is that >> correct? >> >> >> >> >> Not exactly. A view model can hold references to any data; that's what >> the >> MementoService is for. >> >> Our Google Summer of Coder (Dileepa) has written a view model that wraps >> some JSON representing a gmail obtained via a web service, for example. >> >> Fundamentally a view model just has the ability to marshall itself to/from >> a string. We use that string as its OID, which appears in the URL. When >> we next interact with the view model, Isis recreates the view model from >> that OID. What the view model does with its string is up to it. >> >> >> >> >> >> >> What I try to accomplish right now (as a work around) is to return a >> ViewModel from an action with the posted data from the action put into >> that >> viewmodel and than call some actions on that viewmodel. If it is possible >> to return a fresh viewmodel every time I return from an action, it looks a >> bit like a wizard. At least I can build some data model in memory and >> persist this model when ready. Should that be possible? >> >> >> >> >> Yup, that's the best we can offer for now. >> >> >> >> >> >> I will elaborate my wishes in the ticket you raised. >> >> Wat is the use of a @NotPersistable-entity like described in [1]? >> >> >> >> >> It was a way of saying that an object can never be persisted, ie a domain >> constraint. But when using JDO objectstore it is somewhat redundant (or >> at >> least not fully implemented), because we delegate the responsibility for >> doing persistence to JDO/DN. >> >> When Isis 2.0 comes along, some of these older annotations might end up >> being deprecated/removed. >> >> Cheers >> Dan >> >> >> >> >> >> Thanks, >> Erik >> >> [1] >> >> http://isis.apache.org/more-advanced-topics/how-to-07-040-How-to-specify-that-an-object-should-not-be-persisted.html >> >> >> On 06/09/2014 07:59 AM, Dan Haywood wrote: >> >> Hi Erik, >> Short answer is that we don't really (properly) support this. And we >> should. >> >> I agree that @NotPersistable is confusing and its not clear what to use; >> the right solution would be to implement a view model (currently: >> implement >> the ViewModel interface), and then - optionally - write a custom >> ComponentFactory for the Wicket viewer to render the wizard appropriately. >> >> But the snag even with the above is that (currently) view models are >> immutable; they support actions but their properties cannot be edited. >> >> I can see the way forward on this; I don't think it's difficult, but it >> will require a change in core and probably the wicket viewer also. >> >> If you want then raise a ticket for this requirement, and sketch how you'd >> like it to work. >> >> Cheers >> Dan >> >> >> >> On 6 June 2014 17:40, Erik de Hair <e...@pocos.nl><mailto:e...@pocos.nl >> ><mailto:e...@pocos.nl><mailto:e...@pocos.nl> >> wrote: >> >> >> >> Ok, I've found the @NotPersistable annotation but don't know how to use >> this. I get an error message saying the object is not persistent. Extended >> my entity from AbstractDomainObject later, but that doesn't help. >> >> Erik >> >> On 06/06/2014 04:07 PM, Erik de Hair wrote: >> >> Hi, >> >> Is it in some way possible to create a wizard like form or open an action >> with an action? I tried to return a not yet persisted object from an >> action >> and hoped I could edit some properties and add some elements to >> collections >> of the object before persisting it to the database... >> >> Thanks, >> Erik >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >
