Replied inline. On Sun, Jun 17, 2012 at 5:09 AM, Dan Haywood <[email protected]> wrote: > I'll reach out to Johan myself, hopefully to get him re-enthused, but as a > minimum to get such a declaration that Adam can use that work as a basis > for a future Apache donation.
I did some googling and this [1] may be him [2]. I don't have a twitter account and I can't InMail on LinkedIn. > ~~~ > Whatever... all that's to come. I'll reach out to Johan, and if he > responds (which I'm sure he will) then that'll ensure that your code isn't > IP-poisoned from the outset. One more legal question then I'll get back to work. What considerations come from including other javascript libraries. Two examples: jQuery UI Touch Punch [3] is dual licensed as MIT and GPLv2. Is it ok to include it as part of my distribution? I've added it to my example app and now I can drag and resize dialogs on the iPad. See screenshot [4] or live app [5]. You mentioned ExtJS. That is licensed solely under GPLv3 but has open source license exceptions for non GPL projects including ASL. Could a viewer based on ExtJS be hosted by Apache? What if the ExtJS files were only included through a CDN and not checked in to source control? Ok. Back to coding now. -- Adam Howard [1] http://twitter.com/#!/johan_andries [2] http://www.linkedin.com/in/johanandries [3] http://touchpunch.furf.com/ [4] http://db.tt/JDRLFUkh [5] http://simple-dusk-6870.herokuapp.com/services.html > > On 16 June 2012 11:33, Mark Struberg <[email protected]> wrote: > >> 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 <[email protected]> >> > To: "[email protected]" <[email protected]> >> > 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 <[email protected]> >> >> To: [email protected] >> >> 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 <[email protected]> >> > 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 >> >> <[email protected]> >> >> 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 >> >> <[email protected]> wrote: >> >>> On 15 June 2012 04:06, Adam Howard <[email protected]> >> > 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 >> >>>> <[email protected]>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/ >> >>>> > >> >>>> >> >> >> > >>
