isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: [DISCUSSION] next gen viewer
Date Sat, 07 Sep 2013 10:16:11 GMT
Hi David
(as an aside, could you subscribe to the dev list, so that I don't need to
approve any mails from you for that list).

Thanks for the analysis below; responses within....


On 7 September 2013 10:55, David Tildesley <davotnz@yahoo.co.nz> wrote:

>
> In my opinion, web UI's for internal applications were a big step
> backwards for enterprises - clumsy for users and expensive to build (at
> least before ISIS came along) compared to rich clients. I guess web
> technology has advanced to a point where it has almost caught up with rich
> client technology of 15 years ago but that's hardly something to crow
> about. The argument put forward for web UI's in the enterprise was "zero
> maintenance" in terms of the desktop (all the difficulties of packaging and
> distribution of rich clients eliminated) but then rich clients caught up in
> that area (at least for Java). But then comes along smart phones and
> tablets and html5 that potentially changes the game again. Or maybe not -
> html5 turns out to not be the panacea it was touted to be and now we are
> back to the future with the horrible incompatibilities of vendors
> implementations and versions. Facebook recently publicly vented on this
> subject and have declared the end of
>  their romp with html5 and a return to native.
>

Yup, I'd agree with all of that.


>
> With ISIS able to generate many viewers, then perhaps we are looking at
> the real game changer in the enterprise being ISIS.
>

Ooh, please keep saying that!  (Still hoping for one of the opinion formers
of the tech community - the Martin Fowlers etc - to rediscover NO via Isis
and take a similar view).


>
> The DnD viewer I understood was a highly productive desktop UI for DSW? of
> Ireland.


s/was/is/

It's likely to be in production for many years to come.  But the
client/server architecture - with serialized .NET objects over web services
- leaves something to be desired; state management/synchronisation being
especially difficult.  I was very glad when we junked the remoting logic in
Isis a while back.




> Should it not live on in the form of a JFX based viewer?


It could, of course; but I guess it limits the deployment options.  If we
can achieve the same technology using web UI, then why limit the audience.

But "fat client" RO clients are possible; over in Ireland we have been
spiking a Win8 metro UI that's an RO client.



> [snip]
>
> The wicket viewer is good. However, bouncing around different objects to
> get a view of information in a "graph" can be frustrating even with the
> sliding bookmark bar when you want to go back a few steps but I guess less
> frustrating than one of those damn wizards that forces you along a
> particular process.
>

Agreed.


>
> Sometimes (maybe often) it is preferable to present an aggregated view of
> information in the UI from an object graph instance. One could achieve this
> with a custom UI (e.g. calling the ISIS domain RO viewer) however I'm
> thinking why not simply use a (transient) ISIS object instead and treat it
> as a UI model component which from my point of view simply amounts to
> making it transient and putting it in a package that indicates that it is
> not part of the domain layer and ensure that this "UI" object has a
> dependency on the domain layer but never the other way around ( no dom
> object should depend on the UI). To give you an example: Say I have a Human
> Resource domain (with
> Person--->Employment--->PositionAssigment--->Position--->OrgUnit--->Organisation)
> but I want to implement an easy to enterprise resource directory so that
> users could quickly search for people in the organisation and once found
> display all the relevant and permitted information about the
>  person on a single page so that the user doesn't have to bounce around
> the dom graph to get this information. So I have a StaffDetails aggregating
> object in the UI that dynamically aggregates the relevant information from
> the dom object graph by calling dom behaviour. Similarly I might want to
> implement a MyDetails UI object for the same reason. Does that make sense?
> To me, taking this approach makes the wicket viewer a lot more acceptable
> to users.
>
> It does make sense.  In fact, the .NET version of Naked Objects they have
implemented addressable view models, which are non-persistent but act as if
they are persistent. This originated from a code sketch I did in the RO
spec.  I don't think it'd be that hard to implement in Isis, either.

Then, in the Wicket viewer, one could register a custom ComponentFactory to
render the view model as required (using the lower-level components to
build up the pieces of the UI).

Not really a difficult piece of work (though not a priority for me right
now).  I could provide guidance to someone in your team if it's something
you'd like to explore further.

Cheers
Dan



> Regards,
> David.
>
>
>
>
>
>
>
>
> ________________________________
>  From: Dan Haywood <dan@haywood-associates.co.uk>
> To: users <users@isis.apache.org>
> Cc: dev <dev@isis.apache.org>
> Sent: Saturday, 7 September 2013 8:25 PM
> Subject: [DISCUSSION] next gen viewer
>
>
> Breaking this out to a new thread...
>
> ~~~
> Over the last few days I've (coincidentally) been having off-list
> discussions with both Maurizio and Jeroen, thinking about what the next gen
> viewer should be implemented and might look like.
>
> We're all agreed, I think, that it should be a stateless RO-based viewer,
> and that it should build on Spiro [1].
>
> In other words, the next gen viewer will be an SPA app, with AngularJS
> underneath, making RESTful calls to the Isis-provided backend.  The SPA app
> would (as they all do) use some sort of templating framework and widget
> framework for generate the GUI.  For the latter, I think that Bootstrap is
> a candidate (though Jeroen didn't agree, I think).
>
> Although (hopefully) scalable to the internet, the intent should still
> primarily be for "problem solvers, not process followers", ie for those who
> are familiar with the domain.
>
> What that implies is solving the modality problem; allowing the user to
> switch context and to associate different contexts.  The original DnD
> viewer - whatever other faults it might have had - was very good at
> supporting this, with its "desktop" (windowed) metaphor.  Adam Howard's
> (currently stagnant) AROW viewer [2] also adopts a "desktop" metaphor.
>
> At the other end of the spectrum, my Wicket viewer is very page oriented.
> This means that the user looks only at one object at a time.  The
> autocomplete stuff makes it easier to associate stuff, and the bookmarks
> panel helps provide some sense of context, but I'm the first to admit that
> the Wicket viewer is closer to a website than an webapp.
>
> Maurizio's DHTMLX viewer is more page oriented [3], but the use of tabs
> does go a long way to mitigating this.  I probably should acknowledge that
> tabs is a better metaphor for helping the user to maintain context than the
> sliding bookmarks I've implemented in the Wicket viewer.
>
> Anyway... no work on a new RO viewer is going to happen this side of Xmas,
> but it might be worth arranging some sort of get together over a offsite
> weekend (in Europe, somewhere) to thrash out ideas.    I'm thinking
> something like Mar~May next year (depending on how well Estatio beds in
> when it goes live).
>
> Let me know your thoughts, and whether you'd be interested in meeting up to
> discuss this (or any other Isis-related stuff, I suppose).
>
> Cheers
> Dan
>
>
> [1] https://github.com/nakedobjectsgroup/spiro
> [2] http://simple-dusk-6870.herokuapp.com/arow-fpc.html
> [3] http://isis-viewer-dhtmlx.appspot.com
>
>
>
>
>
> On 7 September 2013 09:03, GESCONSULTOR - Óscar Bou
> <o.bou@gesconsultor.com>wrote:
>
> > Just to clarify, the point is that our current viewer, based on
> Wavemaker,
> > is implemented in DOJO, and we have all "screen widgets composition"
> code.
> >
> > As we must "refactor" the Isis session management, perhaps a good
> solution
> > would be to re-use the js viewer code, but, as you pointed out, that will
> > be better done on the future project with Stef and Richard.
> >
> >
> > Thanks and keep the good work,
> >
> > Oscar
> >
> >
> >
> > El 06/09/2013, a las 22:47, GESCONSULTOR <o.bou@gesconsultor.com>
> > escribió:
> >
> > > Yes, that was what I meant.
> > >
> > > Thanks!
> > >
> > >
> > > El 06/09/2013, a las 21:15, Bhargav Golla <bhargav.golla@gmail.com>
> > escribió:
> > >
> > >> I am sorry. I didn't exactly understand your question. Are you asking
> > if we
> > >> can use my code with minor changes, to use it with other UI libraries?
> > If
> > >> so, currently, no. As part of my plan post GSoC, as discussed with
> Dan,
> > I
> > >> would be working on something similar to this idea, with what Stef and
> > >> Richard are working on in Spiro. We will work to improve their models
> > file
> > >> to act as a complete interface to all Isis interactions, so that
> > developers
> > >> can then develop any JS viewer by making use of this models file.
> > >>
> > >> Bhargav Golla
> > >> Developer. Freelancer.
> > >> B.E (Hons.) Computer Science
> > >> BITS-Pilani
> > >> Github <http://www.github.com/bhargavgolla> |
> > >> LinkedIN<http://www.linkedin.com/in/bhargavgolla>
> > >> | Website <http://www.bhargavgolla.com/>
> > >>
> > >>
> > >> On Sat, Sep 7, 2013 at 12:32 AM, GESCONSULTOR <o.bou@gesconsultor.com
> > >wrote:
> > >>
> > >>> Looks really well, Bhargav.
> > >>>
> > >>> Just to know, Would it be "relatively" easy to reuse the classes
> > >>> interacting with Isis (for obtaining properties and collections,
> > updating
> > >>> properties or executing actions) on an existing project made with
> other
> > >>> JavaScript UI libraries, like ExtJS, Vaadin or the ones here [1]?
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Oscar
> > >>>
> > >>>
> > >>> [1]
> > >>>
> >
> http://speckyboy.com/2010/05/17/15-javascript-web-ui-libraries-frameworks-and-libraries/
> > >>>
> > >>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message