Further improvements committed, tickets ISIS-781 and ISIS-800 marked as resolved
Discussing off-line with Jeroen, do have some further refactorings planned, however. Specifically: ... currently support for IWizard is "hard-coded" into the Wicket viewer; it ought to be a pluggable component (such as the map and calendar components). So will probably move it out and into a separate github repo. One consequence of that is that the quickstart todo app can't demonstrate the usage. So I'll need to move that into a github repo as a separate demo. One upside is that this ought to then plug into 1.5.0, rather than relying on a new release of Isis. Also, it'll be a good resource for how to write custom components to the Wicket viewer. But the basic functionality will be as currently implemented. More to follow.... Dan On 12 June 2014 20:34, Dan Haywood <[email protected]> wrote: > 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 <[email protected]> wrote: > >> >> >> >> On 10 June 2014 13:09, Erik de Hair <[email protected]> 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 <[email protected]><mailto:[email protected]> >>> 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 <[email protected]><mailto:[email protected] >>> ><mailto:[email protected]><mailto:[email protected]> >>> 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 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >
