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 <davo...@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 <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/ > > >>> > > >>> > > >
