You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2013/09/07 10:25:32 UTC
[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 <bh...@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/
> >>>
> >>>
>
Re: [DISCUSSION] next gen viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 9 September 2013 03:55, David Tildesley <da...@yahoo.co.nz> wrote:
>
> Can I just check with you that adding bootstrap will provide a "master"
> html template for the site? This would be really useful for including e.g
> header meta info in one place (please correct me if this is already
> possible now).
>
I don't think that it will, David. Nor is it possible now.
If you could code sketch what you'd like to do in a new JIRA ticket, we'll
see if we could incorporate somehow. For example, using Wicket's Include
component [1] we ought to be able to include arbitrary blocks of HTML into
the page. (You could even get one of your guys to provide a little patch
:-)
Cheers
Dan
[1]
http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/markup/html/include/Include.html
>
>
>
Re: [DISCUSSION] next gen viewer
Posted by David Tildesley <da...@yahoo.co.nz>.
Hi Oscar,
+1
Can I just check with you that adding bootstrap will provide a "master" html template for the site? This would be really useful for including e.g header meta info in one place (please correct me if this is already possible now).
Regards,
David.
Oscar wrote:
> Perhaps, in the meantime, we could consider the addition of Bootstrap to
> the Wicket viewer.
> That seemed a really good solution until the new viewer debate started,
> and also that it was feasible to accomplish it on Christmas.
> There were also some contributors interested, and it can be a way to learn
> about bootstrap in the meanwhile.
>
> The end-result would be a really good (stateful) customizable viewer for
> 2014 (including some navigation improvements like those transient entities
> used only for navigation, and, perhaps, modal action dialogs) and a really
> scalable and customizable viewer from 2015 on.
Re: [DISCUSSION] next gen viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Yeah, this is very much my own thinking, too. ie +1
On 8 September 2013 09:32, GESCONSULTOR - Óscar Bou
<o....@gesconsultor.com>wrote:
>
> Seems that the new viewer has many supporters.
>
> But if the planned meeting is on march-april, it also implies that we
> cannot expect a new viewer probably until one year from now.
>
> Perhaps, in the meantime, we could consider the addition of Bootstrap to
> the Wicket viewer.
> That seemed a really good solution until the new viewer debate started,
> and also that it was feasible to accomplish it on Christmas.
> There were also some contributors interested, and it can be a way to learn
> about bootstrap in the meanwhile.
>
> The end-result would be a really good (stateful) customizable viewer for
> 2014 (including some navigation improvements like those transient entities
> used only for navigation, and, perhaps, modal action dialogs) and a really
> scalable and customizable viewer from 2015 on.
>
> What does the community think?
>
> Thanks,
>
> Oscar
>
>
>
> El 08/09/2013, a las 09:30, Dan Haywood <da...@haywood-associates.co.uk>
> escribió:
>
> > On 7 September 2013 18:58, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> >
> >> Hi Dan,
> >>
> >> I would be interested in helping out with a new viewer that is stateless
> >> and (data-type) extensible. When I first saw this thread I thought
> >> "HTML 5?" Then I saw David's reply and comment, so then maybe
> >> not..
> >>
> >>
> > Well, for myself I am keen to keep with web UI in some flavour or other.
> > We want the largest reach/most appeal. Staying with a desktop client
> > would limit that, I think. And we don't really have the resources to
> build
> > two.
> >
> > Also, for the most likely deployment cases of Isis - within an
> enterprise -
> > I would hope that a web UI is appropriate; we can more carefully specify
> > the web browsers we support. (I can see that Facebook, having to support
> > absolutely everything out there, might decide that native was easier).
> >
> >
> >
> >> I know of an application development coming up in a few years time
> >> where I'd like to push Isis, but it requires support for scientific data
> >> visualisation (waveforms, graphs and etc). So this would be an
> >> absolute must for me (the ability to add a component handler for a
> >> MIME/blob type)... (d3js.org looks interesting.. must look more into
> it)
> >>
> >>
> > Having some concrete use cases like this will really help. I agree,
> > being extensible for new data types ("mashability" ?) should be part of
> the
> > spec of the viewer. The Wicket viewer's design (chain of responsibility)
> > could be used as a starting point to thrashing this out.
> >
> >
> >
> >>
> >>> 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.
> >>
> >> Excellent idea. I'd also like to add "timezone handling" to the agenda..
> >>
> >>
> > Fair enough; we don't have a good story there.
> >
> >
> >
> >>> 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).
> >>
> >> Well, I can recommend Slovenia (EasyJet flies direct to Ljubljana)!
> >> It's a quiet little country and most people probably wouldn't consider
> >> coming here without good reason, so why not offer this as a reason..
> >> but practically I realise that somewhere more central is more likely to
> >> be favoured by all.
> >>
> >>
> > I guess all of those attending will be getting on a plane one way or
> > another; the deciding factor might be frequency of flights.
> >
> > Cheers
> > Dan
> >
> >
> >
> >> --
> >> Kevin Meyer, Cell: +386 (0)70 260 321 Ljubljana, Slovenia
> >>
>
>
Re: [DISCUSSION] next gen viewer
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Seems that the new viewer has many supporters.
But if the planned meeting is on march-april, it also implies that we cannot expect a new viewer probably until one year from now.
Perhaps, in the meantime, we could consider the addition of Bootstrap to the Wicket viewer.
That seemed a really good solution until the new viewer debate started, and also that it was feasible to accomplish it on Christmas.
There were also some contributors interested, and it can be a way to learn about bootstrap in the meanwhile.
The end-result would be a really good (stateful) customizable viewer for 2014 (including some navigation improvements like those transient entities used only for navigation, and, perhaps, modal action dialogs) and a really scalable and customizable viewer from 2015 on.
What does the community think?
Thanks,
Oscar
El 08/09/2013, a las 09:30, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On 7 September 2013 18:58, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
>> Hi Dan,
>>
>> I would be interested in helping out with a new viewer that is stateless
>> and (data-type) extensible. When I first saw this thread I thought
>> "HTML 5?" Then I saw David's reply and comment, so then maybe
>> not..
>>
>>
> Well, for myself I am keen to keep with web UI in some flavour or other.
> We want the largest reach/most appeal. Staying with a desktop client
> would limit that, I think. And we don't really have the resources to build
> two.
>
> Also, for the most likely deployment cases of Isis - within an enterprise -
> I would hope that a web UI is appropriate; we can more carefully specify
> the web browsers we support. (I can see that Facebook, having to support
> absolutely everything out there, might decide that native was easier).
>
>
>
>> I know of an application development coming up in a few years time
>> where I'd like to push Isis, but it requires support for scientific data
>> visualisation (waveforms, graphs and etc). So this would be an
>> absolute must for me (the ability to add a component handler for a
>> MIME/blob type)... (d3js.org looks interesting.. must look more into it)
>>
>>
> Having some concrete use cases like this will really help. I agree,
> being extensible for new data types ("mashability" ?) should be part of the
> spec of the viewer. The Wicket viewer's design (chain of responsibility)
> could be used as a starting point to thrashing this out.
>
>
>
>>
>>> 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.
>>
>> Excellent idea. I'd also like to add "timezone handling" to the agenda..
>>
>>
> Fair enough; we don't have a good story there.
>
>
>
>>> 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).
>>
>> Well, I can recommend Slovenia (EasyJet flies direct to Ljubljana)!
>> It's a quiet little country and most people probably wouldn't consider
>> coming here without good reason, so why not offer this as a reason..
>> but practically I realise that somewhere more central is more likely to
>> be favoured by all.
>>
>>
> I guess all of those attending will be getting on a plane one way or
> another; the deciding factor might be frequency of flights.
>
> Cheers
> Dan
>
>
>
>> --
>> Kevin Meyer, Cell: +386 (0)70 260 321 Ljubljana, Slovenia
>>
Re: [DISCUSSION] next gen viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 7 September 2013 18:58, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> Hi Dan,
>
> I would be interested in helping out with a new viewer that is stateless
> and (data-type) extensible. When I first saw this thread I thought
> "HTML 5?" Then I saw David's reply and comment, so then maybe
> not..
>
>
Well, for myself I am keen to keep with web UI in some flavour or other.
We want the largest reach/most appeal. Staying with a desktop client
would limit that, I think. And we don't really have the resources to build
two.
Also, for the most likely deployment cases of Isis - within an enterprise -
I would hope that a web UI is appropriate; we can more carefully specify
the web browsers we support. (I can see that Facebook, having to support
absolutely everything out there, might decide that native was easier).
> I know of an application development coming up in a few years time
> where I'd like to push Isis, but it requires support for scientific data
> visualisation (waveforms, graphs and etc). So this would be an
> absolute must for me (the ability to add a component handler for a
> MIME/blob type)... (d3js.org looks interesting.. must look more into it)
>
>
Having some concrete use cases like this will really help. I agree,
being extensible for new data types ("mashability" ?) should be part of the
spec of the viewer. The Wicket viewer's design (chain of responsibility)
could be used as a starting point to thrashing this out.
>
> > 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.
>
> Excellent idea. I'd also like to add "timezone handling" to the agenda..
>
>
Fair enough; we don't have a good story there.
> > 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).
>
> Well, I can recommend Slovenia (EasyJet flies direct to Ljubljana)!
> It's a quiet little country and most people probably wouldn't consider
> coming here without good reason, so why not offer this as a reason..
> but practically I realise that somewhere more central is more likely to
> be favoured by all.
>
>
I guess all of those attending will be getting on a plane one way or
another; the deciding factor might be frequency of flights.
Cheers
Dan
> --
> Kevin Meyer, Cell: +386 (0)70 260 321 Ljubljana, Slovenia
>
Re: [DISCUSSION] next gen viewer
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
Hi Dan,
I would be interested in helping out with a new viewer that is stateless
and (data-type) extensible. When I first saw this thread I thought
"HTML 5?" Then I saw David's reply and comment, so then maybe
not..
I know of an application development coming up in a few years time
where I'd like to push Isis, but it requires support for scientific data
visualisation (waveforms, graphs and etc). So this would be an
absolute must for me (the ability to add a component handler for a
MIME/blob type)... (d3js.org looks interesting.. must look more into it)
> 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.
Excellent idea. I'd also like to add "timezone handling" to the agenda..
> 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).
Well, I can recommend Slovenia (EasyJet flies direct to Ljubljana)!
It's a quiet little country and most people probably wouldn't consider
coming here without good reason, so why not offer this as a reason..
but practically I realise that somewhere more central is more likely to
be favoured by all.
>
> Cheers
> Dan
--
Kevin Meyer, Cell: +386 (0)70 260 321 Ljubljana, Slovenia
Re: [DISCUSSION] next gen viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <da...@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 <da...@haywood-associates.co.uk>
> To: users <us...@isis.apache.org>
> Cc: dev <de...@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 <bh...@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/
> > >>>
> > >>>
> >
>
Re: [DISCUSSION] next gen viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <da...@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 <da...@haywood-associates.co.uk>
> To: users <us...@isis.apache.org>
> Cc: dev <de...@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 <bh...@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/
> > >>>
> > >>>
> >
>
Re: [DISCUSSION] next gen viewer
Posted by David Tildesley <da...@yahoo.co.nz>.
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 <da...@haywood-associates.co.uk>
To: users <us...@isis.apache.org>
Cc: dev <de...@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 <bh...@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/
> >>>
> >>>
>
Re: [DISCUSSION] next gen viewer
Posted by David Tildesley <da...@yahoo.co.nz>.
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 <da...@haywood-associates.co.uk>
To: users <us...@isis.apache.org>
Cc: dev <de...@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 <bh...@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/
> >>>
> >>>
>
Re: [DISCUSSION] next gen viewer
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
+1 To David :-))
>
> 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).
El 07/09/2013, a las 12:22, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On 7 September 2013 11:02, GESCONSULTOR - Óscar Bou
> <o....@gesconsultor.com>wrote:
>
>>
>>
>> First of all, the meeting is a great idea !
>> Count, at least, with me... On those dates, perhaps one mate can join.
>>
>
> Good stuff... I thought you might be interested!
>
>
>
>>
>> Regarding the UI, I'm also a big fan of bootstrap. As there's a clear
>> distinction between code and themes, and with such high adoption, in the
>> future we will be able to change the UI appearance easily (for "selling"
>> software that's a really important point, competing with packages with
>> similar functionalities).
>>
>
> Yeah, themeability is important if Isis is to succeed as a framework.
>
>
>>
>> Regarding the tab "metaphor", we are using it together with modal forms
>> (in "excess", I would say... And as we don't have a "modern" theme right
>> now seems a bit updated; that was also a plus for the wicket migration to
>> bootstrap :-).
>>
>> We like the SPA metaphor, but a proper mechanism for navigating and
>> bookmarking an entity's form or action form is needed.
>>
>
> The ideal might be to find some way of combining the hierarchical grouping
> capability of the sliding bookmark panel with the accessibility of the
> tabs. Perhaps each tab is the root aggregate, but lets the user select any
> object within the aggregate.
>
> These are the sort of ideas we should kick around in a face-to-face meetup.
>
>
>>
>> Seeing the Spiro screenshots, the navigation metaphor, including the " +
>> ", seems a good idea, but as it's opening the linked entity to the right
>> (on current screenshots) instead of directly opening the entity's page (or
>> SPA form), I'm not sure about user-adoption. It also requires the right
>> part of the screen (on those screenshots) to be empty, in order to show it.
>>
>> Perhaps there's a slight variation that could adapt better to user
>> expectations and screen size. When first clicked, the entity could show on
>> a modal form (not loosing the main context). In that modal form the " + "
>> button would be available and, when clicked, it would changed the "context"
>> by closing the modal form and opening on the main screen that entity's form
>> - or action form -.
>>
>> Not sure... Perhaps some user-adoption tests needed :-)
>>
>>
> Yeah, coming up with a usable generic UI is non-trivial, irrespective of
> the actual technologies used.
>
> They are going to be doing some more work on Spiro soon; that might come up
> with some more ideas.
>
> Cheers
> Dan
>
>
>
>>
>> Regards,
>>
>> Oscar
>>
>>
>>
>> El 07/09/2013, a las 10:25, Dan Haywood <da...@haywood-associates.co.uk>
>> escribió:
>>
>>> 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 <bh...@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/
>>>>>>>
>>>>>>>
>>>>
>>
>>
Re: [DISCUSSION] next gen viewer
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
+1 To David :-))
>
> 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).
El 07/09/2013, a las 12:22, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On 7 September 2013 11:02, GESCONSULTOR - Óscar Bou
> <o....@gesconsultor.com>wrote:
>
>>
>>
>> First of all, the meeting is a great idea !
>> Count, at least, with me... On those dates, perhaps one mate can join.
>>
>
> Good stuff... I thought you might be interested!
>
>
>
>>
>> Regarding the UI, I'm also a big fan of bootstrap. As there's a clear
>> distinction between code and themes, and with such high adoption, in the
>> future we will be able to change the UI appearance easily (for "selling"
>> software that's a really important point, competing with packages with
>> similar functionalities).
>>
>
> Yeah, themeability is important if Isis is to succeed as a framework.
>
>
>>
>> Regarding the tab "metaphor", we are using it together with modal forms
>> (in "excess", I would say... And as we don't have a "modern" theme right
>> now seems a bit updated; that was also a plus for the wicket migration to
>> bootstrap :-).
>>
>> We like the SPA metaphor, but a proper mechanism for navigating and
>> bookmarking an entity's form or action form is needed.
>>
>
> The ideal might be to find some way of combining the hierarchical grouping
> capability of the sliding bookmark panel with the accessibility of the
> tabs. Perhaps each tab is the root aggregate, but lets the user select any
> object within the aggregate.
>
> These are the sort of ideas we should kick around in a face-to-face meetup.
>
>
>>
>> Seeing the Spiro screenshots, the navigation metaphor, including the " +
>> ", seems a good idea, but as it's opening the linked entity to the right
>> (on current screenshots) instead of directly opening the entity's page (or
>> SPA form), I'm not sure about user-adoption. It also requires the right
>> part of the screen (on those screenshots) to be empty, in order to show it.
>>
>> Perhaps there's a slight variation that could adapt better to user
>> expectations and screen size. When first clicked, the entity could show on
>> a modal form (not loosing the main context). In that modal form the " + "
>> button would be available and, when clicked, it would changed the "context"
>> by closing the modal form and opening on the main screen that entity's form
>> - or action form -.
>>
>> Not sure... Perhaps some user-adoption tests needed :-)
>>
>>
> Yeah, coming up with a usable generic UI is non-trivial, irrespective of
> the actual technologies used.
>
> They are going to be doing some more work on Spiro soon; that might come up
> with some more ideas.
>
> Cheers
> Dan
>
>
>
>>
>> Regards,
>>
>> Oscar
>>
>>
>>
>> El 07/09/2013, a las 10:25, Dan Haywood <da...@haywood-associates.co.uk>
>> escribió:
>>
>>> 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 <bh...@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/
>>>>>>>
>>>>>>>
>>>>
>>
>>
Re: [DISCUSSION] next gen viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 7 September 2013 11:02, GESCONSULTOR - Óscar Bou
<o....@gesconsultor.com>wrote:
>
>
> First of all, the meeting is a great idea !
> Count, at least, with me... On those dates, perhaps one mate can join.
>
Good stuff... I thought you might be interested!
>
> Regarding the UI, I'm also a big fan of bootstrap. As there's a clear
> distinction between code and themes, and with such high adoption, in the
> future we will be able to change the UI appearance easily (for "selling"
> software that's a really important point, competing with packages with
> similar functionalities).
>
Yeah, themeability is important if Isis is to succeed as a framework.
>
> Regarding the tab "metaphor", we are using it together with modal forms
> (in "excess", I would say... And as we don't have a "modern" theme right
> now seems a bit updated; that was also a plus for the wicket migration to
> bootstrap :-).
>
> We like the SPA metaphor, but a proper mechanism for navigating and
> bookmarking an entity's form or action form is needed.
>
The ideal might be to find some way of combining the hierarchical grouping
capability of the sliding bookmark panel with the accessibility of the
tabs. Perhaps each tab is the root aggregate, but lets the user select any
object within the aggregate.
These are the sort of ideas we should kick around in a face-to-face meetup.
>
> Seeing the Spiro screenshots, the navigation metaphor, including the " +
> ", seems a good idea, but as it's opening the linked entity to the right
> (on current screenshots) instead of directly opening the entity's page (or
> SPA form), I'm not sure about user-adoption. It also requires the right
> part of the screen (on those screenshots) to be empty, in order to show it.
>
> Perhaps there's a slight variation that could adapt better to user
> expectations and screen size. When first clicked, the entity could show on
> a modal form (not loosing the main context). In that modal form the " + "
> button would be available and, when clicked, it would changed the "context"
> by closing the modal form and opening on the main screen that entity's form
> - or action form -.
>
> Not sure... Perhaps some user-adoption tests needed :-)
>
>
Yeah, coming up with a usable generic UI is non-trivial, irrespective of
the actual technologies used.
They are going to be doing some more work on Spiro soon; that might come up
with some more ideas.
Cheers
Dan
>
> Regards,
>
> Oscar
>
>
>
> El 07/09/2013, a las 10:25, Dan Haywood <da...@haywood-associates.co.uk>
> escribió:
>
> > 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 <bh...@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/
> >>>>>
> >>>>>
> >>
>
>
Re: [DISCUSSION] next gen viewer
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
First of all, the meeting is a great idea !
Count, at least, with me... On those dates, perhaps one mate can join.
Regarding the UI, I'm also a big fan of bootstrap. As there's a clear distinction between code and themes, and with such high adoption, in the future we will be able to change the UI appearance easily (for "selling" software that's a really important point, competing with packages with similar functionalities).
Regarding the tab "metaphor", we are using it together with modal forms (in "excess", I would say... And as we don't have a "modern" theme right now seems a bit updated; that was also a plus for the wicket migration to bootstrap :-).
We like the SPA metaphor, but a proper mechanism for navigating and bookmarking an entity's form or action form is needed.
Seeing the Spiro screenshots, the navigation metaphor, including the " + ", seems a good idea, but as it's opening the linked entity to the right (on current screenshots) instead of directly opening the entity's page (or SPA form), I'm not sure about user-adoption. It also requires the right part of the screen (on those screenshots) to be empty, in order to show it.
Perhaps there's a slight variation that could adapt better to user expectations and screen size. When first clicked, the entity could show on a modal form (not loosing the main context). In that modal form the " + " button would be available and, when clicked, it would changed the "context" by closing the modal form and opening on the main screen that entity's form - or action form -.
Not sure... Perhaps some user-adoption tests needed :-)
Regards,
Oscar
El 07/09/2013, a las 10:25, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> 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 <bh...@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/
>>>>>
>>>>>
>>
Re: [DISCUSSION] next gen viewer
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
First of all, the meeting is a great idea !
Count, at least, with me... On those dates, perhaps one mate can join.
Regarding the UI, I'm also a big fan of bootstrap. As there's a clear distinction between code and themes, and with such high adoption, in the future we will be able to change the UI appearance easily (for "selling" software that's a really important point, competing with packages with similar functionalities).
Regarding the tab "metaphor", we are using it together with modal forms (in "excess", I would say... And as we don't have a "modern" theme right now seems a bit updated; that was also a plus for the wicket migration to bootstrap :-).
We like the SPA metaphor, but a proper mechanism for navigating and bookmarking an entity's form or action form is needed.
Seeing the Spiro screenshots, the navigation metaphor, including the " + ", seems a good idea, but as it's opening the linked entity to the right (on current screenshots) instead of directly opening the entity's page (or SPA form), I'm not sure about user-adoption. It also requires the right part of the screen (on those screenshots) to be empty, in order to show it.
Perhaps there's a slight variation that could adapt better to user expectations and screen size. When first clicked, the entity could show on a modal form (not loosing the main context). In that modal form the " + " button would be available and, when clicked, it would changed the "context" by closing the modal form and opening on the main screen that entity's form - or action form -.
Not sure... Perhaps some user-adoption tests needed :-)
Regards,
Oscar
El 07/09/2013, a las 10:25, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> 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 <bh...@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/
>>>>>
>>>>>
>>
Re: [DISCUSSION] next gen viewer
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
Hi Dan,
I would be interested in helping out with a new viewer that is stateless
and (data-type) extensible. When I first saw this thread I thought
"HTML 5?" Then I saw David's reply and comment, so then maybe
not..
I know of an application development coming up in a few years time
where I'd like to push Isis, but it requires support for scientific data
visualisation (waveforms, graphs and etc). So this would be an
absolute must for me (the ability to add a component handler for a
MIME/blob type)... (d3js.org looks interesting.. must look more into it)
> 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.
Excellent idea. I'd also like to add "timezone handling" to the agenda..
> 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).
Well, I can recommend Slovenia (EasyJet flies direct to Ljubljana)!
It's a quiet little country and most people probably wouldn't consider
coming here without good reason, so why not offer this as a reason..
but practically I realise that somewhere more central is more likely to
be favoured by all.
>
> Cheers
> Dan
--
Kevin Meyer, Cell: +386 (0)70 260 321 Ljubljana, Slovenia