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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Reply via email to