You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Adam Howard <ho...@gmail.com> on 2012/06/14 08:43:04 UTC
Introduction and another viewer
Hello list,
=======================================
This got kind of long. See link [4] for the good stuff.
=======================================
Naked Objects is something I keep coming back to every few years. All of my
work experience is with sovereign applications so the concerns that the
pattern addresses are very natural to me.
I started reading Dan's book last fall and made it part way through the
carserv example app using Isis 0.1.2-incubating. I used the DnD viewer
almost exclusively, enjoying how tangible the objects became using the
multi-window interface.
About a month ago I came back to the book and decided to start writing my
own little app alongside carserv. I grabbed the latest Isis quickstart
archetype (0.2.0-incubating) and started coding. Surprisingly, I saw that
the DnD viewer was no longer included as standard in the archetype. I used
the HTML viewer for about a week but it just didn't feel the same. With the
DnD viewer I could look at my object representations and it would help
drive my modeling. "Oh, I need a relationship here so I can drop this
object on that one."
This got me wondering. Could a browser-based multi-window interface be
built on top of the JSON viewer and a javascript ui library? I looked at
all the contenders (YUI, jQuery, MooTools, Backbone, ExtJS) and finally
settled on jQuery after seeing this blog post [1] and looking at the
jqMobile example.
I've been playing with it for the past couple weeks and I'm at the point
where I wanted to know if this is something the community is interested in.
I know it's ANOTHER viewer and I'm making no claims that it's ready (or
will ever be ready) for anyone else to use. I'm really asking if the ideas
embodied in the DnD viewer are still desired? The most important to me
being multiple objects on a virtual desktop that you can visually layout to
increase understanding.
All of the latest developments I've seen, both in Isis and NakedObject.NET,
have centered on single-object view web layouts. Was it discovered that the
desktop metaphor viewers were lacking for some users? The new web viewers
are great but they don't give me the same sense of exploration as the
original GUI. Maybe that exploration isn't needed after the model
solidifies and the app is being used.
Anyway, sorry for rambling. I tried something new and posted my little app
on Heroku. If I understand the service right you can access the JSON viewer
[2], the HTML viewer [3] and my "windowed" viewer [4] at the urls below. It
might take a few seconds to spool up. Credentials are sven/pass. Tested in
Chrome, FF, and Safari.
Again it's nowhere near complete but you can execute actions, view objects
and collections, create objects and modify properties (mostly.)
Thanks for creating a wonderful framework to build on.
--
Adam Howard
[1]
http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
[2] http://simple-dusk-6870.herokuapp.com
[3] http://simple-dusk-6870.herokuapp.com/htmlviewer
[4] http://simple-dusk-6870.herokuapp.com/services.html
Re: Introduction and another viewer
Posted by Adam Howard <ho...@gmail.com>.
Flattened is a wonderful adjective for describing web apps when compared to
the DnD viewer.
--
Adam Howard
On Thu, Jun 14, 2012 at 9:09 AM, Richardson, Jason - FSA, Kansas City, MO <
jason.richardson@kcc.usda.gov> wrote:
> I tend to agree with you Adam, I miss the interactivity of Drag and Drop
> UI's. I have never been a fan of web based UI's because of the simple fact
> of the sense of exploratory loss. I think a multi window web front end
> would be very beneficial. Standard web front ends to me have always
> provided a flattened feel to applications.
>
>
>
> Jason Richardson
> National Payments Service (NPS) Technical Lead
>
>
> -----Original Message-----
> From: Adam Howard [mailto:howard.adam@gmail.com]
> Sent: Thursday, June 14, 2012 1:43 AM
> To: isis-users@incubator.apache.org
> Subject: Introduction and another viewer
>
> Hello list,
>
> =======================================
> This got kind of long. See link [4] for the good stuff.
> =======================================
>
> Naked Objects is something I keep coming back to every few years. All of
> my work experience is with sovereign applications so the concerns that the
> pattern addresses are very natural to me.
>
> I started reading Dan's book last fall and made it part way through the
> carserv example app using Isis 0.1.2-incubating. I used the DnD viewer
> almost exclusively, enjoying how tangible the objects became using the
> multi-window interface.
>
> About a month ago I came back to the book and decided to start writing my
> own little app alongside carserv. I grabbed the latest Isis quickstart
> archetype (0.2.0-incubating) and started coding. Surprisingly, I saw that
> the DnD viewer was no longer included as standard in the archetype. I used
> the HTML viewer for about a week but it just didn't feel the same. With the
> DnD viewer I could look at my object representations and it would help
> drive my modeling. "Oh, I need a relationship here so I can drop this
> object on that one."
>
> This got me wondering. Could a browser-based multi-window interface be
> built on top of the JSON viewer and a javascript ui library? I looked at
> all the contenders (YUI, jQuery, MooTools, Backbone, ExtJS) and finally
> settled on jQuery after seeing this blog post [1] and looking at the
> jqMobile example.
>
> I've been playing with it for the past couple weeks and I'm at the point
> where I wanted to know if this is something the community is interested in.
> I know it's ANOTHER viewer and I'm making no claims that it's ready (or
> will ever be ready) for anyone else to use. I'm really asking if the ideas
> embodied in the DnD viewer are still desired? The most important to me
> being multiple objects on a virtual desktop that you can visually layout to
> increase understanding.
>
> All of the latest developments I've seen, both in Isis and
> NakedObject.NET, have centered on single-object view web layouts. Was it
> discovered that the desktop metaphor viewers were lacking for some users?
> The new web viewers are great but they don't give me the same sense of
> exploration as the original GUI. Maybe that exploration isn't needed after
> the model solidifies and the app is being used.
>
> Anyway, sorry for rambling. I tried something new and posted my little app
> on Heroku. If I understand the service right you can access the JSON viewer
> [2], the HTML viewer [3] and my "windowed" viewer [4] at the urls below. It
> might take a few seconds to spool up. Credentials are sven/pass. Tested in
> Chrome, FF, and Safari.
>
> Again it's nowhere near complete but you can execute actions, view objects
> and collections, create objects and modify properties (mostly.)
>
> Thanks for creating a wonderful framework to build on.
> --
> Adam Howard
>
> [1]
>
> http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
> [2] http://simple-dusk-6870.herokuapp.com
> [3] http://simple-dusk-6870.herokuapp.com/htmlviewer
> [4] http://simple-dusk-6870.herokuapp.com/services.html
>
>
>
>
> This electronic message contains information generated by the USDA solely
> for the intended recipients. Any unauthorized interception of this message
> or the use or disclosure of the information it contains may violate the law
> and subject the violator to civil or criminal penalties. If you believe you
> have received this message in error, please notify the sender and delete
> the email immediately.
>
>
RE: Introduction and another viewer
Posted by "Richardson, Jason - FSA, Kansas City, MO" <ja...@kcc.usda.gov>.
I tend to agree with you Adam, I miss the interactivity of Drag and Drop UI's. I have never been a fan of web based UI's because of the simple fact of the sense of exploratory loss. I think a multi window web front end would be very beneficial. Standard web front ends to me have always provided a flattened feel to applications.
Jason Richardson
National Payments Service (NPS) Technical Lead
-----Original Message-----
From: Adam Howard [mailto:howard.adam@gmail.com]
Sent: Thursday, June 14, 2012 1:43 AM
To: isis-users@incubator.apache.org
Subject: Introduction and another viewer
Hello list,
=======================================
This got kind of long. See link [4] for the good stuff.
=======================================
Naked Objects is something I keep coming back to every few years. All of my work experience is with sovereign applications so the concerns that the pattern addresses are very natural to me.
I started reading Dan's book last fall and made it part way through the carserv example app using Isis 0.1.2-incubating. I used the DnD viewer almost exclusively, enjoying how tangible the objects became using the multi-window interface.
About a month ago I came back to the book and decided to start writing my own little app alongside carserv. I grabbed the latest Isis quickstart archetype (0.2.0-incubating) and started coding. Surprisingly, I saw that the DnD viewer was no longer included as standard in the archetype. I used the HTML viewer for about a week but it just didn't feel the same. With the DnD viewer I could look at my object representations and it would help drive my modeling. "Oh, I need a relationship here so I can drop this object on that one."
This got me wondering. Could a browser-based multi-window interface be built on top of the JSON viewer and a javascript ui library? I looked at all the contenders (YUI, jQuery, MooTools, Backbone, ExtJS) and finally settled on jQuery after seeing this blog post [1] and looking at the jqMobile example.
I've been playing with it for the past couple weeks and I'm at the point where I wanted to know if this is something the community is interested in.
I know it's ANOTHER viewer and I'm making no claims that it's ready (or will ever be ready) for anyone else to use. I'm really asking if the ideas embodied in the DnD viewer are still desired? The most important to me being multiple objects on a virtual desktop that you can visually layout to increase understanding.
All of the latest developments I've seen, both in Isis and NakedObject.NET, have centered on single-object view web layouts. Was it discovered that the desktop metaphor viewers were lacking for some users? The new web viewers are great but they don't give me the same sense of exploration as the original GUI. Maybe that exploration isn't needed after the model solidifies and the app is being used.
Anyway, sorry for rambling. I tried something new and posted my little app on Heroku. If I understand the service right you can access the JSON viewer [2], the HTML viewer [3] and my "windowed" viewer [4] at the urls below. It might take a few seconds to spool up. Credentials are sven/pass. Tested in Chrome, FF, and Safari.
Again it's nowhere near complete but you can execute actions, view objects and collections, create objects and modify properties (mostly.)
Thanks for creating a wonderful framework to build on.
--
Adam Howard
[1]
http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
[2] http://simple-dusk-6870.herokuapp.com
[3] http://simple-dusk-6870.herokuapp.com/htmlviewer
[4] http://simple-dusk-6870.herokuapp.com/services.html
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
Re: Introduction and another viewer
Posted by Mark Struberg <st...@yahoo.de>.
Btw, I should have split one paragraph:
> 2. Hypothetically, I spend more time on my project and it turns out great and
> everyone wants to use it :P. Would, or should, it live at Apache? I would
> definitely be willing to donate it.
That would be very cool, and yes (as stated in the paragraph above) I think it would fit really well.
All we would need for such a bigger contribution is to file an iCLA [1].
txs and LieGrue,
strub
[1] http://www.apache.org/licenses/icla.txt
----- Original Message -----
> From: Mark Struberg <st...@yahoo.de>
> To: "isis-users@incubator.apache.org" <is...@incubator.apache.org>
> Cc:
> Sent: Saturday, June 16, 2012 12:05 PM
> Subject: Re: Introduction and another viewer
>
> Hi Adam!
>
> Really good questions and sorry that you tapped into the legal mine field that
> early. I hope this doesn't distract you too much from your intended hacking
> ;)
>
>
> Just to explain the rational behind this a bit further:
>
> _every_ OSS developer must be really carefully when it comes to legal aspects
> nowadays (Goog vs Orcl anyone?)
> This is not folks at ASF being weirdos but we only like to protect our
> contributors (thus you and others) by making them aware. That's one of the
> reasons for our VOTEs on releases, ip-clearance [1] etc. We even maintain an own
> legal-discuss list where a few pro-bono lawyers, attorneys and even law
> professors also show up and help us resolving more difficult legal questions
> (big thanks btw!).
>
>
> For the basics: an algorithm cannot be patented and also not being
> 'protected' via Intellectual Property rights (IP). But copying a bigger
> source 1:1 is problematic as it can lead to breaching IP.
> Thus taking the idea of this single loop of 4 lines and rewriting them in your
> own code is absolutely no problem. Simple copying code is never a good idea
> though - be it for only changing code style or reviewing the code that way.
>
>
> *skipping the technical ISIS questions, Dan please take over ;) *
>
>
>> 1. Is this the correct forum to discuss these issues? I will definitely be
> using
>> Isis to generate my Restful Objects with the json-viewer but I don't
> want to
>> hijack the mailing list for these kinds of things unless it can benefit the
> Isis
>> community.
>
> It's perfectly fine to discuss it here on the list and even develop the
> viewer here. If this can be done in a 'portable', way we should take
> care to keep that part abstract and independent. But it's always a good idea
> to have at least a known server part it interacts well with. If it proved stable
> and universal, we can still split it out into an own project later on. Once one
> becomes an ASF committer on one project it's really easy to 'extend'
> into other project communities as well ;)
>
>
>> 2. Hypothetically, I spend more time on my project and it turns out great
> and
>> everyone wants to use it :P. Would, or should, it live at Apache? I would
>> definitely be willing to donate it. But how would it be packaged? It's
> own
>> viewer? That doesn't make sense because it needs the json-viewer to
> operate.
>> A Maven war overlay of the json-viewer or webpp artifacts? Maybe. What if
> the
>> .NET guys want it? I'm completely unfamiliar with NuGet and how it
> manages
>> packages but I'm guessing it doesn't interoperate with Maven.
>
> No clue about that right now. We would need to take a deep look at the details.
> But I'm sure we can solve this!
>
>> I develop the code on GitHub under MIT license.
>> Johan doesn't respond and his code is abandoned.
>> I like his work so I merge our codebases giving him
>> attribution. The code is now "IP unclean.
>
> There is a very good summary and a license compat matrix here:
> http://www.apache.org/legal/3party.html
>
> MIT is perfectly fine to include in our work. Of course keep the author
> attribution.
> I'm not sure how big the parts are you like to 'copy' from him 1:1
> or if you/we more or less create own 'derivative' work by taking his
> code as base for _some_ features but changing/adopting/extending it ourselfs.
> This is really often the case if you take code from someone else.
> We also might try to reach out as PMC, telling him what we like to do and if he
> is cool with that.
> The worst thing which could happen is imo that we need to rewrite those parts we
> didn't yet touch.
>
>
> LieGrue,
> strub
>
> [1] http://incubator.apache.org/ip-clearance/index.html
> whoooops, I think we are still missing here ^^
>
>
>
> ----- Original Message -----
>> From: Adam Howard <ho...@gmail.com>
>> To: isis-users@incubator.apache.org
>> Cc:
>> Sent: Saturday, June 16, 2012 5:06 AM
>> Subject: Re: Introduction and another viewer
>>
>> I'm including responses to both Mark and Dan here. I don't know if
> that
>> meets
>> list etiquette. Also should I be including full message history in every
> reply?
>>
>>
>> On Fri, Jun 15, 2012 at 12:16 PM, Mark Struberg <st...@yahoo.de>
> wrote:
>>>
>>> The point is that here at ASF we only take code if someone explicitly
>>> gives it to us.
>>> Of course not if those are only a few lines of code or a pretty
> straight
>>> forward basic task without much own work. But it's more complex
> and
>>> originary work then we just don't take it.
>>
>> So for example, I wanted a unique id for every window and field in my ui. I
>> googled for javascript guid and found a 4 line function that generates
>> something "kind of like" a guid. Definitely random enough for my
> use.
>> Is that a
>> case where I would need to track down the author and ask if they will
> donate the
>> code to ASF. I can think of many levels of scenarios. Is there a document
>> outlining this? I don't want to "poison" my project this
> early :)
>>
>>
>> On Fri, Jun 15, 2012 at 8:59 AM, Dan Haywood
>> <da...@haywood-associates.co.uk>
>> wrote:
>>
>>>> One of those features, though, you mentioned as a possible
> negative of
>> the
>>>> DnD viewer was maintaining a client-side cache of objects...
>>>
>>> Indeed. Those caches can get out of date; at least: they do on the
> Irish
>>> system.
>>>
>>> The main workaround there is that, when the user searches for a
> Customer,
>>> then the client invalidates the client-side cache. It works well
> enough
>>> because the Customer is the usual start point for most business
> processing.
>>> But it's not generic solution, ie is a hack.
>>
>> The cache that Johan is using seems a little different. When a domain
> object is
>> returned from Isis, the graph is walked and more requests are made for
>> properties, collections and descriptions. These all feed into a local
>> representation of the state of the object. The window then displays the
> object
>> as it exists in the cache. On subsequent requests for the object, it is
> ALWAYS
>> refreshed from the server including all of its relations. So the cache is
> really
>> just used to ensure that all current views are in sync with each other. So
> you
>> change the name of a project and it's title is updated in the project
> list
>> view
>> because they are both pointing at the same javascript object.
>>
>>> Also (and this is even more of a dirty secret), the validation methods
>>> (hidden, disabled, validate) run client-side. Strictly speaking, they
>>> should run server-side which would force the latest version of the
> object
>>> to be grabbed.
>>
>> You mention the object's version. Is there an optimistic locking
> property
>> exposed in RO? I searched the 1.0.0 spec and couldn't find one.
>>
>>> This second point isn't an issue with an RO-based client, because
>>> validation must trigger a call to the REST API... there is no Java
> code
>>> client-side. Of course, with REST we can using HTTP caching to stop
> the
>>> server being flooded with calls.
>>
>> The object traversal definitely floods the server. What would the
> cache-control
>> be on an entity? Surely if we're asking we would want the latest
> version?
>> Related to the optimistic locking property above would we say "I want
>> object
>> OID:10. I currently have v123" and the server could determine that
> v123 was
>> the
>> latest and send us a 304 (or do we keep track of when we requested the
> object
>> and send that as If-modified-since?) Would it be different for value
> objects?
>> And descriptions?
>>
>>>> The next step I suppose would be to tie in either the WebSockets
> or
>>>> EventSource API...
>>>
>>> Not necessarily... it's hard to say. I guess we're all going
> to
>> learn
>>> where websockets (and related technologies) work well and where they
>> don't
>>> as HTML5 becomes commonplace.
>>>
>>> I do think it's worth taking this work forward and seeing what
> happens.
>>> But ultimately it will require server-side changes to fully
> support... It
>>> might end up being quite simple to implement, hard to say.
>>>
>>> It also occurs to me that a full WebSockets impl would mean that the
> UI
>>> would change dynamically in front of a "user's eyes".
>> Although that sounds
>>> cool, I could also see that it might be disconcerting in some
> scenarios.
>>> (You wouldn't want that to happen to a Java source file you were
>> editing,
>>> for example).
>>
>> There would be server-side changes and I don't know enough about how a
>> property
>> gets changed on an object to guess at the implementation. The two use cases
> I
>> can see for this are streaming data and update announcements. Streaming
> data
>> could be like a stock ticker or a continually updating chart. I've
> played
>> with
>> that before. The update announcements would broadcast that an object has
> changed
>> server-side. It could include the full object or just the object id. The
> viewer
>> could then choose to update the object in place or set a stale flag.
>>
>> It could be strange to see my Project view change in front of me
> (especially
>> while I'm editing!) but there are cases where this could be very
> useful:
>>
>> * Shipping: Live map of where your package is.
>> * The energy trading example from the first Naked Objects book.
>> * Collaborative drawing: Not really a business system but often used to
> describe
>> how rich we should strive to make our interfaces
>>
>> In the end, WebSockets is just a more server-friendly way to do what we
> have
>> been doing with polling.
>>
>> =========
>> Disclaimer: I love Apache. I wouldn't be able to do my job without it.
> All
>> of the questions below are purely hypothetical and for clarification
> purposes.
>>
>> One question came up while writing all this and thinking about what Mark
> said.
>> What we are really talking about here is a Restful Objects viewer and not
> an
>> Isis viewer. At least not in the same sense as the HTML, Scimpi, or Wicket
>> viewers. That being the case, the jqMobile interface, Johan's project,
> my
>> project, etc. are not Isis-specific (unless they use something in
> extensions.)
>> Two questions:
>>
>> 1. Is this the correct forum to discuss these issues? I will definitely be
> using
>> Isis to generate my Restful Objects with the json-viewer but I don't
> want to
>> hijack the mailing list for these kinds of things unless it can benefit the
> Isis
>> community.
>>
>> 2. Hypothetically, I spend more time on my project and it turns out great
> and
>> everyone wants to use it :P. Would, or should, it live at Apache? I would
>> definitely be willing to donate it. But how would it be packaged? It's
> own
>> viewer? That doesn't make sense because it needs the json-viewer to
> operate.
>> A Maven war overlay of the json-viewer or webpp artifacts? Maybe. What if
> the
>> .NET guys want it? I'm completely unfamiliar with NuGet and how it
> manages
>> packages but I'm guessing it doesn't interoperate with Maven.
>>
>> One scenario…
>> I develop the code on GitHub under MIT license. Johan doesn't respond
> and
>> his
>> code is abandoned. I like his work so I merge our codebases giving him
>> attribution. The code is now "IP unclean." If I can get it
> published
>> to maven
>> central I can create a maven war overlay of the Isis json-viewer. Isis
> users
>> can include this in their root project but it can't be a part of the
>> quickstart
>> archetype because of the IP issue. (Is that similar to the fate of the
> Hibernate
>> backend?) The project is RestfulObjects focused so it could also be shared
> with
>> the .NET community. I realize I am getting way ahead of myself but like I
> said
>> at the beginning of this email, I don't want to "poison" the
>> project early.
>>
>> I worry alot about the tone of these messages. I can see how the above
> might
>> sound combative.
>>
>> "The computer can't tell you the emotional story.
>> It can give you the exact mathematical design,
>> but what's missing is the eyebrows."
>> -- Frank Zappa
>>
>>
>> Very much enjoying the discussion.
>> --
>> Adam Howard
>>
>>
>> On Fri, Jun 15, 2012 at 8:59 AM, Dan Haywood
>> <da...@haywood-associates.co.uk> wrote:
>>> On 15 June 2012 04:06, Adam Howard <ho...@gmail.com>
> wrote:
>>>
>>> I tried it out [Johan's client] ...
>>>> He already has many of the features I wanted to add to my little
>> project.
>>>> ...
>>>>
>>>> One of those features, though, you mentioned as a possible
> negative of
>> the
>>>> DnD viewer was maintaining a client-side cache of objects. Johan
> uses
>> this
>>>> so that the views can be direct projections of the local model.
> You
>> change
>>>> a field in one view and all others views automatically update.
>>>
>>>
>>> Indeed. Those caches can get out of date; at least: they do on the
> Irish
>>> system.
>>>
>>> The main workaround there is that, when the user searches for a
> Customer,
>>> then the client invalidates the client-side cache. It works well
> enough
>>> because the Customer is the usual start point for most business
> processing.
>>> But it's not generic solution, ie is a hack.
>>>
>>> Also (and this is even more of a dirty secret), the validation methods
>>> (hidden, disabled, validate) run client-side. Strictly speaking, they
>>> should run server-side which would force the latest version of the
> object
>>> to be grabbed.
>>>
>>> This second point isn't an issue with an RO-based client, because
>>> validation must trigger a call to the REST API... there is no Java
> code
>>> client-side. Of course, with REST we can using HTTP caching to stop
> the
>>> server being flooded with calls.
>>>
>>>
>>>
>>>
>>>> The next
>>>> step I suppose would be to tie in either the WebSockets or
> EventSource
>> API
>>>> to allow the server to broadcast object change events back to all
>> connected
>>>> viewers. Would you advise against this sort of approach?
>>>
>>>
>>> Not necessarily... it's hard to say. I guess we're all going
> to
>> learn
>>> where websockets (and related technologies) work well and where they
>> don't
>>> as HTML5 becomes commonplace.
>>>
>>> I do think it's worth taking this work forward and seeing what
> happens.
>>> But ultimately it will require server-side changes to fully
> support... It
>>> might end up being quite simple to implement, hard to say.
>>>
>>> It also occurs to me that a full WebSockets impl would mean that the
> UI
>>> would change dynamically in front of a "user's eyes".
>> Although that sounds
>>> cool, I could also see that it might be disconcerting in some
> scenarios.
>>> (You wouldn't want that to happen to a Java source file you were
>> editing,
>>> for example).
>>>
>>>
>>>
>>>
>>>> Or is the
>>>> client-side cache you mention more an artifact of the remoting
>> protocol?
>>>>
>>>
>>> The bespoke remoting that we had (and have now thrown away) certainly
>>> didn't help matters. But it was also complicated by the fact that
> OIDs
>>> (the serializable object identifier by which we identify every object,
> eg
>>> "customer|123") used to be mutable. This was because an
> object
>> would be
>>> transient client-side, then get persisted (ie: users hits the
>> "save"
>>> button), then the object would be sent over the wire, persisted, and
> its
>>> OID would change. Figuring all this stuff out was complex.
>>>
>>> OIDs are now immutable, which basically means that we don't really
>
>> support
>>> transient objects anymore. I can think of patterns that would allow
> us to
>>> simulate this, though.
>>>
>>>
>>>
>>>
>>>>
>>>> On Heroku, I just signed up for the account to post this demo. It
>> seemed
>>>> like the easiest and cheapest (free) way to post a simple java
> webapp.
>>>> Especially since I didn't require an RDBMS. My 24 hours of
>> experience have
>>>> been fine.
>>>>
>>>
>>> OK, looking into it. I'm also looking at CloudBees and OpenShift,
> cos
>> I
>>> want a (non-Apache) CI server for this new project that is kicking
> off.
>>>
>>>
>>>
>>>
>>>>
>>>> On the iPad, I thought this would be cool too and then started to
> think
>>>> about how dragging and right-clicking doesn't work. Then I
> found
>> jQuery UI
>>>> Touch Punch [1] which maps the jQuery UI events to touch events:
> click
>>>> becomes tap, right-click becomes tap & hold, and they've
> made
>> dragging and
>>>> dropping work as well. I'll definitely have to try it out.
>>>>
>>>
>>> It's great how many of these UI frameworks are. Hopefully the
> REST API
>>> will allow for all sorts of interesting user interfaces going forward.
>>>
>>> Cheers
>>> Dan
>>>
>>>
>>>
>>>>
>>>> --
>>>> Adam Howard
>>>>
>>>> [1] http://touchpunch.furf.com/
>>>>
>>>> On Thu, Jun 14, 2012 at 10:12 AM, Dan Haywood
>>>> <da...@haywood-associates.co.uk>wrote:
>>>>
>>>> > Hi Adam,
>>>> > Welcome to Isis, and thanks very much for your interest and
> the
>> good work
>>>> > you've already done so far!
>>>> >
>>>> > Since you've made a number of points, I've commented
> on
>> them inline....
>>>> >
>>>> >
>>>> > On Thursday, 14 June 2012, Adam Howard wrote:
>>>> >
>>>> > >
>>>> > > I started reading Dan's book last fall and made it
> part
>> way through the
>>>> > > carserv example app using Isis 0.1.2-incubating. I used
> the
>> DnD viewer
>>>> > > almost exclusively, enjoying how tangible the objects
> became
>> using the
>>>> > > multi-window interface.
>>>> > >
>>>> >
>>>> >
>>>> >
>>>> > >
>>>> > > About a month ago I came back to the book and decided to
>
>> start writing
>>>> my
>>>> > > own little app alongside carserv. I grabbed the latest
> Isis
>> quickstart
>>>> > > archetype (0.2.0-incubating) and started coding.
>> Surprisingly, I saw
>>>> that
>>>> > > the DnD viewer was no longer included as standard in the
>
>> archetype. I
>>>> > used
>>>> > > the HTML viewer for about a week but it just didn't
> feel
>> the same. With
>>>> > the
>>>> > > DnD viewer I could look at my object representations and
> it
>> would help
>>>> > > drive my modeling. "Oh, I need a relationship here
> so I
>> can drop this
>>>> > > object on that one."
>>>> > >
>>>> >
>>>> > Like you, I also have a soft spot for the DnD viewer, and Rob
> does
>> too of
>>>> > course because it's his baby. It's also the viewer
>> that's used on the
>>>> big
>>>> > system in Ireland, used by 2,500+ people on a day-to-day
> basis.
>>>> >
>>>> > On the other hand, the DnD viewer, let's say, not the
>> prettiest of UIs.
>>>> > (For myself at least) I'm pretty sure lots of people
> have
>> seen it and
>>>> got
>>>> > turned off by Isis / the naked objects pattern....
>>>> >
>>>> > As you've probably realized, the DnD viewer code itself
> has
>> not been
>>>> > deleted. However, we removed it from the archetype because:
>>>> > * we wanted to try to include only the stuff that was
>> "complete", and in
>>>> > its current incarnation a few new features are only
>> semi-implemented
>>>> > * its status was becoming less clear with the move to remove
> the
>> remoting
>>>> > stuff
>>>> > * to figure out what it's positioning should be within
> the
>> context of the
>>>> > other viewers.
>>>> >
>>>> > Where I think we are now is that we see the DnD viewer as
> being
>>>> > resurrected, but positioned solely as a design tool for
>> developers.
>>>> >
>>>> > At some point Rob needs to do some tidy up work to remove the
>>>> > semi-implemented features and get it back to where it was
>> (ideally: I'd
>>>> > like it to look like NOF 3.0.3, with the collections on the
> left).
>> As
>>>> and
>>>> > when that's done, I'll add it back into the
> archetype.
>>>> >
>>>> > In the meantime, you can of course create a Maven module and
>> reference
>>>> the
>>>> > viewer; the module generated from the 0.1.2-incubating
> archetype
>> will
>>>> > probably work just fine (save change the version of Isis
>> referenced,
>>>> > obviously).
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > >
>>>> > > This got me wondering. Could a browser-based
> multi-window
>> interface be
>>>> > > built on top of the JSON viewer and a javascript ui
> library?
>> I looked
>>>> at
>>>> > > all the contenders (YUI, jQuery, MooTools, Backbone,
> ExtJS)
>> and finally
>>>> > > settled on jQuery after seeing this blog post [1] and
> looking
>> at the
>>>> > > jqMobile example.
>>>> > >
>>>> >
>>>> > Indeed. And in fact a chap called Johan Andries had the same
> idea
>> and
>>>> > spent some time putting together an early JS application
> against
>> the
>>>> > Restful interface using JQueryUI and Backbone. He's also
>
>> shared his
>>>> code,
>>>> > at [5].
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > >
>>>> > > I've been playing with it for the past couple weeks
> and
>> I'm at the
>>>> point
>>>> > > where I wanted to know if this is something the
> community is
>> interested
>>>> > in.
>>>> > > I know it's ANOTHER viewer and I'm making no
> claims
>> that it's ready (or
>>>> > > will ever be ready) for anyone else to use. I'm
> really
>> asking if the
>>>> > ideas
>>>> > > embodied in the DnD viewer are still desired?
>>>> >
>>>> >
>>>> > Yes, I think they are. In fact, Johan's viewer also uses
> the
>> DnD as its
>>>> > metaphor. I had a quick play with your app [4] (though not
> for
>> long)
>>>> and I
>>>> > think that Johan has gotten a little further with his
> framework
>> than you.
>>>> > That said, he doesn't seem to have done any work on it
> since
>> Nov last.
>>>> >
>>>> > So, one option you might want to explore is to contact Johan
> and
>> either
>>>> > join his project, or fork it and take it from there.
>>>> >
>>>> > For myself, I was thinking that a GUI based on ExtJS might do
> well
>> as a
>>>> > sovereign style app... but I can't see myself starting on
> that
>> this year
>>>> > (2012).
>>>> >
>>>> >
>>>> >
>>>> > > The most important to me
>>>> > > being multiple objects on a virtual desktop that you can
>
>> visually
>>>> layout
>>>> > to
>>>> > > increase understanding.
>>>> > >
>>>> >
>>>> > Agreed. Also, with toolkits such as SenchaTouch, I think
> there
>> are
>>>> > opportunities for very interactive UIs that can be deployed
> on
>> iPADs and
>>>> > the like.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > >
>>>> > > All of the latest developments I've seen, both in
> Isis
>> and
>>>> > NakedObject.NET,
>>>> > > have centered on single-object view web layouts. Was it
>> discovered that
>>>> > the
>>>> > > desktop metaphor viewers were lacking for some users?
>>>> >
>>>> >
>>>> > The next generation of the Irish government project is indeed
>
>> moving to
>>>> > Naked Objects MVC. It's too early to say how that will
> pan
>> out.
>>>> >
>>>> > However, the issue with the DnD viewer is mostly its
> architecture:
>> the
>>>> > client/server remoting protocol, and having to maintain
>> client-side cache
>>>> > of objects and managing transient/persistent objects and lazy
>
>> loading
>>>> over
>>>> > the wire. The Irish app which runs under this architecture
> does
>> work,
>>>> but
>>>> > the sordid little secret is that there are a number of hacks
> under
>> the
>>>> > covers to get it to do so.
>>>> >
>>>> > But this is why the Restful interface (per the json-viewer)
> is so
>>>> > important, I think: it will enable different types of viewers
> with
>>>> whatever
>>>> > UI paradigm fits, but on a solid, scalable, back-end
> architecture
>> .
>>>> >
>>>> > So... I would say, go for it and build a DnD (or whatever)
> viewer,
>> using
>>>> > the restful API. There's no reason not to.
>>>> >
>>>> >
>>>> >
>>>> > > The new web viewers
>>>> > > are great but they don't give me the same sense of
>> exploration as the
>>>> > > original GUI. Maybe that exploration isn't needed
> after
>> the model
>>>> > > solidifies and the app is being used.
>>>> > >
>>>> > > Anyway, sorry for rambling.
>>>> >
>>>> >
>>>> > Not at all... very interested to hear your thoughts.
>>>> >
>>>> >
>>>> >
>>>> > > I tried something new and posted my little app
>>>> > > on Heroku. If I understand the service right you can
> access
>> the JSON
>>>> > viewer
>>>> > > [2], the HTML viewer [3] and my "windowed"
> viewer
>> [4] at the urls
>>>> below.
>>>> > It
>>>> > > might take a few seconds to spool up. Credentials are
>> sven/pass. Tested
>>>> > in
>>>> > > Chrome, FF, and Safari.
>>>> > >
>>>> >
>>>> > Heroku: that's on my todo list to look into. I might
> pick
>> your brains.
>>>> >
>>>> >
>>>> >
>>>> > >
>>>> > > Again it's nowhere near complete but you can execute
>
>> actions, view
>>>> > objects
>>>> > > and collections, create objects and modify properties
>> (mostly.)
>>>> > >
>>>> > > Thanks for creating a wonderful framework to build on.
>>>> > >
>>>> >
>>>> > Thanks for the kind words, looking forward to continuing the
>>>> conversation!
>>>> >
>>>> > Cheers
>>>> > Dan
>>>> >
>>>> >
>>>> >
>>>> > > --
>>>> > > Adam Howard
>>>> > >
>>>> > > [1]
>>>> > >
>>>> > >
>>>> >
>>>>
>>
> http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
>>>> > > [2] http://simple-dusk-6870.herokuapp.com
>>>> > > [3] http://simple-dusk-6870.herokuapp.com/htmlviewer
>>>> > > [4] http://simple-dusk-6870.herokuapp.com/services.html
>>>> >
>>>> >
>>>> > [5] http://code.google.com/p/restfulobjects-js/
>>>> >
>>>>
>>
>
Re: Introduction and another viewer
Posted by Mark Struberg <st...@yahoo.de>.
Hi Adam!
Really good questions and sorry that you tapped into the legal mine field that early. I hope this doesn't distract you too much from your intended hacking ;)
Just to explain the rational behind this a bit further:
_every_ OSS developer must be really carefully when it comes to legal aspects nowadays (Goog vs Orcl anyone?)
This is not folks at ASF being weirdos but we only like to protect our contributors (thus you and others) by making them aware. That's one of the reasons for our VOTEs on releases, ip-clearance [1] etc. We even maintain an own legal-discuss list where a few pro-bono lawyers, attorneys and even law professors also show up and help us resolving more difficult legal questions (big thanks btw!).
For the basics: an algorithm cannot be patented and also not being 'protected' via Intellectual Property rights (IP). But copying a bigger source 1:1 is problematic as it can lead to breaching IP.
Thus taking the idea of this single loop of 4 lines and rewriting them in your own code is absolutely no problem. Simple copying code is never a good idea though - be it for only changing code style or reviewing the code that way.
*skipping the technical ISIS questions, Dan please take over ;) *
> 1. Is this the correct forum to discuss these issues? I will definitely be using
> Isis to generate my Restful Objects with the json-viewer but I don't want to
> hijack the mailing list for these kinds of things unless it can benefit the Isis
> community.
It's perfectly fine to discuss it here on the list and even develop the viewer here. If this can be done in a 'portable', way we should take care to keep that part abstract and independent. But it's always a good idea to have at least a known server part it interacts well with. If it proved stable and universal, we can still split it out into an own project later on. Once one becomes an ASF committer on one project it's really easy to 'extend' into other project communities as well ;)
> 2. Hypothetically, I spend more time on my project and it turns out great and
> everyone wants to use it :P. Would, or should, it live at Apache? I would
> definitely be willing to donate it. But how would it be packaged? It's own
> viewer? That doesn't make sense because it needs the json-viewer to operate.
> A Maven war overlay of the json-viewer or webpp artifacts? Maybe. What if the
> .NET guys want it? I'm completely unfamiliar with NuGet and how it manages
> packages but I'm guessing it doesn't interoperate with Maven.
No clue about that right now. We would need to take a deep look at the details. But I'm sure we can solve this!
> I develop the code on GitHub under MIT license.
> Johan doesn't respond and his code is abandoned.
> I like his work so I merge our codebases giving him
> attribution. The code is now "IP unclean.
There is a very good summary and a license compat matrix here:
http://www.apache.org/legal/3party.html
MIT is perfectly fine to include in our work. Of course keep the author attribution.
I'm not sure how big the parts are you like to 'copy' from him 1:1 or if you/we more or less create own 'derivative' work by taking his code as base for _some_ features but changing/adopting/extending it ourselfs. This is really often the case if you take code from someone else.
We also might try to reach out as PMC, telling him what we like to do and if he is cool with that.
The worst thing which could happen is imo that we need to rewrite those parts we didn't yet touch.
LieGrue,
strub
[1] http://incubator.apache.org/ip-clearance/index.html
whoooops, I think we are still missing here ^^
----- Original Message -----
> From: Adam Howard <ho...@gmail.com>
> To: isis-users@incubator.apache.org
> Cc:
> Sent: Saturday, June 16, 2012 5:06 AM
> Subject: Re: Introduction and another viewer
>
> I'm including responses to both Mark and Dan here. I don't know if that
> meets
> list etiquette. Also should I be including full message history in every reply?
>
>
> On Fri, Jun 15, 2012 at 12:16 PM, Mark Struberg <st...@yahoo.de> wrote:
>>
>> The point is that here at ASF we only take code if someone explicitly
>> gives it to us.
>> Of course not if those are only a few lines of code or a pretty straight
>> forward basic task without much own work. But it's more complex and
>> originary work then we just don't take it.
>
> So for example, I wanted a unique id for every window and field in my ui. I
> googled for javascript guid and found a 4 line function that generates
> something "kind of like" a guid. Definitely random enough for my use.
> Is that a
> case where I would need to track down the author and ask if they will donate the
> code to ASF. I can think of many levels of scenarios. Is there a document
> outlining this? I don't want to "poison" my project this early :)
>
>
> On Fri, Jun 15, 2012 at 8:59 AM, Dan Haywood
> <da...@haywood-associates.co.uk>
> wrote:
>
>>> One of those features, though, you mentioned as a possible negative of
> the
>>> DnD viewer was maintaining a client-side cache of objects...
>>
>> Indeed. Those caches can get out of date; at least: they do on the Irish
>> system.
>>
>> The main workaround there is that, when the user searches for a Customer,
>> then the client invalidates the client-side cache. It works well enough
>> because the Customer is the usual start point for most business processing.
>> But it's not generic solution, ie is a hack.
>
> The cache that Johan is using seems a little different. When a domain object is
> returned from Isis, the graph is walked and more requests are made for
> properties, collections and descriptions. These all feed into a local
> representation of the state of the object. The window then displays the object
> as it exists in the cache. On subsequent requests for the object, it is ALWAYS
> refreshed from the server including all of its relations. So the cache is really
> just used to ensure that all current views are in sync with each other. So you
> change the name of a project and it's title is updated in the project list
> view
> because they are both pointing at the same javascript object.
>
>> Also (and this is even more of a dirty secret), the validation methods
>> (hidden, disabled, validate) run client-side. Strictly speaking, they
>> should run server-side which would force the latest version of the object
>> to be grabbed.
>
> You mention the object's version. Is there an optimistic locking property
> exposed in RO? I searched the 1.0.0 spec and couldn't find one.
>
>> This second point isn't an issue with an RO-based client, because
>> validation must trigger a call to the REST API... there is no Java code
>> client-side. Of course, with REST we can using HTTP caching to stop the
>> server being flooded with calls.
>
> The object traversal definitely floods the server. What would the cache-control
> be on an entity? Surely if we're asking we would want the latest version?
> Related to the optimistic locking property above would we say "I want
> object
> OID:10. I currently have v123" and the server could determine that v123 was
> the
> latest and send us a 304 (or do we keep track of when we requested the object
> and send that as If-modified-since?) Would it be different for value objects?
> And descriptions?
>
>>> The next step I suppose would be to tie in either the WebSockets or
>>> EventSource API...
>>
>> Not necessarily... it's hard to say. I guess we're all going to
> learn
>> where websockets (and related technologies) work well and where they
> don't
>> as HTML5 becomes commonplace.
>>
>> I do think it's worth taking this work forward and seeing what happens.
>> But ultimately it will require server-side changes to fully support... It
>> might end up being quite simple to implement, hard to say.
>>
>> It also occurs to me that a full WebSockets impl would mean that the UI
>> would change dynamically in front of a "user's eyes".
> Although that sounds
>> cool, I could also see that it might be disconcerting in some scenarios.
>> (You wouldn't want that to happen to a Java source file you were
> editing,
>> for example).
>
> There would be server-side changes and I don't know enough about how a
> property
> gets changed on an object to guess at the implementation. The two use cases I
> can see for this are streaming data and update announcements. Streaming data
> could be like a stock ticker or a continually updating chart. I've played
> with
> that before. The update announcements would broadcast that an object has changed
> server-side. It could include the full object or just the object id. The viewer
> could then choose to update the object in place or set a stale flag.
>
> It could be strange to see my Project view change in front of me (especially
> while I'm editing!) but there are cases where this could be very useful:
>
> * Shipping: Live map of where your package is.
> * The energy trading example from the first Naked Objects book.
> * Collaborative drawing: Not really a business system but often used to describe
> how rich we should strive to make our interfaces
>
> In the end, WebSockets is just a more server-friendly way to do what we have
> been doing with polling.
>
> =========
> Disclaimer: I love Apache. I wouldn't be able to do my job without it. All
> of the questions below are purely hypothetical and for clarification purposes.
>
> One question came up while writing all this and thinking about what Mark said.
> What we are really talking about here is a Restful Objects viewer and not an
> Isis viewer. At least not in the same sense as the HTML, Scimpi, or Wicket
> viewers. That being the case, the jqMobile interface, Johan's project, my
> project, etc. are not Isis-specific (unless they use something in extensions.)
> Two questions:
>
> 1. Is this the correct forum to discuss these issues? I will definitely be using
> Isis to generate my Restful Objects with the json-viewer but I don't want to
> hijack the mailing list for these kinds of things unless it can benefit the Isis
> community.
>
> 2. Hypothetically, I spend more time on my project and it turns out great and
> everyone wants to use it :P. Would, or should, it live at Apache? I would
> definitely be willing to donate it. But how would it be packaged? It's own
> viewer? That doesn't make sense because it needs the json-viewer to operate.
> A Maven war overlay of the json-viewer or webpp artifacts? Maybe. What if the
> .NET guys want it? I'm completely unfamiliar with NuGet and how it manages
> packages but I'm guessing it doesn't interoperate with Maven.
>
> One scenario…
> I develop the code on GitHub under MIT license. Johan doesn't respond and
> his
> code is abandoned. I like his work so I merge our codebases giving him
> attribution. The code is now "IP unclean." If I can get it published
> to maven
> central I can create a maven war overlay of the Isis json-viewer. Isis users
> can include this in their root project but it can't be a part of the
> quickstart
> archetype because of the IP issue. (Is that similar to the fate of the Hibernate
> backend?) The project is RestfulObjects focused so it could also be shared with
> the .NET community. I realize I am getting way ahead of myself but like I said
> at the beginning of this email, I don't want to "poison" the
> project early.
>
> I worry alot about the tone of these messages. I can see how the above might
> sound combative.
>
> "The computer can't tell you the emotional story.
> It can give you the exact mathematical design,
> but what's missing is the eyebrows."
> -- Frank Zappa
>
>
> Very much enjoying the discussion.
> --
> Adam Howard
>
>
> On Fri, Jun 15, 2012 at 8:59 AM, Dan Haywood
> <da...@haywood-associates.co.uk> wrote:
>> On 15 June 2012 04:06, Adam Howard <ho...@gmail.com> wrote:
>>
>> I tried it out [Johan's client] ...
>>> He already has many of the features I wanted to add to my little
> project.
>>> ...
>>>
>>> One of those features, though, you mentioned as a possible negative of
> the
>>> DnD viewer was maintaining a client-side cache of objects. Johan uses
> this
>>> so that the views can be direct projections of the local model. You
> change
>>> a field in one view and all others views automatically update.
>>
>>
>> Indeed. Those caches can get out of date; at least: they do on the Irish
>> system.
>>
>> The main workaround there is that, when the user searches for a Customer,
>> then the client invalidates the client-side cache. It works well enough
>> because the Customer is the usual start point for most business processing.
>> But it's not generic solution, ie is a hack.
>>
>> Also (and this is even more of a dirty secret), the validation methods
>> (hidden, disabled, validate) run client-side. Strictly speaking, they
>> should run server-side which would force the latest version of the object
>> to be grabbed.
>>
>> This second point isn't an issue with an RO-based client, because
>> validation must trigger a call to the REST API... there is no Java code
>> client-side. Of course, with REST we can using HTTP caching to stop the
>> server being flooded with calls.
>>
>>
>>
>>
>>> The next
>>> step I suppose would be to tie in either the WebSockets or EventSource
> API
>>> to allow the server to broadcast object change events back to all
> connected
>>> viewers. Would you advise against this sort of approach?
>>
>>
>> Not necessarily... it's hard to say. I guess we're all going to
> learn
>> where websockets (and related technologies) work well and where they
> don't
>> as HTML5 becomes commonplace.
>>
>> I do think it's worth taking this work forward and seeing what happens.
>> But ultimately it will require server-side changes to fully support... It
>> might end up being quite simple to implement, hard to say.
>>
>> It also occurs to me that a full WebSockets impl would mean that the UI
>> would change dynamically in front of a "user's eyes".
> Although that sounds
>> cool, I could also see that it might be disconcerting in some scenarios.
>> (You wouldn't want that to happen to a Java source file you were
> editing,
>> for example).
>>
>>
>>
>>
>>> Or is the
>>> client-side cache you mention more an artifact of the remoting
> protocol?
>>>
>>
>> The bespoke remoting that we had (and have now thrown away) certainly
>> didn't help matters. But it was also complicated by the fact that OIDs
>> (the serializable object identifier by which we identify every object, eg
>> "customer|123") used to be mutable. This was because an object
> would be
>> transient client-side, then get persisted (ie: users hits the
> "save"
>> button), then the object would be sent over the wire, persisted, and its
>> OID would change. Figuring all this stuff out was complex.
>>
>> OIDs are now immutable, which basically means that we don't really
> support
>> transient objects anymore. I can think of patterns that would allow us to
>> simulate this, though.
>>
>>
>>
>>
>>>
>>> On Heroku, I just signed up for the account to post this demo. It
> seemed
>>> like the easiest and cheapest (free) way to post a simple java webapp.
>>> Especially since I didn't require an RDBMS. My 24 hours of
> experience have
>>> been fine.
>>>
>>
>> OK, looking into it. I'm also looking at CloudBees and OpenShift, cos
> I
>> want a (non-Apache) CI server for this new project that is kicking off.
>>
>>
>>
>>
>>>
>>> On the iPad, I thought this would be cool too and then started to think
>>> about how dragging and right-clicking doesn't work. Then I found
> jQuery UI
>>> Touch Punch [1] which maps the jQuery UI events to touch events: click
>>> becomes tap, right-click becomes tap & hold, and they've made
> dragging and
>>> dropping work as well. I'll definitely have to try it out.
>>>
>>
>> It's great how many of these UI frameworks are. Hopefully the REST API
>> will allow for all sorts of interesting user interfaces going forward.
>>
>> Cheers
>> Dan
>>
>>
>>
>>>
>>> --
>>> Adam Howard
>>>
>>> [1] http://touchpunch.furf.com/
>>>
>>> On Thu, Jun 14, 2012 at 10:12 AM, Dan Haywood
>>> <da...@haywood-associates.co.uk>wrote:
>>>
>>> > Hi Adam,
>>> > Welcome to Isis, and thanks very much for your interest and the
> good work
>>> > you've already done so far!
>>> >
>>> > Since you've made a number of points, I've commented on
> them inline....
>>> >
>>> >
>>> > On Thursday, 14 June 2012, Adam Howard wrote:
>>> >
>>> > >
>>> > > I started reading Dan's book last fall and made it part
> way through the
>>> > > carserv example app using Isis 0.1.2-incubating. I used the
> DnD viewer
>>> > > almost exclusively, enjoying how tangible the objects became
> using the
>>> > > multi-window interface.
>>> > >
>>> >
>>> >
>>> >
>>> > >
>>> > > About a month ago I came back to the book and decided to
> start writing
>>> my
>>> > > own little app alongside carserv. I grabbed the latest Isis
> quickstart
>>> > > archetype (0.2.0-incubating) and started coding.
> Surprisingly, I saw
>>> that
>>> > > the DnD viewer was no longer included as standard in the
> archetype. I
>>> > used
>>> > > the HTML viewer for about a week but it just didn't feel
> the same. With
>>> > the
>>> > > DnD viewer I could look at my object representations and it
> would help
>>> > > drive my modeling. "Oh, I need a relationship here so I
> can drop this
>>> > > object on that one."
>>> > >
>>> >
>>> > Like you, I also have a soft spot for the DnD viewer, and Rob does
> too of
>>> > course because it's his baby. It's also the viewer
> that's used on the
>>> big
>>> > system in Ireland, used by 2,500+ people on a day-to-day basis.
>>> >
>>> > On the other hand, the DnD viewer, let's say, not the
> prettiest of UIs.
>>> > (For myself at least) I'm pretty sure lots of people have
> seen it and
>>> got
>>> > turned off by Isis / the naked objects pattern....
>>> >
>>> > As you've probably realized, the DnD viewer code itself has
> not been
>>> > deleted. However, we removed it from the archetype because:
>>> > * we wanted to try to include only the stuff that was
> "complete", and in
>>> > its current incarnation a few new features are only
> semi-implemented
>>> > * its status was becoming less clear with the move to remove the
> remoting
>>> > stuff
>>> > * to figure out what it's positioning should be within the
> context of the
>>> > other viewers.
>>> >
>>> > Where I think we are now is that we see the DnD viewer as being
>>> > resurrected, but positioned solely as a design tool for
> developers.
>>> >
>>> > At some point Rob needs to do some tidy up work to remove the
>>> > semi-implemented features and get it back to where it was
> (ideally: I'd
>>> > like it to look like NOF 3.0.3, with the collections on the left).
> As
>>> and
>>> > when that's done, I'll add it back into the archetype.
>>> >
>>> > In the meantime, you can of course create a Maven module and
> reference
>>> the
>>> > viewer; the module generated from the 0.1.2-incubating archetype
> will
>>> > probably work just fine (save change the version of Isis
> referenced,
>>> > obviously).
>>> >
>>> >
>>> >
>>> >
>>> > >
>>> > > This got me wondering. Could a browser-based multi-window
> interface be
>>> > > built on top of the JSON viewer and a javascript ui library?
> I looked
>>> at
>>> > > all the contenders (YUI, jQuery, MooTools, Backbone, ExtJS)
> and finally
>>> > > settled on jQuery after seeing this blog post [1] and looking
> at the
>>> > > jqMobile example.
>>> > >
>>> >
>>> > Indeed. And in fact a chap called Johan Andries had the same idea
> and
>>> > spent some time putting together an early JS application against
> the
>>> > Restful interface using JQueryUI and Backbone. He's also
> shared his
>>> code,
>>> > at [5].
>>> >
>>> >
>>> >
>>> >
>>> > >
>>> > > I've been playing with it for the past couple weeks and
> I'm at the
>>> point
>>> > > where I wanted to know if this is something the community is
> interested
>>> > in.
>>> > > I know it's ANOTHER viewer and I'm making no claims
> that it's ready (or
>>> > > will ever be ready) for anyone else to use. I'm really
> asking if the
>>> > ideas
>>> > > embodied in the DnD viewer are still desired?
>>> >
>>> >
>>> > Yes, I think they are. In fact, Johan's viewer also uses the
> DnD as its
>>> > metaphor. I had a quick play with your app [4] (though not for
> long)
>>> and I
>>> > think that Johan has gotten a little further with his framework
> than you.
>>> > That said, he doesn't seem to have done any work on it since
> Nov last.
>>> >
>>> > So, one option you might want to explore is to contact Johan and
> either
>>> > join his project, or fork it and take it from there.
>>> >
>>> > For myself, I was thinking that a GUI based on ExtJS might do well
> as a
>>> > sovereign style app... but I can't see myself starting on that
> this year
>>> > (2012).
>>> >
>>> >
>>> >
>>> > > The most important to me
>>> > > being multiple objects on a virtual desktop that you can
> visually
>>> layout
>>> > to
>>> > > increase understanding.
>>> > >
>>> >
>>> > Agreed. Also, with toolkits such as SenchaTouch, I think there
> are
>>> > opportunities for very interactive UIs that can be deployed on
> iPADs and
>>> > the like.
>>> >
>>> >
>>> >
>>> >
>>> > >
>>> > > All of the latest developments I've seen, both in Isis
> and
>>> > NakedObject.NET,
>>> > > have centered on single-object view web layouts. Was it
> discovered that
>>> > the
>>> > > desktop metaphor viewers were lacking for some users?
>>> >
>>> >
>>> > The next generation of the Irish government project is indeed
> moving to
>>> > Naked Objects MVC. It's too early to say how that will pan
> out.
>>> >
>>> > However, the issue with the DnD viewer is mostly its architecture:
> the
>>> > client/server remoting protocol, and having to maintain
> client-side cache
>>> > of objects and managing transient/persistent objects and lazy
> loading
>>> over
>>> > the wire. The Irish app which runs under this architecture does
> work,
>>> but
>>> > the sordid little secret is that there are a number of hacks under
> the
>>> > covers to get it to do so.
>>> >
>>> > But this is why the Restful interface (per the json-viewer) is so
>>> > important, I think: it will enable different types of viewers with
>>> whatever
>>> > UI paradigm fits, but on a solid, scalable, back-end architecture
> .
>>> >
>>> > So... I would say, go for it and build a DnD (or whatever) viewer,
> using
>>> > the restful API. There's no reason not to.
>>> >
>>> >
>>> >
>>> > > The new web viewers
>>> > > are great but they don't give me the same sense of
> exploration as the
>>> > > original GUI. Maybe that exploration isn't needed after
> the model
>>> > > solidifies and the app is being used.
>>> > >
>>> > > Anyway, sorry for rambling.
>>> >
>>> >
>>> > Not at all... very interested to hear your thoughts.
>>> >
>>> >
>>> >
>>> > > I tried something new and posted my little app
>>> > > on Heroku. If I understand the service right you can access
> the JSON
>>> > viewer
>>> > > [2], the HTML viewer [3] and my "windowed" viewer
> [4] at the urls
>>> below.
>>> > It
>>> > > might take a few seconds to spool up. Credentials are
> sven/pass. Tested
>>> > in
>>> > > Chrome, FF, and Safari.
>>> > >
>>> >
>>> > Heroku: that's on my todo list to look into. I might pick
> your brains.
>>> >
>>> >
>>> >
>>> > >
>>> > > Again it's nowhere near complete but you can execute
> actions, view
>>> > objects
>>> > > and collections, create objects and modify properties
> (mostly.)
>>> > >
>>> > > Thanks for creating a wonderful framework to build on.
>>> > >
>>> >
>>> > Thanks for the kind words, looking forward to continuing the
>>> conversation!
>>> >
>>> > Cheers
>>> > Dan
>>> >
>>> >
>>> >
>>> > > --
>>> > > Adam Howard
>>> > >
>>> > > [1]
>>> > >
>>> > >
>>> >
>>>
> http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
>>> > > [2] http://simple-dusk-6870.herokuapp.com
>>> > > [3] http://simple-dusk-6870.herokuapp.com/htmlviewer
>>> > > [4] http://simple-dusk-6870.herokuapp.com/services.html
>>> >
>>> >
>>> > [5] http://code.google.com/p/restfulobjects-js/
>>> >
>>>
>
Re: Introduction and another viewer
Posted by Adam Howard <ho...@gmail.com>.
I'm including responses to both Mark and Dan here. I don't know if that meets
list etiquette. Also should I be including full message history in every reply?
On Fri, Jun 15, 2012 at 12:16 PM, Mark Struberg <st...@yahoo.de> wrote:
>
> The point is that here at ASF we only take code if someone explicitly
> gives it to us.
> Of course not if those are only a few lines of code or a pretty straight
> forward basic task without much own work. But it's more complex and
> originary work then we just don't take it.
So for example, I wanted a unique id for every window and field in my ui. I
googled for javascript guid and found a 4 line function that generates
something "kind of like" a guid. Definitely random enough for my use. Is that a
case where I would need to track down the author and ask if they will donate the
code to ASF. I can think of many levels of scenarios. Is there a document
outlining this? I don't want to "poison" my project this early :)
On Fri, Jun 15, 2012 at 8:59 AM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
>> One of those features, though, you mentioned as a possible negative of the
>> DnD viewer was maintaining a client-side cache of objects...
>
> Indeed. Those caches can get out of date; at least: they do on the Irish
> system.
>
> The main workaround there is that, when the user searches for a Customer,
> then the client invalidates the client-side cache. It works well enough
> because the Customer is the usual start point for most business processing.
> But it's not generic solution, ie is a hack.
The cache that Johan is using seems a little different. When a domain object is
returned from Isis, the graph is walked and more requests are made for
properties, collections and descriptions. These all feed into a local
representation of the state of the object. The window then displays the object
as it exists in the cache. On subsequent requests for the object, it is ALWAYS
refreshed from the server including all of its relations. So the cache is really
just used to ensure that all current views are in sync with each other. So you
change the name of a project and it's title is updated in the project list view
because they are both pointing at the same javascript object.
> Also (and this is even more of a dirty secret), the validation methods
> (hidden, disabled, validate) run client-side. Strictly speaking, they
> should run server-side which would force the latest version of the object
> to be grabbed.
You mention the object's version. Is there an optimistic locking property
exposed in RO? I searched the 1.0.0 spec and couldn't find one.
> This second point isn't an issue with an RO-based client, because
> validation must trigger a call to the REST API... there is no Java code
> client-side. Of course, with REST we can using HTTP caching to stop the
> server being flooded with calls.
The object traversal definitely floods the server. What would the cache-control
be on an entity? Surely if we're asking we would want the latest version?
Related to the optimistic locking property above would we say "I want object
OID:10. I currently have v123" and the server could determine that v123 was the
latest and send us a 304 (or do we keep track of when we requested the object
and send that as If-modified-since?) Would it be different for value objects?
And descriptions?
>> The next step I suppose would be to tie in either the WebSockets or
>> EventSource API...
>
> Not necessarily... it's hard to say. I guess we're all going to learn
> where websockets (and related technologies) work well and where they don't
> as HTML5 becomes commonplace.
>
> I do think it's worth taking this work forward and seeing what happens.
> But ultimately it will require server-side changes to fully support... It
> might end up being quite simple to implement, hard to say.
>
> It also occurs to me that a full WebSockets impl would mean that the UI
> would change dynamically in front of a "user's eyes". Although that sounds
> cool, I could also see that it might be disconcerting in some scenarios.
> (You wouldn't want that to happen to a Java source file you were editing,
> for example).
There would be server-side changes and I don't know enough about how a property
gets changed on an object to guess at the implementation. The two use cases I
can see for this are streaming data and update announcements. Streaming data
could be like a stock ticker or a continually updating chart. I've played with
that before. The update announcements would broadcast that an object has changed
server-side. It could include the full object or just the object id. The viewer
could then choose to update the object in place or set a stale flag.
It could be strange to see my Project view change in front of me (especially
while I'm editing!) but there are cases where this could be very useful:
* Shipping: Live map of where your package is.
* The energy trading example from the first Naked Objects book.
* Collaborative drawing: Not really a business system but often used to describe
how rich we should strive to make our interfaces
In the end, WebSockets is just a more server-friendly way to do what we have
been doing with polling.
=========
Disclaimer: I love Apache. I wouldn't be able to do my job without it. All
of the questions below are purely hypothetical and for clarification purposes.
One question came up while writing all this and thinking about what Mark said.
What we are really talking about here is a Restful Objects viewer and not an
Isis viewer. At least not in the same sense as the HTML, Scimpi, or Wicket
viewers. That being the case, the jqMobile interface, Johan's project, my
project, etc. are not Isis-specific (unless they use something in extensions.)
Two questions:
1. Is this the correct forum to discuss these issues? I will definitely be using
Isis to generate my Restful Objects with the json-viewer but I don't want to
hijack the mailing list for these kinds of things unless it can benefit the Isis
community.
2. Hypothetically, I spend more time on my project and it turns out great and
everyone wants to use it :P. Would, or should, it live at Apache? I would
definitely be willing to donate it. But how would it be packaged? It's own
viewer? That doesn't make sense because it needs the json-viewer to operate.
A Maven war overlay of the json-viewer or webpp artifacts? Maybe. What if the
.NET guys want it? I'm completely unfamiliar with NuGet and how it manages
packages but I'm guessing it doesn't interoperate with Maven.
One scenario…
I develop the code on GitHub under MIT license. Johan doesn't respond and his
code is abandoned. I like his work so I merge our codebases giving him
attribution. The code is now "IP unclean." If I can get it published to maven
central I can create a maven war overlay of the Isis json-viewer. Isis users
can include this in their root project but it can't be a part of the quickstart
archetype because of the IP issue. (Is that similar to the fate of the Hibernate
backend?) The project is RestfulObjects focused so it could also be shared with
the .NET community. I realize I am getting way ahead of myself but like I said
at the beginning of this email, I don't want to "poison" the project early.
I worry alot about the tone of these messages. I can see how the above might
sound combative.
"The computer can't tell you the emotional story.
It can give you the exact mathematical design,
but what's missing is the eyebrows."
-- Frank Zappa
Very much enjoying the discussion.
--
Adam Howard
On Fri, Jun 15, 2012 at 8:59 AM, Dan Haywood
<da...@haywood-associates.co.uk> wrote:
> On 15 June 2012 04:06, Adam Howard <ho...@gmail.com> wrote:
>
> I tried it out [Johan's client] ...
>> He already has many of the features I wanted to add to my little project.
>> ...
>>
>> One of those features, though, you mentioned as a possible negative of the
>> DnD viewer was maintaining a client-side cache of objects. Johan uses this
>> so that the views can be direct projections of the local model. You change
>> a field in one view and all others views automatically update.
>
>
> Indeed. Those caches can get out of date; at least: they do on the Irish
> system.
>
> The main workaround there is that, when the user searches for a Customer,
> then the client invalidates the client-side cache. It works well enough
> because the Customer is the usual start point for most business processing.
> But it's not generic solution, ie is a hack.
>
> Also (and this is even more of a dirty secret), the validation methods
> (hidden, disabled, validate) run client-side. Strictly speaking, they
> should run server-side which would force the latest version of the object
> to be grabbed.
>
> This second point isn't an issue with an RO-based client, because
> validation must trigger a call to the REST API... there is no Java code
> client-side. Of course, with REST we can using HTTP caching to stop the
> server being flooded with calls.
>
>
>
>
>> The next
>> step I suppose would be to tie in either the WebSockets or EventSource API
>> to allow the server to broadcast object change events back to all connected
>> viewers. Would you advise against this sort of approach?
>
>
> Not necessarily... it's hard to say. I guess we're all going to learn
> where websockets (and related technologies) work well and where they don't
> as HTML5 becomes commonplace.
>
> I do think it's worth taking this work forward and seeing what happens.
> But ultimately it will require server-side changes to fully support... It
> might end up being quite simple to implement, hard to say.
>
> It also occurs to me that a full WebSockets impl would mean that the UI
> would change dynamically in front of a "user's eyes". Although that sounds
> cool, I could also see that it might be disconcerting in some scenarios.
> (You wouldn't want that to happen to a Java source file you were editing,
> for example).
>
>
>
>
>> Or is the
>> client-side cache you mention more an artifact of the remoting protocol?
>>
>
> The bespoke remoting that we had (and have now thrown away) certainly
> didn't help matters. But it was also complicated by the fact that OIDs
> (the serializable object identifier by which we identify every object, eg
> "customer|123") used to be mutable. This was because an object would be
> transient client-side, then get persisted (ie: users hits the "save"
> button), then the object would be sent over the wire, persisted, and its
> OID would change. Figuring all this stuff out was complex.
>
> OIDs are now immutable, which basically means that we don't really support
> transient objects anymore. I can think of patterns that would allow us to
> simulate this, though.
>
>
>
>
>>
>> On Heroku, I just signed up for the account to post this demo. It seemed
>> like the easiest and cheapest (free) way to post a simple java webapp.
>> Especially since I didn't require an RDBMS. My 24 hours of experience have
>> been fine.
>>
>
> OK, looking into it. I'm also looking at CloudBees and OpenShift, cos I
> want a (non-Apache) CI server for this new project that is kicking off.
>
>
>
>
>>
>> On the iPad, I thought this would be cool too and then started to think
>> about how dragging and right-clicking doesn't work. Then I found jQuery UI
>> Touch Punch [1] which maps the jQuery UI events to touch events: click
>> becomes tap, right-click becomes tap & hold, and they've made dragging and
>> dropping work as well. I'll definitely have to try it out.
>>
>
> It's great how many of these UI frameworks are. Hopefully the REST API
> will allow for all sorts of interesting user interfaces going forward.
>
> Cheers
> Dan
>
>
>
>>
>> --
>> Adam Howard
>>
>> [1] http://touchpunch.furf.com/
>>
>> On Thu, Jun 14, 2012 at 10:12 AM, Dan Haywood
>> <da...@haywood-associates.co.uk>wrote:
>>
>> > Hi Adam,
>> > Welcome to Isis, and thanks very much for your interest and the good work
>> > you've already done so far!
>> >
>> > Since you've made a number of points, I've commented on them inline....
>> >
>> >
>> > On Thursday, 14 June 2012, Adam Howard wrote:
>> >
>> > >
>> > > I started reading Dan's book last fall and made it part way through the
>> > > carserv example app using Isis 0.1.2-incubating. I used the DnD viewer
>> > > almost exclusively, enjoying how tangible the objects became using the
>> > > multi-window interface.
>> > >
>> >
>> >
>> >
>> > >
>> > > About a month ago I came back to the book and decided to start writing
>> my
>> > > own little app alongside carserv. I grabbed the latest Isis quickstart
>> > > archetype (0.2.0-incubating) and started coding. Surprisingly, I saw
>> that
>> > > the DnD viewer was no longer included as standard in the archetype. I
>> > used
>> > > the HTML viewer for about a week but it just didn't feel the same. With
>> > the
>> > > DnD viewer I could look at my object representations and it would help
>> > > drive my modeling. "Oh, I need a relationship here so I can drop this
>> > > object on that one."
>> > >
>> >
>> > Like you, I also have a soft spot for the DnD viewer, and Rob does too of
>> > course because it's his baby. It's also the viewer that's used on the
>> big
>> > system in Ireland, used by 2,500+ people on a day-to-day basis.
>> >
>> > On the other hand, the DnD viewer, let's say, not the prettiest of UIs.
>> > (For myself at least) I'm pretty sure lots of people have seen it and
>> got
>> > turned off by Isis / the naked objects pattern....
>> >
>> > As you've probably realized, the DnD viewer code itself has not been
>> > deleted. However, we removed it from the archetype because:
>> > * we wanted to try to include only the stuff that was "complete", and in
>> > its current incarnation a few new features are only semi-implemented
>> > * its status was becoming less clear with the move to remove the remoting
>> > stuff
>> > * to figure out what it's positioning should be within the context of the
>> > other viewers.
>> >
>> > Where I think we are now is that we see the DnD viewer as being
>> > resurrected, but positioned solely as a design tool for developers.
>> >
>> > At some point Rob needs to do some tidy up work to remove the
>> > semi-implemented features and get it back to where it was (ideally: I'd
>> > like it to look like NOF 3.0.3, with the collections on the left). As
>> and
>> > when that's done, I'll add it back into the archetype.
>> >
>> > In the meantime, you can of course create a Maven module and reference
>> the
>> > viewer; the module generated from the 0.1.2-incubating archetype will
>> > probably work just fine (save change the version of Isis referenced,
>> > obviously).
>> >
>> >
>> >
>> >
>> > >
>> > > This got me wondering. Could a browser-based multi-window interface be
>> > > built on top of the JSON viewer and a javascript ui library? I looked
>> at
>> > > all the contenders (YUI, jQuery, MooTools, Backbone, ExtJS) and finally
>> > > settled on jQuery after seeing this blog post [1] and looking at the
>> > > jqMobile example.
>> > >
>> >
>> > Indeed. And in fact a chap called Johan Andries had the same idea and
>> > spent some time putting together an early JS application against the
>> > Restful interface using JQueryUI and Backbone. He's also shared his
>> code,
>> > at [5].
>> >
>> >
>> >
>> >
>> > >
>> > > I've been playing with it for the past couple weeks and I'm at the
>> point
>> > > where I wanted to know if this is something the community is interested
>> > in.
>> > > I know it's ANOTHER viewer and I'm making no claims that it's ready (or
>> > > will ever be ready) for anyone else to use. I'm really asking if the
>> > ideas
>> > > embodied in the DnD viewer are still desired?
>> >
>> >
>> > Yes, I think they are. In fact, Johan's viewer also uses the DnD as its
>> > metaphor. I had a quick play with your app [4] (though not for long)
>> and I
>> > think that Johan has gotten a little further with his framework than you.
>> > That said, he doesn't seem to have done any work on it since Nov last.
>> >
>> > So, one option you might want to explore is to contact Johan and either
>> > join his project, or fork it and take it from there.
>> >
>> > For myself, I was thinking that a GUI based on ExtJS might do well as a
>> > sovereign style app... but I can't see myself starting on that this year
>> > (2012).
>> >
>> >
>> >
>> > > The most important to me
>> > > being multiple objects on a virtual desktop that you can visually
>> layout
>> > to
>> > > increase understanding.
>> > >
>> >
>> > Agreed. Also, with toolkits such as SenchaTouch, I think there are
>> > opportunities for very interactive UIs that can be deployed on iPADs and
>> > the like.
>> >
>> >
>> >
>> >
>> > >
>> > > All of the latest developments I've seen, both in Isis and
>> > NakedObject.NET,
>> > > have centered on single-object view web layouts. Was it discovered that
>> > the
>> > > desktop metaphor viewers were lacking for some users?
>> >
>> >
>> > The next generation of the Irish government project is indeed moving to
>> > Naked Objects MVC. It's too early to say how that will pan out.
>> >
>> > However, the issue with the DnD viewer is mostly its architecture: the
>> > client/server remoting protocol, and having to maintain client-side cache
>> > of objects and managing transient/persistent objects and lazy loading
>> over
>> > the wire. The Irish app which runs under this architecture does work,
>> but
>> > the sordid little secret is that there are a number of hacks under the
>> > covers to get it to do so.
>> >
>> > But this is why the Restful interface (per the json-viewer) is so
>> > important, I think: it will enable different types of viewers with
>> whatever
>> > UI paradigm fits, but on a solid, scalable, back-end architecture .
>> >
>> > So... I would say, go for it and build a DnD (or whatever) viewer, using
>> > the restful API. There's no reason not to.
>> >
>> >
>> >
>> > > The new web viewers
>> > > are great but they don't give me the same sense of exploration as the
>> > > original GUI. Maybe that exploration isn't needed after the model
>> > > solidifies and the app is being used.
>> > >
>> > > Anyway, sorry for rambling.
>> >
>> >
>> > Not at all... very interested to hear your thoughts.
>> >
>> >
>> >
>> > > I tried something new and posted my little app
>> > > on Heroku. If I understand the service right you can access the JSON
>> > viewer
>> > > [2], the HTML viewer [3] and my "windowed" viewer [4] at the urls
>> below.
>> > It
>> > > might take a few seconds to spool up. Credentials are sven/pass. Tested
>> > in
>> > > Chrome, FF, and Safari.
>> > >
>> >
>> > Heroku: that's on my todo list to look into. I might pick your brains.
>> >
>> >
>> >
>> > >
>> > > Again it's nowhere near complete but you can execute actions, view
>> > objects
>> > > and collections, create objects and modify properties (mostly.)
>> > >
>> > > Thanks for creating a wonderful framework to build on.
>> > >
>> >
>> > Thanks for the kind words, looking forward to continuing the
>> conversation!
>> >
>> > Cheers
>> > Dan
>> >
>> >
>> >
>> > > --
>> > > Adam Howard
>> > >
>> > > [1]
>> > >
>> > >
>> >
>> http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
>> > > [2] http://simple-dusk-6870.herokuapp.com
>> > > [3] http://simple-dusk-6870.herokuapp.com/htmlviewer
>> > > [4] http://simple-dusk-6870.herokuapp.com/services.html
>> >
>> >
>> > [5] http://code.google.com/p/restfulobjects-js/
>> >
>>
Re: Introduction and another viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 15 June 2012 04:06, Adam Howard <ho...@gmail.com> wrote:
I tried it out [Johan's client] ...
> He already has many of the features I wanted to add to my little project.
> ...
>
> One of those features, though, you mentioned as a possible negative of the
> DnD viewer was maintaining a client-side cache of objects. Johan uses this
> so that the views can be direct projections of the local model. You change
> a field in one view and all others views automatically update.
Indeed. Those caches can get out of date; at least: they do on the Irish
system.
The main workaround there is that, when the user searches for a Customer,
then the client invalidates the client-side cache. It works well enough
because the Customer is the usual start point for most business processing.
But it's not generic solution, ie is a hack.
Also (and this is even more of a dirty secret), the validation methods
(hidden, disabled, validate) run client-side. Strictly speaking, they
should run server-side which would force the latest version of the object
to be grabbed.
This second point isn't an issue with an RO-based client, because
validation must trigger a call to the REST API... there is no Java code
client-side. Of course, with REST we can using HTTP caching to stop the
server being flooded with calls.
> The next
> step I suppose would be to tie in either the WebSockets or EventSource API
> to allow the server to broadcast object change events back to all connected
> viewers. Would you advise against this sort of approach?
Not necessarily... it's hard to say. I guess we're all going to learn
where websockets (and related technologies) work well and where they don't
as HTML5 becomes commonplace.
I do think it's worth taking this work forward and seeing what happens.
But ultimately it will require server-side changes to fully support... It
might end up being quite simple to implement, hard to say.
It also occurs to me that a full WebSockets impl would mean that the UI
would change dynamically in front of a "user's eyes". Although that sounds
cool, I could also see that it might be disconcerting in some scenarios.
(You wouldn't want that to happen to a Java source file you were editing,
for example).
> Or is the
> client-side cache you mention more an artifact of the remoting protocol?
>
The bespoke remoting that we had (and have now thrown away) certainly
didn't help matters. But it was also complicated by the fact that OIDs
(the serializable object identifier by which we identify every object, eg
"customer|123") used to be mutable. This was because an object would be
transient client-side, then get persisted (ie: users hits the "save"
button), then the object would be sent over the wire, persisted, and its
OID would change. Figuring all this stuff out was complex.
OIDs are now immutable, which basically means that we don't really support
transient objects anymore. I can think of patterns that would allow us to
simulate this, though.
>
> On Heroku, I just signed up for the account to post this demo. It seemed
> like the easiest and cheapest (free) way to post a simple java webapp.
> Especially since I didn't require an RDBMS. My 24 hours of experience have
> been fine.
>
OK, looking into it. I'm also looking at CloudBees and OpenShift, cos I
want a (non-Apache) CI server for this new project that is kicking off.
>
> On the iPad, I thought this would be cool too and then started to think
> about how dragging and right-clicking doesn't work. Then I found jQuery UI
> Touch Punch [1] which maps the jQuery UI events to touch events: click
> becomes tap, right-click becomes tap & hold, and they've made dragging and
> dropping work as well. I'll definitely have to try it out.
>
It's great how many of these UI frameworks are. Hopefully the REST API
will allow for all sorts of interesting user interfaces going forward.
Cheers
Dan
>
> --
> Adam Howard
>
> [1] http://touchpunch.furf.com/
>
> On Thu, Jun 14, 2012 at 10:12 AM, Dan Haywood
> <da...@haywood-associates.co.uk>wrote:
>
> > Hi Adam,
> > Welcome to Isis, and thanks very much for your interest and the good work
> > you've already done so far!
> >
> > Since you've made a number of points, I've commented on them inline....
> >
> >
> > On Thursday, 14 June 2012, Adam Howard wrote:
> >
> > >
> > > I started reading Dan's book last fall and made it part way through the
> > > carserv example app using Isis 0.1.2-incubating. I used the DnD viewer
> > > almost exclusively, enjoying how tangible the objects became using the
> > > multi-window interface.
> > >
> >
> >
> >
> > >
> > > About a month ago I came back to the book and decided to start writing
> my
> > > own little app alongside carserv. I grabbed the latest Isis quickstart
> > > archetype (0.2.0-incubating) and started coding. Surprisingly, I saw
> that
> > > the DnD viewer was no longer included as standard in the archetype. I
> > used
> > > the HTML viewer for about a week but it just didn't feel the same. With
> > the
> > > DnD viewer I could look at my object representations and it would help
> > > drive my modeling. "Oh, I need a relationship here so I can drop this
> > > object on that one."
> > >
> >
> > Like you, I also have a soft spot for the DnD viewer, and Rob does too of
> > course because it's his baby. It's also the viewer that's used on the
> big
> > system in Ireland, used by 2,500+ people on a day-to-day basis.
> >
> > On the other hand, the DnD viewer, let's say, not the prettiest of UIs.
> > (For myself at least) I'm pretty sure lots of people have seen it and
> got
> > turned off by Isis / the naked objects pattern....
> >
> > As you've probably realized, the DnD viewer code itself has not been
> > deleted. However, we removed it from the archetype because:
> > * we wanted to try to include only the stuff that was "complete", and in
> > its current incarnation a few new features are only semi-implemented
> > * its status was becoming less clear with the move to remove the remoting
> > stuff
> > * to figure out what it's positioning should be within the context of the
> > other viewers.
> >
> > Where I think we are now is that we see the DnD viewer as being
> > resurrected, but positioned solely as a design tool for developers.
> >
> > At some point Rob needs to do some tidy up work to remove the
> > semi-implemented features and get it back to where it was (ideally: I'd
> > like it to look like NOF 3.0.3, with the collections on the left). As
> and
> > when that's done, I'll add it back into the archetype.
> >
> > In the meantime, you can of course create a Maven module and reference
> the
> > viewer; the module generated from the 0.1.2-incubating archetype will
> > probably work just fine (save change the version of Isis referenced,
> > obviously).
> >
> >
> >
> >
> > >
> > > This got me wondering. Could a browser-based multi-window interface be
> > > built on top of the JSON viewer and a javascript ui library? I looked
> at
> > > all the contenders (YUI, jQuery, MooTools, Backbone, ExtJS) and finally
> > > settled on jQuery after seeing this blog post [1] and looking at the
> > > jqMobile example.
> > >
> >
> > Indeed. And in fact a chap called Johan Andries had the same idea and
> > spent some time putting together an early JS application against the
> > Restful interface using JQueryUI and Backbone. He's also shared his
> code,
> > at [5].
> >
> >
> >
> >
> > >
> > > I've been playing with it for the past couple weeks and I'm at the
> point
> > > where I wanted to know if this is something the community is interested
> > in.
> > > I know it's ANOTHER viewer and I'm making no claims that it's ready (or
> > > will ever be ready) for anyone else to use. I'm really asking if the
> > ideas
> > > embodied in the DnD viewer are still desired?
> >
> >
> > Yes, I think they are. In fact, Johan's viewer also uses the DnD as its
> > metaphor. I had a quick play with your app [4] (though not for long)
> and I
> > think that Johan has gotten a little further with his framework than you.
> > That said, he doesn't seem to have done any work on it since Nov last.
> >
> > So, one option you might want to explore is to contact Johan and either
> > join his project, or fork it and take it from there.
> >
> > For myself, I was thinking that a GUI based on ExtJS might do well as a
> > sovereign style app... but I can't see myself starting on that this year
> > (2012).
> >
> >
> >
> > > The most important to me
> > > being multiple objects on a virtual desktop that you can visually
> layout
> > to
> > > increase understanding.
> > >
> >
> > Agreed. Also, with toolkits such as SenchaTouch, I think there are
> > opportunities for very interactive UIs that can be deployed on iPADs and
> > the like.
> >
> >
> >
> >
> > >
> > > All of the latest developments I've seen, both in Isis and
> > NakedObject.NET,
> > > have centered on single-object view web layouts. Was it discovered that
> > the
> > > desktop metaphor viewers were lacking for some users?
> >
> >
> > The next generation of the Irish government project is indeed moving to
> > Naked Objects MVC. It's too early to say how that will pan out.
> >
> > However, the issue with the DnD viewer is mostly its architecture: the
> > client/server remoting protocol, and having to maintain client-side cache
> > of objects and managing transient/persistent objects and lazy loading
> over
> > the wire. The Irish app which runs under this architecture does work,
> but
> > the sordid little secret is that there are a number of hacks under the
> > covers to get it to do so.
> >
> > But this is why the Restful interface (per the json-viewer) is so
> > important, I think: it will enable different types of viewers with
> whatever
> > UI paradigm fits, but on a solid, scalable, back-end architecture .
> >
> > So... I would say, go for it and build a DnD (or whatever) viewer, using
> > the restful API. There's no reason not to.
> >
> >
> >
> > > The new web viewers
> > > are great but they don't give me the same sense of exploration as the
> > > original GUI. Maybe that exploration isn't needed after the model
> > > solidifies and the app is being used.
> > >
> > > Anyway, sorry for rambling.
> >
> >
> > Not at all... very interested to hear your thoughts.
> >
> >
> >
> > > I tried something new and posted my little app
> > > on Heroku. If I understand the service right you can access the JSON
> > viewer
> > > [2], the HTML viewer [3] and my "windowed" viewer [4] at the urls
> below.
> > It
> > > might take a few seconds to spool up. Credentials are sven/pass. Tested
> > in
> > > Chrome, FF, and Safari.
> > >
> >
> > Heroku: that's on my todo list to look into. I might pick your brains.
> >
> >
> >
> > >
> > > Again it's nowhere near complete but you can execute actions, view
> > objects
> > > and collections, create objects and modify properties (mostly.)
> > >
> > > Thanks for creating a wonderful framework to build on.
> > >
> >
> > Thanks for the kind words, looking forward to continuing the
> conversation!
> >
> > Cheers
> > Dan
> >
> >
> >
> > > --
> > > Adam Howard
> > >
> > > [1]
> > >
> > >
> >
> http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
> > > [2] http://simple-dusk-6870.herokuapp.com
> > > [3] http://simple-dusk-6870.herokuapp.com/htmlviewer
> > > [4] http://simple-dusk-6870.herokuapp.com/services.html
> >
> >
> > [5] http://code.google.com/p/restfulobjects-js/
> >
>
Re: Introduction and another viewer
Posted by Mark Struberg <st...@yahoo.de>.
The point is that here at ASF we only take code if someone explicitly gives it to us.
Of course not if those are only a few lines of code or a pretty straight forward basic task without much own work. But it's more complex and originary work then we just don't take it.
There are quite a few reasons for it.
a.) we don't know where this code came from. We've seen quite some code which got published on sf or other hosters which are taken from company projects and thus _not_ IP clean.
b.) we don't grab code if the user doesn't want us to have it. Even if we would be perfectly fine from a legal point. We just don't do that ;)
c.) most users are happy to share the burden of developing code with others. Especially when getting good feedback! Open Source is not only about the code, but also to a big degree about the community behind it. Developing is just not that funny without having someone to discuss directions and complex problems ;)
So lets just try to reach out to him a bit.
LieGrue,
strub
----- Original Message -----
> From: Dan Haywood <da...@haywood-associates.co.uk>
> To: isis-users@incubator.apache.org
> Cc:
> Sent: Friday, June 15, 2012 3:57 PM
> Subject: Re: Introduction and another viewer
>
> On 15 June 2012 14:51, Adam Howard <ho...@gmail.com> wrote:
>
>>
>> Johan's project is separate from mine. I haven't gotten a reply
> back
>> from him yet.
>>
>
> If he's unresponsive (I don't know him personally), you can always fork
> his
> code, of course. He very kindly published it with an MIT license, that's
> very liberal and compatible with Apache.
>
> Dan
>
>
>
>>
>> --
>> Adam Howard
>>
>> On Jun 15, 2012, at 1:37 AM, Mark Struberg <st...@yahoo.de> wrote:
>>
>> > sounds really great.
>> >
>> > I cannot estimate this, but do you think this could make a good part
> of
>> Isis itself?
>> > What did you and Johan use as license so far? And who else contributed
>> to the code?
>> >
>> > Dan, is it mature enough to be a candidate? Or shall we better keep is
>> separated yet?
>> >
>> > Just lots of blue-eyed if-then-else questions ;)
>> >
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> > ----- Original Message -----
>> >> From: Adam Howard <ho...@gmail.com>
>> >> To: isis-users@incubator.apache.org
>> >> Cc:
>> >> Sent: Friday, June 15, 2012 5:06 AM
>> >> Subject: Re: Introduction and another viewer
>> >>
>> >> Dan,
>> >>
>> >> Thanks for the words of encouragement and the link to Johan's
> previous
>> >> work. I tried it out tonight and it's almost as if we shared
> to do
>> lists.
>> >> He already has many of the features I wanted to add to my little
>> project. I
>> >> sent him an email and I hope to hear back from him soon.
>> >>
>> >> One of those features, though, you mentioned as a possible
> negative of
>> the
>> >> DnD viewer was maintaining a client-side cache of objects. Johan
> uses
>> this
>> >> so that the views can be direct projections of the local model.
> You
>> change
>> >> a field in one view and all others views automatically update. The
> next
>> >> step I suppose would be to tie in either the WebSockets or
> EventSource
>> API
>> >> to allow the server to broadcast object change events back to all
>> connected
>> >> viewers. Would you advise against this sort of approach? Or is the
>> >> client-side cache you mention more an artifact of the remoting
> protocol?
>> >>
>> >> On Heroku, I just signed up for the account to post this demo. It
> seemed
>> >> like the easiest and cheapest (free) way to post a simple java
> webapp.
>> >> Especially since I didn't require an RDBMS. My 24 hours of
> experience
>> have
>> >> been fine.
>> >>
>> >> On the iPad, I thought this would be cool too and then started to
> think
>> >> about how dragging and right-clicking doesn't work. Then I
> found jQuery
>> UI
>> >> Touch Punch [1] which maps the jQuery UI events to touch events:
> click
>> >> becomes tap, right-click becomes tap & hold, and they've
> made dragging
>> >> and
>> >> dropping work as well. I'll definitely have to try it out.
>> >>
>> >> --
>> >> Adam Howard
>> >>
>> >> [1] http://touchpunch.furf.com/
>> >>
>> >> On Thu, Jun 14, 2012 at 10:12 AM, Dan Haywood
>> >> <da...@haywood-associates.co.uk>wrote:
>> >>
>> >>> Hi Adam,
>> >>> Welcome to Isis, and thanks very much for your interest and
> the good
>> work
>> >>> you've already done so far!
>> >>>
>> >>> Since you've made a number of points, I've commented
> on them
>> >> inline....
>> >>>
>> >>>
>> >>> On Thursday, 14 June 2012, Adam Howard wrote:
>> >>>
>> >>>>
>> >>>> I started reading Dan's book last fall and made it
> part way
>> >> through the
>> >>>> carserv example app using Isis 0.1.2-incubating. I used
> the DnD viewer
>> >>>> almost exclusively, enjoying how tangible the objects
> became using the
>> >>>> multi-window interface.
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> About a month ago I came back to the book and decided to
> start writing
>> >> my
>> >>>> own little app alongside carserv. I grabbed the latest
> Isis quickstart
>> >>>> archetype (0.2.0-incubating) and started coding.
> Surprisingly, I saw
>> >> that
>> >>>> the DnD viewer was no longer included as standard in the
> archetype. I
>> >>> used
>> >>>> the HTML viewer for about a week but it just didn't
> feel the same.
>> >> With
>> >>> the
>> >>>> DnD viewer I could look at my object representations and
> it would help
>> >>>> drive my modeling. "Oh, I need a relationship here so
> I can drop
>> >> this
>> >>>> object on that one."
>> >>>>
>> >>>
>> >>> Like you, I also have a soft spot for the DnD viewer, and Rob
> does too
>> of
>> >>> course because it's his baby. It's also the viewer
> that's used
>> >> on the big
>> >>> system in Ireland, used by 2,500+ people on a day-to-day
> basis.
>> >>>
>> >>> On the other hand, the DnD viewer, let's say, not the
> prettiest of UIs.
>> >>> (For myself at least) I'm pretty sure lots of people
> have seen it and
>> >> got
>> >>> turned off by Isis / the naked objects pattern....
>> >>>
>> >>> As you've probably realized, the DnD viewer code itself
> has not been
>> >>> deleted. However, we removed it from the archetype because:
>> >>> * we wanted to try to include only the stuff that was
> "complete",
>> >> and in
>> >>> its current incarnation a few new features are only
> semi-implemented
>> >>> * its status was becoming less clear with the move to remove
> the
>> remoting
>> >>> stuff
>> >>> * to figure out what it's positioning should be within the
> context of
>> >> the
>> >>> other viewers.
>> >>>
>> >>> Where I think we are now is that we see the DnD viewer as
> being
>> >>> resurrected, but positioned solely as a design tool for
> developers.
>> >>>
>> >>> At some point Rob needs to do some tidy up work to remove the
>> >>> semi-implemented features and get it back to where it was
> (ideally: I'd
>> >>> like it to look like NOF 3.0.3, with the collections on the
> left). As
>> and
>> >>> when that's done, I'll add it back into the archetype.
>> >>>
>> >>> In the meantime, you can of course create a Maven module and
> reference
>> the
>> >>> viewer; the module generated from the 0.1.2-incubating
> archetype will
>> >>> probably work just fine (save change the version of Isis
> referenced,
>> >>> obviously).
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> This got me wondering. Could a browser-based multi-window
> interface be
>> >>>> built on top of the JSON viewer and a javascript ui
> library? I looked
>> >> at
>> >>>> all the contenders (YUI, jQuery, MooTools, Backbone,
> ExtJS) and
>> >> finally
>> >>>> settled on jQuery after seeing this blog post [1] and
> looking at the
>> >>>> jqMobile example.
>> >>>>
>> >>>
>> >>> Indeed. And in fact a chap called Johan Andries had the same
> idea and
>> >>> spent some time putting together an early JS application
> against the
>> >>> Restful interface using JQueryUI and Backbone. He's also
> shared his
>> >> code,
>> >>> at [5].
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> I've been playing with it for the past couple weeks
> and I'm at
>> >> the point
>> >>>> where I wanted to know if this is something the community
> is
>> >> interested
>> >>> in.
>> >>>> I know it's ANOTHER viewer and I'm making no
> claims that
>> >> it's ready (or
>> >>>> will ever be ready) for anyone else to use. I'm really
> asking if
>> >> the
>> >>> ideas
>> >>>> embodied in the DnD viewer are still desired?
>> >>>
>> >>>
>> >>> Yes, I think they are. In fact, Johan's viewer also uses
> the DnD as
>> >> its
>> >>> metaphor. I had a quick play with your app [4] (though not
> for long)
>> and I
>> >>> think that Johan has gotten a little further with his
> framework than
>> you.
>> >>> That said, he doesn't seem to have done any work on it
> since Nov
>> last.
>> >>>
>> >>> So, one option you might want to explore is to contact Johan
> and either
>> >>> join his project, or fork it and take it from there.
>> >>>
>> >>> For myself, I was thinking that a GUI based on ExtJS might do
> well as a
>> >>> sovereign style app... but I can't see myself starting on
> that this
>> >> year
>> >>> (2012).
>> >>>
>> >>>
>> >>>
>> >>>> The most important to me
>> >>>> being multiple objects on a virtual desktop that you can
> visually
>> >> layout
>> >>> to
>> >>>> increase understanding.
>> >>>>
>> >>>
>> >>> Agreed. Also, with toolkits such as SenchaTouch, I think
> there are
>> >>> opportunities for very interactive UIs that can be deployed on
> iPADs
>> and
>> >>> the like.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> All of the latest developments I've seen, both in Isis
> and
>> >>> NakedObject.NET,
>> >>>> have centered on single-object view web layouts. Was it
> discovered
>> >> that
>> >>> the
>> >>>> desktop metaphor viewers were lacking for some users?
>> >>>
>> >>>
>> >>> The next generation of the Irish government project is indeed
> moving to
>> >>> Naked Objects MVC. It's too early to say how that will
> pan out.
>> >>>
>> >>> However, the issue with the DnD viewer is mostly its
> architecture: the
>> >>> client/server remoting protocol, and having to maintain
> client-side
>> cache
>> >>> of objects and managing transient/persistent objects and lazy
> loading
>> over
>> >>> the wire. The Irish app which runs under this architecture
> does work,
>> but
>> >>> the sordid little secret is that there are a number of hacks
> under the
>> >>> covers to get it to do so.
>> >>>
>> >>> But this is why the Restful interface (per the json-viewer) is
> so
>> >>> important, I think: it will enable different types of viewers
> with
>> whatever
>> >>> UI paradigm fits, but on a solid, scalable, back-end
> architecture .
>> >>>
>> >>> So... I would say, go for it and build a DnD (or whatever)
> viewer,
>> using
>> >>> the restful API. There's no reason not to.
>> >>>
>> >>>
>> >>>
>> >>>> The new web viewers
>> >>>> are great but they don't give me the same sense of
> exploration as
>> >> the
>> >>>> original GUI. Maybe that exploration isn't needed
> after the model
>> >>>> solidifies and the app is being used.
>> >>>>
>> >>>> Anyway, sorry for rambling.
>> >>>
>> >>>
>> >>> Not at all... very interested to hear your thoughts.
>> >>>
>> >>>
>> >>>
>> >>>> I tried something new and posted my little app
>> >>>> on Heroku. If I understand the service right you can
> access the JSON
>> >>> viewer
>> >>>> [2], the HTML viewer [3] and my "windowed"
> viewer [4] at the
>> >> urls below.
>> >>> It
>> >>>> might take a few seconds to spool up. Credentials are
> sven/pass.
>> >> Tested
>> >>> in
>> >>>> Chrome, FF, and Safari.
>> >>>>
>> >>>
>> >>> Heroku: that's on my todo list to look into. I might pick
> your brains.
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> Again it's nowhere near complete but you can execute
> actions, view
>> >>> objects
>> >>>> and collections, create objects and modify properties
> (mostly.)
>> >>>>
>> >>>> Thanks for creating a wonderful framework to build on.
>> >>>>
>> >>>
>> >>> Thanks for the kind words, looking forward to continuing the
>> conversation!
>> >>>
>> >>> Cheers
>> >>> Dan
>> >>>
>> >>>
>> >>>
>> >>>> --
>> >>>> Adam Howard
>> >>>>
>> >>>> [1]
>> >>>>
>> >>>>
>> >>>
>> >>
>>
> http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
>> >>>> [2] http://simple-dusk-6870.herokuapp.com
>> >>>> [3] http://simple-dusk-6870.herokuapp.com/htmlviewer
>> >>>> [4] http://simple-dusk-6870.herokuapp.com/services.html
>> >>>
>> >>>
>> >>> [5] http://code.google.com/p/restfulobjects-js/
>> >>>
>> >>
>>
>
Re: Introduction and another viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 15 June 2012 14:51, Adam Howard <ho...@gmail.com> wrote:
>
> Johan's project is separate from mine. I haven't gotten a reply back
> from him yet.
>
If he's unresponsive (I don't know him personally), you can always fork his
code, of course. He very kindly published it with an MIT license, that's
very liberal and compatible with Apache.
Dan
>
> --
> Adam Howard
>
> On Jun 15, 2012, at 1:37 AM, Mark Struberg <st...@yahoo.de> wrote:
>
> > sounds really great.
> >
> > I cannot estimate this, but do you think this could make a good part of
> Isis itself?
> > What did you and Johan use as license so far? And who else contributed
> to the code?
> >
> > Dan, is it mature enough to be a candidate? Or shall we better keep is
> separated yet?
> >
> > Just lots of blue-eyed if-then-else questions ;)
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> >> From: Adam Howard <ho...@gmail.com>
> >> To: isis-users@incubator.apache.org
> >> Cc:
> >> Sent: Friday, June 15, 2012 5:06 AM
> >> Subject: Re: Introduction and another viewer
> >>
> >> Dan,
> >>
> >> Thanks for the words of encouragement and the link to Johan's previous
> >> work. I tried it out tonight and it's almost as if we shared to do
> lists.
> >> He already has many of the features I wanted to add to my little
> project. I
> >> sent him an email and I hope to hear back from him soon.
> >>
> >> One of those features, though, you mentioned as a possible negative of
> the
> >> DnD viewer was maintaining a client-side cache of objects. Johan uses
> this
> >> so that the views can be direct projections of the local model. You
> change
> >> a field in one view and all others views automatically update. The next
> >> step I suppose would be to tie in either the WebSockets or EventSource
> API
> >> to allow the server to broadcast object change events back to all
> connected
> >> viewers. Would you advise against this sort of approach? Or is the
> >> client-side cache you mention more an artifact of the remoting protocol?
> >>
> >> On Heroku, I just signed up for the account to post this demo. It seemed
> >> like the easiest and cheapest (free) way to post a simple java webapp.
> >> Especially since I didn't require an RDBMS. My 24 hours of experience
> have
> >> been fine.
> >>
> >> On the iPad, I thought this would be cool too and then started to think
> >> about how dragging and right-clicking doesn't work. Then I found jQuery
> UI
> >> Touch Punch [1] which maps the jQuery UI events to touch events: click
> >> becomes tap, right-click becomes tap & hold, and they've made dragging
> >> and
> >> dropping work as well. I'll definitely have to try it out.
> >>
> >> --
> >> Adam Howard
> >>
> >> [1] http://touchpunch.furf.com/
> >>
> >> On Thu, Jun 14, 2012 at 10:12 AM, Dan Haywood
> >> <da...@haywood-associates.co.uk>wrote:
> >>
> >>> Hi Adam,
> >>> Welcome to Isis, and thanks very much for your interest and the good
> work
> >>> you've already done so far!
> >>>
> >>> Since you've made a number of points, I've commented on them
> >> inline....
> >>>
> >>>
> >>> On Thursday, 14 June 2012, Adam Howard wrote:
> >>>
> >>>>
> >>>> I started reading Dan's book last fall and made it part way
> >> through the
> >>>> carserv example app using Isis 0.1.2-incubating. I used the DnD viewer
> >>>> almost exclusively, enjoying how tangible the objects became using the
> >>>> multi-window interface.
> >>>>
> >>>
> >>>
> >>>
> >>>>
> >>>> About a month ago I came back to the book and decided to start writing
> >> my
> >>>> own little app alongside carserv. I grabbed the latest Isis quickstart
> >>>> archetype (0.2.0-incubating) and started coding. Surprisingly, I saw
> >> that
> >>>> the DnD viewer was no longer included as standard in the archetype. I
> >>> used
> >>>> the HTML viewer for about a week but it just didn't feel the same.
> >> With
> >>> the
> >>>> DnD viewer I could look at my object representations and it would help
> >>>> drive my modeling. "Oh, I need a relationship here so I can drop
> >> this
> >>>> object on that one."
> >>>>
> >>>
> >>> Like you, I also have a soft spot for the DnD viewer, and Rob does too
> of
> >>> course because it's his baby. It's also the viewer that's used
> >> on the big
> >>> system in Ireland, used by 2,500+ people on a day-to-day basis.
> >>>
> >>> On the other hand, the DnD viewer, let's say, not the prettiest of UIs.
> >>> (For myself at least) I'm pretty sure lots of people have seen it and
> >> got
> >>> turned off by Isis / the naked objects pattern....
> >>>
> >>> As you've probably realized, the DnD viewer code itself has not been
> >>> deleted. However, we removed it from the archetype because:
> >>> * we wanted to try to include only the stuff that was "complete",
> >> and in
> >>> its current incarnation a few new features are only semi-implemented
> >>> * its status was becoming less clear with the move to remove the
> remoting
> >>> stuff
> >>> * to figure out what it's positioning should be within the context of
> >> the
> >>> other viewers.
> >>>
> >>> Where I think we are now is that we see the DnD viewer as being
> >>> resurrected, but positioned solely as a design tool for developers.
> >>>
> >>> At some point Rob needs to do some tidy up work to remove the
> >>> semi-implemented features and get it back to where it was (ideally: I'd
> >>> like it to look like NOF 3.0.3, with the collections on the left). As
> and
> >>> when that's done, I'll add it back into the archetype.
> >>>
> >>> In the meantime, you can of course create a Maven module and reference
> the
> >>> viewer; the module generated from the 0.1.2-incubating archetype will
> >>> probably work just fine (save change the version of Isis referenced,
> >>> obviously).
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> This got me wondering. Could a browser-based multi-window interface be
> >>>> built on top of the JSON viewer and a javascript ui library? I looked
> >> at
> >>>> all the contenders (YUI, jQuery, MooTools, Backbone, ExtJS) and
> >> finally
> >>>> settled on jQuery after seeing this blog post [1] and looking at the
> >>>> jqMobile example.
> >>>>
> >>>
> >>> Indeed. And in fact a chap called Johan Andries had the same idea and
> >>> spent some time putting together an early JS application against the
> >>> Restful interface using JQueryUI and Backbone. He's also shared his
> >> code,
> >>> at [5].
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> I've been playing with it for the past couple weeks and I'm at
> >> the point
> >>>> where I wanted to know if this is something the community is
> >> interested
> >>> in.
> >>>> I know it's ANOTHER viewer and I'm making no claims that
> >> it's ready (or
> >>>> will ever be ready) for anyone else to use. I'm really asking if
> >> the
> >>> ideas
> >>>> embodied in the DnD viewer are still desired?
> >>>
> >>>
> >>> Yes, I think they are. In fact, Johan's viewer also uses the DnD as
> >> its
> >>> metaphor. I had a quick play with your app [4] (though not for long)
> and I
> >>> think that Johan has gotten a little further with his framework than
> you.
> >>> That said, he doesn't seem to have done any work on it since Nov
> last.
> >>>
> >>> So, one option you might want to explore is to contact Johan and either
> >>> join his project, or fork it and take it from there.
> >>>
> >>> For myself, I was thinking that a GUI based on ExtJS might do well as a
> >>> sovereign style app... but I can't see myself starting on that this
> >> year
> >>> (2012).
> >>>
> >>>
> >>>
> >>>> The most important to me
> >>>> being multiple objects on a virtual desktop that you can visually
> >> layout
> >>> to
> >>>> increase understanding.
> >>>>
> >>>
> >>> Agreed. Also, with toolkits such as SenchaTouch, I think there are
> >>> opportunities for very interactive UIs that can be deployed on iPADs
> and
> >>> the like.
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> All of the latest developments I've seen, both in Isis and
> >>> NakedObject.NET,
> >>>> have centered on single-object view web layouts. Was it discovered
> >> that
> >>> the
> >>>> desktop metaphor viewers were lacking for some users?
> >>>
> >>>
> >>> The next generation of the Irish government project is indeed moving to
> >>> Naked Objects MVC. It's too early to say how that will pan out.
> >>>
> >>> However, the issue with the DnD viewer is mostly its architecture: the
> >>> client/server remoting protocol, and having to maintain client-side
> cache
> >>> of objects and managing transient/persistent objects and lazy loading
> over
> >>> the wire. The Irish app which runs under this architecture does work,
> but
> >>> the sordid little secret is that there are a number of hacks under the
> >>> covers to get it to do so.
> >>>
> >>> But this is why the Restful interface (per the json-viewer) is so
> >>> important, I think: it will enable different types of viewers with
> whatever
> >>> UI paradigm fits, but on a solid, scalable, back-end architecture .
> >>>
> >>> So... I would say, go for it and build a DnD (or whatever) viewer,
> using
> >>> the restful API. There's no reason not to.
> >>>
> >>>
> >>>
> >>>> The new web viewers
> >>>> are great but they don't give me the same sense of exploration as
> >> the
> >>>> original GUI. Maybe that exploration isn't needed after the model
> >>>> solidifies and the app is being used.
> >>>>
> >>>> Anyway, sorry for rambling.
> >>>
> >>>
> >>> Not at all... very interested to hear your thoughts.
> >>>
> >>>
> >>>
> >>>> I tried something new and posted my little app
> >>>> on Heroku. If I understand the service right you can access the JSON
> >>> viewer
> >>>> [2], the HTML viewer [3] and my "windowed" viewer [4] at the
> >> urls below.
> >>> It
> >>>> might take a few seconds to spool up. Credentials are sven/pass.
> >> Tested
> >>> in
> >>>> Chrome, FF, and Safari.
> >>>>
> >>>
> >>> Heroku: that's on my todo list to look into. I might pick your brains.
> >>>
> >>>
> >>>
> >>>>
> >>>> Again it's nowhere near complete but you can execute actions, view
> >>> objects
> >>>> and collections, create objects and modify properties (mostly.)
> >>>>
> >>>> Thanks for creating a wonderful framework to build on.
> >>>>
> >>>
> >>> Thanks for the kind words, looking forward to continuing the
> conversation!
> >>>
> >>> Cheers
> >>> Dan
> >>>
> >>>
> >>>
> >>>> --
> >>>> Adam Howard
> >>>>
> >>>> [1]
> >>>>
> >>>>
> >>>
> >>
> http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
> >>>> [2] http://simple-dusk-6870.herokuapp.com
> >>>> [3] http://simple-dusk-6870.herokuapp.com/htmlviewer
> >>>> [4] http://simple-dusk-6870.herokuapp.com/services.html
> >>>
> >>>
> >>> [5] http://code.google.com/p/restfulobjects-js/
> >>>
> >>
>
Re: Introduction and another viewer
Posted by Adam Howard <ho...@gmail.com>.
Hi Mark,
My project is literally just a few hours of work. Not really ready to
share yet. You can download the entirety of the code minus the css by
grabbing the services.html file from my heroku site (link [4] in
original message.) Put that file in src/main/webapp and try it out on
your model. I can work on cleaning the code up if its something
someone else wants to work on. Maybe post to Github.
Johan's project is separate from mine. I haven't gotten a reply back
from him yet.
--
Adam Howard
On Jun 15, 2012, at 1:37 AM, Mark Struberg <st...@yahoo.de> wrote:
> sounds really great.
>
> I cannot estimate this, but do you think this could make a good part of Isis itself?
> What did you and Johan use as license so far? And who else contributed to the code?
>
> Dan, is it mature enough to be a candidate? Or shall we better keep is separated yet?
>
> Just lots of blue-eyed if-then-else questions ;)
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Adam Howard <ho...@gmail.com>
>> To: isis-users@incubator.apache.org
>> Cc:
>> Sent: Friday, June 15, 2012 5:06 AM
>> Subject: Re: Introduction and another viewer
>>
>> Dan,
>>
>> Thanks for the words of encouragement and the link to Johan's previous
>> work. I tried it out tonight and it's almost as if we shared to do lists.
>> He already has many of the features I wanted to add to my little project. I
>> sent him an email and I hope to hear back from him soon.
>>
>> One of those features, though, you mentioned as a possible negative of the
>> DnD viewer was maintaining a client-side cache of objects. Johan uses this
>> so that the views can be direct projections of the local model. You change
>> a field in one view and all others views automatically update. The next
>> step I suppose would be to tie in either the WebSockets or EventSource API
>> to allow the server to broadcast object change events back to all connected
>> viewers. Would you advise against this sort of approach? Or is the
>> client-side cache you mention more an artifact of the remoting protocol?
>>
>> On Heroku, I just signed up for the account to post this demo. It seemed
>> like the easiest and cheapest (free) way to post a simple java webapp.
>> Especially since I didn't require an RDBMS. My 24 hours of experience have
>> been fine.
>>
>> On the iPad, I thought this would be cool too and then started to think
>> about how dragging and right-clicking doesn't work. Then I found jQuery UI
>> Touch Punch [1] which maps the jQuery UI events to touch events: click
>> becomes tap, right-click becomes tap & hold, and they've made dragging
>> and
>> dropping work as well. I'll definitely have to try it out.
>>
>> --
>> Adam Howard
>>
>> [1] http://touchpunch.furf.com/
>>
>> On Thu, Jun 14, 2012 at 10:12 AM, Dan Haywood
>> <da...@haywood-associates.co.uk>wrote:
>>
>>> Hi Adam,
>>> Welcome to Isis, and thanks very much for your interest and the good work
>>> you've already done so far!
>>>
>>> Since you've made a number of points, I've commented on them
>> inline....
>>>
>>>
>>> On Thursday, 14 June 2012, Adam Howard wrote:
>>>
>>>>
>>>> I started reading Dan's book last fall and made it part way
>> through the
>>>> carserv example app using Isis 0.1.2-incubating. I used the DnD viewer
>>>> almost exclusively, enjoying how tangible the objects became using the
>>>> multi-window interface.
>>>>
>>>
>>>
>>>
>>>>
>>>> About a month ago I came back to the book and decided to start writing
>> my
>>>> own little app alongside carserv. I grabbed the latest Isis quickstart
>>>> archetype (0.2.0-incubating) and started coding. Surprisingly, I saw
>> that
>>>> the DnD viewer was no longer included as standard in the archetype. I
>>> used
>>>> the HTML viewer for about a week but it just didn't feel the same.
>> With
>>> the
>>>> DnD viewer I could look at my object representations and it would help
>>>> drive my modeling. "Oh, I need a relationship here so I can drop
>> this
>>>> object on that one."
>>>>
>>>
>>> Like you, I also have a soft spot for the DnD viewer, and Rob does too of
>>> course because it's his baby. It's also the viewer that's used
>> on the big
>>> system in Ireland, used by 2,500+ people on a day-to-day basis.
>>>
>>> On the other hand, the DnD viewer, let's say, not the prettiest of UIs.
>>> (For myself at least) I'm pretty sure lots of people have seen it and
>> got
>>> turned off by Isis / the naked objects pattern....
>>>
>>> As you've probably realized, the DnD viewer code itself has not been
>>> deleted. However, we removed it from the archetype because:
>>> * we wanted to try to include only the stuff that was "complete",
>> and in
>>> its current incarnation a few new features are only semi-implemented
>>> * its status was becoming less clear with the move to remove the remoting
>>> stuff
>>> * to figure out what it's positioning should be within the context of
>> the
>>> other viewers.
>>>
>>> Where I think we are now is that we see the DnD viewer as being
>>> resurrected, but positioned solely as a design tool for developers.
>>>
>>> At some point Rob needs to do some tidy up work to remove the
>>> semi-implemented features and get it back to where it was (ideally: I'd
>>> like it to look like NOF 3.0.3, with the collections on the left). As and
>>> when that's done, I'll add it back into the archetype.
>>>
>>> In the meantime, you can of course create a Maven module and reference the
>>> viewer; the module generated from the 0.1.2-incubating archetype will
>>> probably work just fine (save change the version of Isis referenced,
>>> obviously).
>>>
>>>
>>>
>>>
>>>>
>>>> This got me wondering. Could a browser-based multi-window interface be
>>>> built on top of the JSON viewer and a javascript ui library? I looked
>> at
>>>> all the contenders (YUI, jQuery, MooTools, Backbone, ExtJS) and
>> finally
>>>> settled on jQuery after seeing this blog post [1] and looking at the
>>>> jqMobile example.
>>>>
>>>
>>> Indeed. And in fact a chap called Johan Andries had the same idea and
>>> spent some time putting together an early JS application against the
>>> Restful interface using JQueryUI and Backbone. He's also shared his
>> code,
>>> at [5].
>>>
>>>
>>>
>>>
>>>>
>>>> I've been playing with it for the past couple weeks and I'm at
>> the point
>>>> where I wanted to know if this is something the community is
>> interested
>>> in.
>>>> I know it's ANOTHER viewer and I'm making no claims that
>> it's ready (or
>>>> will ever be ready) for anyone else to use. I'm really asking if
>> the
>>> ideas
>>>> embodied in the DnD viewer are still desired?
>>>
>>>
>>> Yes, I think they are. In fact, Johan's viewer also uses the DnD as
>> its
>>> metaphor. I had a quick play with your app [4] (though not for long) and I
>>> think that Johan has gotten a little further with his framework than you.
>>> That said, he doesn't seem to have done any work on it since Nov last.
>>>
>>> So, one option you might want to explore is to contact Johan and either
>>> join his project, or fork it and take it from there.
>>>
>>> For myself, I was thinking that a GUI based on ExtJS might do well as a
>>> sovereign style app... but I can't see myself starting on that this
>> year
>>> (2012).
>>>
>>>
>>>
>>>> The most important to me
>>>> being multiple objects on a virtual desktop that you can visually
>> layout
>>> to
>>>> increase understanding.
>>>>
>>>
>>> Agreed. Also, with toolkits such as SenchaTouch, I think there are
>>> opportunities for very interactive UIs that can be deployed on iPADs and
>>> the like.
>>>
>>>
>>>
>>>
>>>>
>>>> All of the latest developments I've seen, both in Isis and
>>> NakedObject.NET,
>>>> have centered on single-object view web layouts. Was it discovered
>> that
>>> the
>>>> desktop metaphor viewers were lacking for some users?
>>>
>>>
>>> The next generation of the Irish government project is indeed moving to
>>> Naked Objects MVC. It's too early to say how that will pan out.
>>>
>>> However, the issue with the DnD viewer is mostly its architecture: the
>>> client/server remoting protocol, and having to maintain client-side cache
>>> of objects and managing transient/persistent objects and lazy loading over
>>> the wire. The Irish app which runs under this architecture does work, but
>>> the sordid little secret is that there are a number of hacks under the
>>> covers to get it to do so.
>>>
>>> But this is why the Restful interface (per the json-viewer) is so
>>> important, I think: it will enable different types of viewers with whatever
>>> UI paradigm fits, but on a solid, scalable, back-end architecture .
>>>
>>> So... I would say, go for it and build a DnD (or whatever) viewer, using
>>> the restful API. There's no reason not to.
>>>
>>>
>>>
>>>> The new web viewers
>>>> are great but they don't give me the same sense of exploration as
>> the
>>>> original GUI. Maybe that exploration isn't needed after the model
>>>> solidifies and the app is being used.
>>>>
>>>> Anyway, sorry for rambling.
>>>
>>>
>>> Not at all... very interested to hear your thoughts.
>>>
>>>
>>>
>>>> I tried something new and posted my little app
>>>> on Heroku. If I understand the service right you can access the JSON
>>> viewer
>>>> [2], the HTML viewer [3] and my "windowed" viewer [4] at the
>> urls below.
>>> It
>>>> might take a few seconds to spool up. Credentials are sven/pass.
>> Tested
>>> in
>>>> Chrome, FF, and Safari.
>>>>
>>>
>>> Heroku: that's on my todo list to look into. I might pick your brains.
>>>
>>>
>>>
>>>>
>>>> Again it's nowhere near complete but you can execute actions, view
>>> objects
>>>> and collections, create objects and modify properties (mostly.)
>>>>
>>>> Thanks for creating a wonderful framework to build on.
>>>>
>>>
>>> Thanks for the kind words, looking forward to continuing the conversation!
>>>
>>> Cheers
>>> Dan
>>>
>>>
>>>
>>>> --
>>>> Adam Howard
>>>>
>>>> [1]
>>>>
>>>>
>>>
>> http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
>>>> [2] http://simple-dusk-6870.herokuapp.com
>>>> [3] http://simple-dusk-6870.herokuapp.com/htmlviewer
>>>> [4] http://simple-dusk-6870.herokuapp.com/services.html
>>>
>>>
>>> [5] http://code.google.com/p/restfulobjects-js/
>>>
>>
Re: Introduction and another viewer
Posted by Mark Struberg <st...@yahoo.de>.
sounds really great.
I cannot estimate this, but do you think this could make a good part of Isis itself?
What did you and Johan use as license so far? And who else contributed to the code?
Dan, is it mature enough to be a candidate? Or shall we better keep is separated yet?
Just lots of blue-eyed if-then-else questions ;)
LieGrue,
strub
----- Original Message -----
> From: Adam Howard <ho...@gmail.com>
> To: isis-users@incubator.apache.org
> Cc:
> Sent: Friday, June 15, 2012 5:06 AM
> Subject: Re: Introduction and another viewer
>
> Dan,
>
> Thanks for the words of encouragement and the link to Johan's previous
> work. I tried it out tonight and it's almost as if we shared to do lists.
> He already has many of the features I wanted to add to my little project. I
> sent him an email and I hope to hear back from him soon.
>
> One of those features, though, you mentioned as a possible negative of the
> DnD viewer was maintaining a client-side cache of objects. Johan uses this
> so that the views can be direct projections of the local model. You change
> a field in one view and all others views automatically update. The next
> step I suppose would be to tie in either the WebSockets or EventSource API
> to allow the server to broadcast object change events back to all connected
> viewers. Would you advise against this sort of approach? Or is the
> client-side cache you mention more an artifact of the remoting protocol?
>
> On Heroku, I just signed up for the account to post this demo. It seemed
> like the easiest and cheapest (free) way to post a simple java webapp.
> Especially since I didn't require an RDBMS. My 24 hours of experience have
> been fine.
>
> On the iPad, I thought this would be cool too and then started to think
> about how dragging and right-clicking doesn't work. Then I found jQuery UI
> Touch Punch [1] which maps the jQuery UI events to touch events: click
> becomes tap, right-click becomes tap & hold, and they've made dragging
> and
> dropping work as well. I'll definitely have to try it out.
>
> --
> Adam Howard
>
> [1] http://touchpunch.furf.com/
>
> On Thu, Jun 14, 2012 at 10:12 AM, Dan Haywood
> <da...@haywood-associates.co.uk>wrote:
>
>> Hi Adam,
>> Welcome to Isis, and thanks very much for your interest and the good work
>> you've already done so far!
>>
>> Since you've made a number of points, I've commented on them
> inline....
>>
>>
>> On Thursday, 14 June 2012, Adam Howard wrote:
>>
>> >
>> > I started reading Dan's book last fall and made it part way
> through the
>> > carserv example app using Isis 0.1.2-incubating. I used the DnD viewer
>> > almost exclusively, enjoying how tangible the objects became using the
>> > multi-window interface.
>> >
>>
>>
>>
>> >
>> > About a month ago I came back to the book and decided to start writing
> my
>> > own little app alongside carserv. I grabbed the latest Isis quickstart
>> > archetype (0.2.0-incubating) and started coding. Surprisingly, I saw
> that
>> > the DnD viewer was no longer included as standard in the archetype. I
>> used
>> > the HTML viewer for about a week but it just didn't feel the same.
> With
>> the
>> > DnD viewer I could look at my object representations and it would help
>> > drive my modeling. "Oh, I need a relationship here so I can drop
> this
>> > object on that one."
>> >
>>
>> Like you, I also have a soft spot for the DnD viewer, and Rob does too of
>> course because it's his baby. It's also the viewer that's used
> on the big
>> system in Ireland, used by 2,500+ people on a day-to-day basis.
>>
>> On the other hand, the DnD viewer, let's say, not the prettiest of UIs.
>> (For myself at least) I'm pretty sure lots of people have seen it and
> got
>> turned off by Isis / the naked objects pattern....
>>
>> As you've probably realized, the DnD viewer code itself has not been
>> deleted. However, we removed it from the archetype because:
>> * we wanted to try to include only the stuff that was "complete",
> and in
>> its current incarnation a few new features are only semi-implemented
>> * its status was becoming less clear with the move to remove the remoting
>> stuff
>> * to figure out what it's positioning should be within the context of
> the
>> other viewers.
>>
>> Where I think we are now is that we see the DnD viewer as being
>> resurrected, but positioned solely as a design tool for developers.
>>
>> At some point Rob needs to do some tidy up work to remove the
>> semi-implemented features and get it back to where it was (ideally: I'd
>> like it to look like NOF 3.0.3, with the collections on the left). As and
>> when that's done, I'll add it back into the archetype.
>>
>> In the meantime, you can of course create a Maven module and reference the
>> viewer; the module generated from the 0.1.2-incubating archetype will
>> probably work just fine (save change the version of Isis referenced,
>> obviously).
>>
>>
>>
>>
>> >
>> > This got me wondering. Could a browser-based multi-window interface be
>> > built on top of the JSON viewer and a javascript ui library? I looked
> at
>> > all the contenders (YUI, jQuery, MooTools, Backbone, ExtJS) and
> finally
>> > settled on jQuery after seeing this blog post [1] and looking at the
>> > jqMobile example.
>> >
>>
>> Indeed. And in fact a chap called Johan Andries had the same idea and
>> spent some time putting together an early JS application against the
>> Restful interface using JQueryUI and Backbone. He's also shared his
> code,
>> at [5].
>>
>>
>>
>>
>> >
>> > I've been playing with it for the past couple weeks and I'm at
> the point
>> > where I wanted to know if this is something the community is
> interested
>> in.
>> > I know it's ANOTHER viewer and I'm making no claims that
> it's ready (or
>> > will ever be ready) for anyone else to use. I'm really asking if
> the
>> ideas
>> > embodied in the DnD viewer are still desired?
>>
>>
>> Yes, I think they are. In fact, Johan's viewer also uses the DnD as
> its
>> metaphor. I had a quick play with your app [4] (though not for long) and I
>> think that Johan has gotten a little further with his framework than you.
>> That said, he doesn't seem to have done any work on it since Nov last.
>>
>> So, one option you might want to explore is to contact Johan and either
>> join his project, or fork it and take it from there.
>>
>> For myself, I was thinking that a GUI based on ExtJS might do well as a
>> sovereign style app... but I can't see myself starting on that this
> year
>> (2012).
>>
>>
>>
>> > The most important to me
>> > being multiple objects on a virtual desktop that you can visually
> layout
>> to
>> > increase understanding.
>> >
>>
>> Agreed. Also, with toolkits such as SenchaTouch, I think there are
>> opportunities for very interactive UIs that can be deployed on iPADs and
>> the like.
>>
>>
>>
>>
>> >
>> > All of the latest developments I've seen, both in Isis and
>> NakedObject.NET,
>> > have centered on single-object view web layouts. Was it discovered
> that
>> the
>> > desktop metaphor viewers were lacking for some users?
>>
>>
>> The next generation of the Irish government project is indeed moving to
>> Naked Objects MVC. It's too early to say how that will pan out.
>>
>> However, the issue with the DnD viewer is mostly its architecture: the
>> client/server remoting protocol, and having to maintain client-side cache
>> of objects and managing transient/persistent objects and lazy loading over
>> the wire. The Irish app which runs under this architecture does work, but
>> the sordid little secret is that there are a number of hacks under the
>> covers to get it to do so.
>>
>> But this is why the Restful interface (per the json-viewer) is so
>> important, I think: it will enable different types of viewers with whatever
>> UI paradigm fits, but on a solid, scalable, back-end architecture .
>>
>> So... I would say, go for it and build a DnD (or whatever) viewer, using
>> the restful API. There's no reason not to.
>>
>>
>>
>> > The new web viewers
>> > are great but they don't give me the same sense of exploration as
> the
>> > original GUI. Maybe that exploration isn't needed after the model
>> > solidifies and the app is being used.
>> >
>> > Anyway, sorry for rambling.
>>
>>
>> Not at all... very interested to hear your thoughts.
>>
>>
>>
>> > I tried something new and posted my little app
>> > on Heroku. If I understand the service right you can access the JSON
>> viewer
>> > [2], the HTML viewer [3] and my "windowed" viewer [4] at the
> urls below.
>> It
>> > might take a few seconds to spool up. Credentials are sven/pass.
> Tested
>> in
>> > Chrome, FF, and Safari.
>> >
>>
>> Heroku: that's on my todo list to look into. I might pick your brains.
>>
>>
>>
>> >
>> > Again it's nowhere near complete but you can execute actions, view
>> objects
>> > and collections, create objects and modify properties (mostly.)
>> >
>> > Thanks for creating a wonderful framework to build on.
>> >
>>
>> Thanks for the kind words, looking forward to continuing the conversation!
>>
>> Cheers
>> Dan
>>
>>
>>
>> > --
>> > Adam Howard
>> >
>> > [1]
>> >
>> >
>>
> http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
>> > [2] http://simple-dusk-6870.herokuapp.com
>> > [3] http://simple-dusk-6870.herokuapp.com/htmlviewer
>> > [4] http://simple-dusk-6870.herokuapp.com/services.html
>>
>>
>> [5] http://code.google.com/p/restfulobjects-js/
>>
>
Re: Introduction and another viewer
Posted by Adam Howard <ho...@gmail.com>.
Dan,
Thanks for the words of encouragement and the link to Johan's previous
work. I tried it out tonight and it's almost as if we shared to do lists.
He already has many of the features I wanted to add to my little project. I
sent him an email and I hope to hear back from him soon.
One of those features, though, you mentioned as a possible negative of the
DnD viewer was maintaining a client-side cache of objects. Johan uses this
so that the views can be direct projections of the local model. You change
a field in one view and all others views automatically update. The next
step I suppose would be to tie in either the WebSockets or EventSource API
to allow the server to broadcast object change events back to all connected
viewers. Would you advise against this sort of approach? Or is the
client-side cache you mention more an artifact of the remoting protocol?
On Heroku, I just signed up for the account to post this demo. It seemed
like the easiest and cheapest (free) way to post a simple java webapp.
Especially since I didn't require an RDBMS. My 24 hours of experience have
been fine.
On the iPad, I thought this would be cool too and then started to think
about how dragging and right-clicking doesn't work. Then I found jQuery UI
Touch Punch [1] which maps the jQuery UI events to touch events: click
becomes tap, right-click becomes tap & hold, and they've made dragging and
dropping work as well. I'll definitely have to try it out.
--
Adam Howard
[1] http://touchpunch.furf.com/
On Thu, Jun 14, 2012 at 10:12 AM, Dan Haywood
<da...@haywood-associates.co.uk>wrote:
> Hi Adam,
> Welcome to Isis, and thanks very much for your interest and the good work
> you've already done so far!
>
> Since you've made a number of points, I've commented on them inline....
>
>
> On Thursday, 14 June 2012, Adam Howard wrote:
>
> >
> > I started reading Dan's book last fall and made it part way through the
> > carserv example app using Isis 0.1.2-incubating. I used the DnD viewer
> > almost exclusively, enjoying how tangible the objects became using the
> > multi-window interface.
> >
>
>
>
> >
> > About a month ago I came back to the book and decided to start writing my
> > own little app alongside carserv. I grabbed the latest Isis quickstart
> > archetype (0.2.0-incubating) and started coding. Surprisingly, I saw that
> > the DnD viewer was no longer included as standard in the archetype. I
> used
> > the HTML viewer for about a week but it just didn't feel the same. With
> the
> > DnD viewer I could look at my object representations and it would help
> > drive my modeling. "Oh, I need a relationship here so I can drop this
> > object on that one."
> >
>
> Like you, I also have a soft spot for the DnD viewer, and Rob does too of
> course because it's his baby. It's also the viewer that's used on the big
> system in Ireland, used by 2,500+ people on a day-to-day basis.
>
> On the other hand, the DnD viewer, let's say, not the prettiest of UIs.
> (For myself at least) I'm pretty sure lots of people have seen it and got
> turned off by Isis / the naked objects pattern....
>
> As you've probably realized, the DnD viewer code itself has not been
> deleted. However, we removed it from the archetype because:
> * we wanted to try to include only the stuff that was "complete", and in
> its current incarnation a few new features are only semi-implemented
> * its status was becoming less clear with the move to remove the remoting
> stuff
> * to figure out what it's positioning should be within the context of the
> other viewers.
>
> Where I think we are now is that we see the DnD viewer as being
> resurrected, but positioned solely as a design tool for developers.
>
> At some point Rob needs to do some tidy up work to remove the
> semi-implemented features and get it back to where it was (ideally: I'd
> like it to look like NOF 3.0.3, with the collections on the left). As and
> when that's done, I'll add it back into the archetype.
>
> In the meantime, you can of course create a Maven module and reference the
> viewer; the module generated from the 0.1.2-incubating archetype will
> probably work just fine (save change the version of Isis referenced,
> obviously).
>
>
>
>
> >
> > This got me wondering. Could a browser-based multi-window interface be
> > built on top of the JSON viewer and a javascript ui library? I looked at
> > all the contenders (YUI, jQuery, MooTools, Backbone, ExtJS) and finally
> > settled on jQuery after seeing this blog post [1] and looking at the
> > jqMobile example.
> >
>
> Indeed. And in fact a chap called Johan Andries had the same idea and
> spent some time putting together an early JS application against the
> Restful interface using JQueryUI and Backbone. He's also shared his code,
> at [5].
>
>
>
>
> >
> > I've been playing with it for the past couple weeks and I'm at the point
> > where I wanted to know if this is something the community is interested
> in.
> > I know it's ANOTHER viewer and I'm making no claims that it's ready (or
> > will ever be ready) for anyone else to use. I'm really asking if the
> ideas
> > embodied in the DnD viewer are still desired?
>
>
> Yes, I think they are. In fact, Johan's viewer also uses the DnD as its
> metaphor. I had a quick play with your app [4] (though not for long) and I
> think that Johan has gotten a little further with his framework than you.
> That said, he doesn't seem to have done any work on it since Nov last.
>
> So, one option you might want to explore is to contact Johan and either
> join his project, or fork it and take it from there.
>
> For myself, I was thinking that a GUI based on ExtJS might do well as a
> sovereign style app... but I can't see myself starting on that this year
> (2012).
>
>
>
> > The most important to me
> > being multiple objects on a virtual desktop that you can visually layout
> to
> > increase understanding.
> >
>
> Agreed. Also, with toolkits such as SenchaTouch, I think there are
> opportunities for very interactive UIs that can be deployed on iPADs and
> the like.
>
>
>
>
> >
> > All of the latest developments I've seen, both in Isis and
> NakedObject.NET,
> > have centered on single-object view web layouts. Was it discovered that
> the
> > desktop metaphor viewers were lacking for some users?
>
>
> The next generation of the Irish government project is indeed moving to
> Naked Objects MVC. It's too early to say how that will pan out.
>
> However, the issue with the DnD viewer is mostly its architecture: the
> client/server remoting protocol, and having to maintain client-side cache
> of objects and managing transient/persistent objects and lazy loading over
> the wire. The Irish app which runs under this architecture does work, but
> the sordid little secret is that there are a number of hacks under the
> covers to get it to do so.
>
> But this is why the Restful interface (per the json-viewer) is so
> important, I think: it will enable different types of viewers with whatever
> UI paradigm fits, but on a solid, scalable, back-end architecture .
>
> So... I would say, go for it and build a DnD (or whatever) viewer, using
> the restful API. There's no reason not to.
>
>
>
> > The new web viewers
> > are great but they don't give me the same sense of exploration as the
> > original GUI. Maybe that exploration isn't needed after the model
> > solidifies and the app is being used.
> >
> > Anyway, sorry for rambling.
>
>
> Not at all... very interested to hear your thoughts.
>
>
>
> > I tried something new and posted my little app
> > on Heroku. If I understand the service right you can access the JSON
> viewer
> > [2], the HTML viewer [3] and my "windowed" viewer [4] at the urls below.
> It
> > might take a few seconds to spool up. Credentials are sven/pass. Tested
> in
> > Chrome, FF, and Safari.
> >
>
> Heroku: that's on my todo list to look into. I might pick your brains.
>
>
>
> >
> > Again it's nowhere near complete but you can execute actions, view
> objects
> > and collections, create objects and modify properties (mostly.)
> >
> > Thanks for creating a wonderful framework to build on.
> >
>
> Thanks for the kind words, looking forward to continuing the conversation!
>
> Cheers
> Dan
>
>
>
> > --
> > Adam Howard
> >
> > [1]
> >
> >
> http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
> > [2] http://simple-dusk-6870.herokuapp.com
> > [3] http://simple-dusk-6870.herokuapp.com/htmlviewer
> > [4] http://simple-dusk-6870.herokuapp.com/services.html
>
>
> [5] http://code.google.com/p/restfulobjects-js/
>
Re: Introduction and another viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Adam,
Welcome to Isis, and thanks very much for your interest and the good work
you've already done so far!
Since you've made a number of points, I've commented on them inline....
On Thursday, 14 June 2012, Adam Howard wrote:
>
> I started reading Dan's book last fall and made it part way through the
> carserv example app using Isis 0.1.2-incubating. I used the DnD viewer
> almost exclusively, enjoying how tangible the objects became using the
> multi-window interface.
>
>
> About a month ago I came back to the book and decided to start writing my
> own little app alongside carserv. I grabbed the latest Isis quickstart
> archetype (0.2.0-incubating) and started coding. Surprisingly, I saw that
> the DnD viewer was no longer included as standard in the archetype. I used
> the HTML viewer for about a week but it just didn't feel the same. With the
> DnD viewer I could look at my object representations and it would help
> drive my modeling. "Oh, I need a relationship here so I can drop this
> object on that one."
>
Like you, I also have a soft spot for the DnD viewer, and Rob does too of
course because it's his baby. It's also the viewer that's used on the big
system in Ireland, used by 2,500+ people on a day-to-day basis.
On the other hand, the DnD viewer, let's say, not the prettiest of UIs.
(For myself at least) I'm pretty sure lots of people have seen it and got
turned off by Isis / the naked objects pattern....
As you've probably realized, the DnD viewer code itself has not been
deleted. However, we removed it from the archetype because:
* we wanted to try to include only the stuff that was "complete", and in
its current incarnation a few new features are only semi-implemented
* its status was becoming less clear with the move to remove the remoting
stuff
* to figure out what it's positioning should be within the context of the
other viewers.
Where I think we are now is that we see the DnD viewer as being
resurrected, but positioned solely as a design tool for developers.
At some point Rob needs to do some tidy up work to remove the
semi-implemented features and get it back to where it was (ideally: I'd
like it to look like NOF 3.0.3, with the collections on the left). As and
when that's done, I'll add it back into the archetype.
In the meantime, you can of course create a Maven module and reference the
viewer; the module generated from the 0.1.2-incubating archetype will
probably work just fine (save change the version of Isis referenced,
obviously).
>
> This got me wondering. Could a browser-based multi-window interface be
> built on top of the JSON viewer and a javascript ui library? I looked at
> all the contenders (YUI, jQuery, MooTools, Backbone, ExtJS) and finally
> settled on jQuery after seeing this blog post [1] and looking at the
> jqMobile example.
>
Indeed. And in fact a chap called Johan Andries had the same idea and
spent some time putting together an early JS application against the
Restful interface using JQueryUI and Backbone. He's also shared his code,
at [5].
>
> I've been playing with it for the past couple weeks and I'm at the point
> where I wanted to know if this is something the community is interested in.
> I know it's ANOTHER viewer and I'm making no claims that it's ready (or
> will ever be ready) for anyone else to use. I'm really asking if the ideas
> embodied in the DnD viewer are still desired?
Yes, I think they are. In fact, Johan's viewer also uses the DnD as its
metaphor. I had a quick play with your app [4] (though not for long) and I
think that Johan has gotten a little further with his framework than you.
That said, he doesn't seem to have done any work on it since Nov last.
So, one option you might want to explore is to contact Johan and either
join his project, or fork it and take it from there.
For myself, I was thinking that a GUI based on ExtJS might do well as a
sovereign style app... but I can't see myself starting on that this year
(2012).
> The most important to me
> being multiple objects on a virtual desktop that you can visually layout to
> increase understanding.
>
Agreed. Also, with toolkits such as SenchaTouch, I think there are
opportunities for very interactive UIs that can be deployed on iPADs and
the like.
>
> All of the latest developments I've seen, both in Isis and NakedObject.NET,
> have centered on single-object view web layouts. Was it discovered that the
> desktop metaphor viewers were lacking for some users?
The next generation of the Irish government project is indeed moving to
Naked Objects MVC. It's too early to say how that will pan out.
However, the issue with the DnD viewer is mostly its architecture: the
client/server remoting protocol, and having to maintain client-side cache
of objects and managing transient/persistent objects and lazy loading over
the wire. The Irish app which runs under this architecture does work, but
the sordid little secret is that there are a number of hacks under the
covers to get it to do so.
But this is why the Restful interface (per the json-viewer) is so
important, I think: it will enable different types of viewers with whatever
UI paradigm fits, but on a solid, scalable, back-end architecture .
So... I would say, go for it and build a DnD (or whatever) viewer, using
the restful API. There's no reason not to.
> The new web viewers
> are great but they don't give me the same sense of exploration as the
> original GUI. Maybe that exploration isn't needed after the model
> solidifies and the app is being used.
>
> Anyway, sorry for rambling.
Not at all... very interested to hear your thoughts.
> I tried something new and posted my little app
> on Heroku. If I understand the service right you can access the JSON viewer
> [2], the HTML viewer [3] and my "windowed" viewer [4] at the urls below. It
> might take a few seconds to spool up. Credentials are sven/pass. Tested in
> Chrome, FF, and Safari.
>
Heroku: that's on my todo list to look into. I might pick your brains.
>
> Again it's nowhere near complete but you can execute actions, view objects
> and collections, create objects and modify properties (mostly.)
>
> Thanks for creating a wonderful framework to build on.
>
Thanks for the kind words, looking forward to continuing the conversation!
Cheers
Dan
> --
> Adam Howard
>
> [1]
>
> http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/
> [2] http://simple-dusk-6870.herokuapp.com
> [3] http://simple-dusk-6870.herokuapp.com/htmlviewer
> [4] http://simple-dusk-6870.herokuapp.com/services.html
[5] http://code.google.com/p/restfulobjects-js/