isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Tildesley <>
Subject Re: [DISCUSSION] next gen viewer
Date Sat, 07 Sep 2013 09:55:24 GMT
Hi Dan,

Sounds good (for internet facing apps).

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.

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

The DnD viewer I understood was a highly productive desktop UI for DSW? of Ireland. Should
it not live on in the form of a JFX based viewer? Then the alternative jscript based viewer(s)
could deliver to a variety of portable devices or instead  a native iOS and Android ISIS
and Metro? app generated viewer.

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.

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.


 From: Dan Haywood <>
To: users <> 
Cc: dev <> 
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).



On 7 September 2013 09:03, GESCONSULTOR - Óscar Bou

> 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 <>
> escribió:
> > Yes, that was what I meant.
> >
> > Thanks!
> >
> >
> > El 06/09/2013, a las 21:15, Bhargav Golla <>
> 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 <> |
> >> LinkedIN<>
> >> | Website <>
> >>
> >>
> >> On Sat, Sep 7, 2013 at 12:32 AM, GESCONSULTOR <
> >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]
> >>>
> >>>
> >>>
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message