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.

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?

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