AJAX in HTML viewers,,

[Kevin Meyer <ke...@kmz.co.za>]

I was talking to a vendor rep this morning who is considering
re-implementing their product. Naturally, I'm suggesting they use Isis
(and focus their efforts on the business domain layer).

One question that was raised was: how does Isis HTML-based viewers handle
1) auto-completion / suggestions in fields and
2) altering remaining content based on prior content values?

For (1), this smacks of Ajax? [1]

For (2), the UI should disable certain remaining fields if, for example,
a prior field is set to "false" (checkbox cleared). I realise that this
means shunting some "isDisabled"-type checks into script in the UI, and
not relying on the metamodel(?) / framework..

I suggested that in this case, the information would have to be captured
over multiple "pages", as the business logic is exercised...?

Dan - sounds like your "process wizard" (?) as referenced in your
book...



[1] http://www.wicket-library.com/wicket-examples/ajax/choice?1

Re: AJAX in HTML viewers,,

[Dan Haywood <dk...@gmail.com>]

Hi Kevin,


On 07/04/2011 15:13, Kevin Meyer wrote:
> One question that was raised was: how does Isis HTML-based viewers handle
> 1) auto-completion / suggestions in fields and
> 2) altering remaining content based on prior content values?
>
> For (1), this smacks of Ajax? [1]
It's definitely do-able.  Indeed, Naked Objects MVC has this working, 
with a contribution from one of their users [2]




> For (2), the UI should disable certain remaining fields if, for example,
> a prior field is set to "false" (checkbox cleared). I realise that this
> means shunting some "isDisabled"-type checks into script in the UI, and
> not relying on the metamodel(?) / framework..
This is trickier, and will depend on the viewer design.

At the moment, the Wicket viewer renders objects either in edit mode or 
in view mode.  But for the interaction design you're describing here 
implies is something half-way between the two ... that the object is 
always implicitly in an edit mode and tabbing out of a field will submit 
a change immediately.

That could work, but only for simple-ish objects.  Managing the 
interaction between different properties that have dependencies between 
them (eg from/to date) could be difficult in the general case if there 
isn't a "batch update" mechanism (which is what the edit mode basically 
provides).



> I suggested that in this case, the information would have to be captured
> over multiple "pages", as the business logic is exercised...?
>
> Dan - sounds like your "process wizard" (?) as referenced in your
> book...
>
Yes, the best approach might be to write a "process object" (as I 
described it; another term that is used and I think is becoming more 
popular is "view model object") which could be used for this instead.  
This would allow one to do the careful analysis to ensure that 
intra-property dependencies are properly thought through (eg by 
carefully tracking the implied state of the object and rendering 
properties appropriately with respect to its state).

In principle the Wicket viewer could support this, because it allows 
different pages to be used for different objects.  I daresay Rob's 
Scimpi viewer could support this too.


Dan

[2] http://forum.nakedobjects.net/viewtopic.php?f=1&t=3331 
<http://forum.nakedobjects.net/viewtopic.php?f=1&t=3331>


>
> [1] http://www.wicket-library.com/wicket-examples/ajax/choice?1
>
>
>
>