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. Regards, David. ________________________________ From: Dan Haywood <d...@haywood-associates.co.uk> To: users <users@isis.apache.org> Cc: dev <d...@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....@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....@gesconsultor.com> > escribió: > > > Yes, that was what I meant. > > > > Thanks! > > > > > > El 06/09/2013, a las 21:15, Bhargav Golla <bhargav.go...@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....@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/ > >>> > >>> >
