On 3 January 2014 12:14, Ged Byrne <[email protected]> wrote:

> Hi All,
>
> I'm working with Dharmesh and I thought I'd take a step back and ask a more
> general question.
>

Thanks, Ged... what follows is helpful.



> [snip]
>
> The problem is our requirements are all in screen flows that are using an
> inductive user interface style:
> http://msdn.microsoft.com/en-us/library/ms997506.aspx
>
> That is to say, it has a process based object that fills in the details for
> domain objects through a set of wizard like screens.
>
> For example, imagine you have a car insurance app.  The domain object is a
> customer who has a vehicle, a bank account and an address history.  There
> may also be a second driver.
>
> The UI screens first captures the customer detail and asks if there is a
> second driver.  If there is, the next screen is the second driver details,
> otherwise it's the vehicle details.  Then the address history one address
> at a time and finally the bank account.
>
> In the documentation it talks about creating "wizard-like process objects"
> that aggregate some state with respect to a certain process:
>
> http://isis.apache.org/applib-guide/how-tos/how-to-07-040-How-to-specify-that-an-object-should-not-be-persisted.html
> .
>  I believe that is what we are trying to create.
>
>
That's a good guess, but there is now (as of v1.3.0+) a better way to do
this.  I must get around to updating the docs :-(

Specifically, you can make your domain object implement
org.apache.isis.applib.ViewModel interface [1].  The example todo app
demonstrates this in the ToDoItemsByCategoryViewModel class [2], by
inheriting from AbstractViewModel [3].

Basically the interface requires that the object returns a string (which
can be arbitrarily long) in its viewModelMemento() method, and this is then
passed back into the view model on each subsequent interaction, through the
viewModelInit(String) method.

Typically the contents of the string is the identifier of one or several
underlying domain objects.  Then, the view model looks up the domain
objects in each interaction.  For a wizard-like process object, the string
would also need to encode the state of the wizard so it knows where it's up
to (eg which "screen" its on).

If you're happy to build from trunk, then you'll find there's a new service
ViewModelSupport [4] - with implementation ViewModelSupportDefault [5] -
that you can use to help build these strings.  The BookmarkService [6] -
with implementation BookmarkServiceDefault [7] - can help generate a string
identifier for each domain object.



> Now we are using Isis to prototype the system.  We want to rapidly
> prototype the screens and then factor out the domain model.  In the final
> application there will be a separate presentation layer with JSF forms that
> then call the Restful Objects services, but we want to avoid that work in
> the prototype.
>
> Has anybody prototyped this style of interface before?  Do you have any
> advice to offer?
>
>
The typical way to work with Isis is from the domain object model out, so
what you are doing is somewhat against the grain.  But I think it is a
viable way to go about it.

It's probably worth identifying as many of the domain objects - even at a
high level - as you can, eg Customer, Vehicle etc.  That way your process
object/view models will have something to talk to.



> As you can see from Dharmesh's post, our current approach is one object per
> form.  Is that the right way to go about it?
>

I'd suggest one object per conversation, ie for the entire wizard.  The
"Objects for State" pattern is probably a good way of implementing the
wizard.  The different fields can be hidden/disabled (using hideXxx() and
disableXxx()) according to the state.


>
> Anything you can share with us would be greatly appreciated.
>
>
HTH, let us know how you get on.

Cheers
Dan



> Regards,
>
>
> Ged
>
>
>
[1]
https://github.com/apache/isis/blob/isis-viewer-wicket-1.3.1-RC1/core/applib/src/main/java/org/apache/isis/applib/ViewModel.java
[2]
https://github.com/apache/isis/blob/isis-viewer-wicket-1.3.1-RC1/example/application/quickstart_wicket_restful_jdo/dom/src/main/java/app/ToDoItemsByCategoryViewModel.java
[3]
https://github.com/apache/isis/blob/isis-viewer-wicket-1.3.1-RC1/core/applib/src/main/java/org/apache/isis/applib/AbstractViewModel.java
[4]
https://github.com/apache/isis/tree/master/core/applib/src/main/java/org/apache/isis/applib/services/viewmodelsupport
[5]
https://github.com/apache/isis/blob/master/core/runtime/src/main/java/org/apache/isis/core/runtime/services/viewmodelsupport/ViewModelSupportDefault.java
[6]
https://github.com/apache/isis/blob/master/core/applib/src/main/java/org/apache/isis/applib/services/bookmark/BookmarkService.java
[7]
https://github.com/apache/isis/blob/master/core/metamodel/src/main/java/org/apache/isis/core/metamodel/services/bookmarks/BookmarkServiceDefault.java






>
> On 2 January 2014 16:54, Chohan, Dharmesh <[email protected]>
> wrote:
>
> >  Hi
> >
> >
> >
> > I have 2 domain objects objectA and object.  I can persist objectA and
> > from objectA screen the control is returned to objectB domain screen.
> >
> >
> >
> > On objectB form, the screen displays the domain properties.  However the
> > screen also displays the title/header as “General” and a “Edit” button.
> >
> >
> >
> > I have 2 issues. One is after editing the form of objectB, the form is
> not
> > persisted.  The other thing is I want to replace the title of “General”
> and
> > the “Ok” button on the screen to some defined values.
> >
> >
> >
> > Please can anyone provide guidance on these issues.
> >
> >
> >
> > Thanks in advance.
> >
> > Dharmesh
> >
> >
> >
>

Reply via email to