This project is read-only.

AROW viewer ready for 1.0.0

Jul 10, 2012 at 5:01 AM

Hi All,

AROW has been updated to work with RO spec 1.0.0 and thus RO.NET. I have an example app up pointing at the AdventureWorks demo hosted by Richard and Stef.

http://simple-dusk-6870.herokuapp.com/arow-ronet.html

You can also browse or checkout the code on github at

http://github.com/adamhoward/arow

If someone could provide me with instructions on how to install the html and js files into a .NET project I will add them to the project page.

Not everything is fully functional but it should give you an idea of where the project is heading. Any and all feedback is appreciated. Especially feature requests. I have a long list of my own but no real priority assigned to them.

Enjoy.
--
Adam Howard

Jul 10, 2012 at 7:08 AM
Edited Jul 10, 2012 at 1:12 PM

Nice work!

Just played with it for a few minutes... it's still a little rough around the edges in places (I get "undefined" errors and some "java.lang.NullPointerException" exceptions when logging in), but thereafter it worked pretty well.
In terms of feature ideas, here are a few (I'm sure many duplicate your own list):
1. I couldn't immediately find the actions for an object, so I think they may need emphasising more.
2. I find it annoying that all windows appear in the middle, over the top of each other. Could you use a more intelligent algorithm?
3. I find the windows rather long and thin. Perhaps the collections could go off into a second column?
4. when a collection is opened, it creates a new window that is divorced from its owning object. If you moved the collections to one side, then the collection list instead could automatically open up in a div within the owning object (gracefully slide open?)
5. the reference properties labels are not in bold whereas the value properties are. At first it wasn't obvious to me that they were reference properties
6. in all cases the reference properties were after the value properties. I suspect that this isn't honouring the member ordering; they are typically intermixed
7. the pop up boxes are ugly and in a different style; only critical warnings/errors should be a pop-up box, informational messages (eg acknowledging a property update) should be in some sort of discrete status bar
8. although I can tab around the widgets, I couldn't see how to invoke the menu actions at the top. Also, there doesn't seem to be any way to tab to an object's action menu
9. titles are not updated even if the underlying properties are
10. if I have two views up of the same object, and update one, then the other is not updated
11. bug: search for a Customer using "Find Customer by Account Number". Enter "AW00023447". Hit OK with the mouse ... it works. But hit enter, and it doesn't work, the URL in the bar changes, and the app is then frozen
12. it'd be nice if you could factor out a little Javascript library for RO to allow other clients to reuse the underpinnings that you've developed, but with a different look-n-feel.
I was using the current Chrome (20.0.1132.47) on Windows for this testing.
Another thought: since I'm sure you're going to get lots of other good ideas from folks, plus your own list, perhaps you should add them into github as issues? I've just added #11 as your first github issue. Was hoping there'd be a vote button, but there doesn't seem to be.
Cheers
Dan
Jul 10, 2012 at 12:21 PM

Adam wrote: "If someone could provide me with instructions on how to install the html and js files into a .NET project I will add them to the project page."

It is very simple to try out Adam's Arow viewer with you own project on RO.NET.  Just go to http://github.com/adamhoward/arow and download the .zip file.  Copy the arow.html file, and the arow directory from within that .zip into your Run project (which generates the Restful Objects API) and then fire up and go to e.g.  

http://localhost:53176/arow.html

(replace with the localhost that your RO project fires up).

Jul 13, 2012 at 7:48 AM
Edited Jul 13, 2012 at 7:48 AM

Thanks Richard. I'll get those instructions added to the github page. 

And thanks Dan for the feedback. I think I agree with all of them and they have all been added to my Trello board for the project [1]. I'm very visual when it comes to task management so I don't think I could use github issues to track my progress. It's definitely a good way to handle incoming bugs though. 

I wanted to highlight a few of the points that I thought could use some discussion:

4. when a collection is opened, it creates a new window that is divorced from its owning object.
> If you moved the collections to one side, then the collection list instead could automatically open
> up in a div within the owning object (gracefully slide open?)

This would be an interesting experiment and I might try to make something like this work. This comment also immediately got me thinking about a zoomable user interface akin to Eagle Mode file browsing[2]. Although because objects are not strictly trees this could quickly become fractal :) 

> 9. titles are not updated even if the underlying properties are
> 10. if I have two views up of the same object, and update one, then the other is not updated

This is definitely something I want to do but I'm trying to figure out the best approach that balances keeping what's on the screen fresh against having to refresh every visible element whenever anything changes. For example, see this image [3]. I have these windows up on my screen and I change the project number (circled in blue.) The title of that window is easy enough to update because the response of submitting the property modification includes the new title of the project (project titles are equal to the project number.) But what about all of the other places circled in red? 99-03 in the project list on the left (1 object), Project: 99-03 in the budget window (Budget for 99-03), and 99-03 in the Project column of the invoices table (Invoices for 99-03)? Those could be made to point to the same central location to reference the project title. But what about the budget title? How would I know to update the budget title (budget titles are "Budget for " + project.title())?

 

> 12. it'd be nice if you could factor out a little Javascript library for RO to allow other clients to
> reuse the underpinnings that you've developed, but with a different look-n-feel.

So this is the thing I liked the most in Johan's code[4]. He had basically a complete javascript model for all of the different RestfulObjects representations. This is going to be a necessity to support the view synchronizations mentioned above. So I'm working now on taking that code and updating it for 1.0.0 and tweaking it to use outside of his UI project. An example of what I'm going for would be something like this:

var client = new RO.Client("/");
var  projectRepository = client.serviceByName("Projects");
var randomProject = projectRepository.actionByName("RandomProject").invoke();
randomProject.properties.projectNumber.update("12345");

I grabbed a copy of the Spiro viewer and I see that there is a similar model being created there. Perhaps we can compare notes as the viewers mature.

Thanks.
--
Adam 

[1] https://trello.com/board/arow/4ffb8a4180e91fc05e02dee5
[2] http://eaglemode.sourceforge.net/screenshots.html
[3] https://www.dropbox.com/s/6fvvh5udulvzpwq/arow-data-updates.jpg
[4] http://code.google.com/p/restfulobjects-js/ 

Jul 13, 2012 at 9:05 AM


On 13 July 2012 07:48, adamhoward <notifications@codeplex.com> wrote:

thanks Dan for the feedback. I think I agree with all of them and they have all been added to my Trello board for the project [1]. I'm very visual when it comes to task management so I don't think I could use github issues to track my progress. It's definitely a good way to handle incoming bugs though.


There are some tools out there [5] to give a similar feedback based directly from the github issues. Not that I've used any of em.



> 4. when a collection is opened, it creates a new window that is divorced from its owning object.
> If you moved the collections to one side, then the collection list instead could automatically open
> up in a div within the owning object (gracefully slide open?)

This would be an interesting experiment and I might try to make something like this work. This comment also immediately got me thinking about a zoomable user interface akin to Eagle Mode file browsing[2]. Although because objects are not strictly trees this could quickly become fractal :)

I remember Rick Mugridge (these days interested in FIT) demo'ing a ZUI about 10 years ago, that he had been getting his grad students to work on. Looked similar (though was written in Java, not JS). Unfortunately that never got open sourced.


> 9. titles are not updated even if the underlying properties are
> 10. if I have two views up of the same object, and update one, then the other is not updated
This is definitely something I want to do but I'm trying to figure out the best approach that balances keeping what's on the screen fresh against having to refresh every visible element whenever anything changes.

Ahh... sounds like a case of MVC. As you say later, Johan's work might make a good basis of this.


So this is the thing I liked the most in Johan's code[4]. He had basically a complete javascript model for all of the different RestfulObjects representations.

I grabbed a copy of the Spiro viewer and I see that there is a similar model being created there. Perhaps we can compare notes as the viewers mature.

Ideally this bit will converge from all the viewers into a separate open source project, the "RO Javascript AppLib" (ro-js-applib)?

Dan


Jul 13, 2012 at 10:16 AM

Dan wrote:  "I remember Rick Mugridge (these days interested in FIT) demo'ing a ZUI about 10 years ago, that he had been getting his grad students to work on. Looked similar (though was written in Java, not JS). Unfortunately that never got open sourced."

The resulting thesis (which contains screenshots) is available here:  http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.6588 

Rick demoed it to me many years ago. Personally I didn't really like the idea of the ZUI, but it was a pretty impressive piece of work.  Actually, Rick did several very impressive things with the early Naked Objects framework, including Emperor  -  a kind of DSL with a Naked Objects UI, for creating Naked Objects applications! It's a pity he got side-tracked onto something as worthy  (a euphemism for 'dull'?)  as Fit  ;-)

Jul 13, 2012 at 10:34 AM


On 13 July 2012 10:16, richardpawson <notifications@codeplex.com> wrote:

Actually, Rick did several very impressive things with the early Naked Objects framework, including Emperor - a kind of DSL with a Naked Objects UI, for creating Naked Objects applications!



We should point out the more contemporary work being done by Marcius Brandão in Brazil. They've built their own DSL and a Java framework that is also a naked objects implementation. I have a translation of their paper, but don't know if it's public domain; but there's also a slidedeck [1] that, while in Portugese, shows how their DSL works (slides 16, 18, 19)

Adding support for these annotations would be easy in either Isis or NO MVC, and could be exposed in the "extensions" json-prop in the RO layer.

Dan


Jul 13, 2012 at 3:03 PM
>>> 9. titles are not updated even if the underlying properties are
>>> 10. if I have two views up of the same object, and update one, then the other is not updated
>> This is definitely something I want to do but I'm trying to figure out the best approach that balances
>> keeping what's on the screen fresh against having to refresh every visible element whenever anything changes.
> Ahh... sounds like a case of MVC. As you say later, Johan's work might make a good basis of this.

I definitely think one of the new MV* javascript frameworks will end
up being used but even Johan's code using Backbone.js had to loop
through every current view and call view.refresh() after each form
submit. Maybe the refreshes could be limited to only those views which
represent objects returned in the "changed" list or objects who
reference the objects returned in the "changed" list. There must be
some upper bounds on how many dialogs/objects a user can deal with on
their screen at once (both in screen real estate and mental capacity.)
If we say that's 10 then every property change would result in one
PUT and at least 10 GETs. More if you are displaying object
collections as tables. It might be that is just what has to be done
but it seems like that would make the app very chatty. I might have to
dig into the DnD java code to see how it's handled there.

--
Adam
Jul 13, 2012 at 3:44 PM
On 13 July 2012 15:03, adamhoward <notifications@codeplex.com> wrote:

I'm trying to figure out the best approach that balances keeping what's on the screen fresh against having to refresh every visible element whenever anything changes.

I might have to
dig into the DnD java code to see how it's handled there.


There's this concept of an UpdateNotifier which returns the modified objects, serialized to some depth. In the remoting support (now removed), this list of objects would be returned within the result.

The RO spec doesn't currently define anything equivalent. I suppose it could define a new element that would hold a similar graph of changed objects. If so, I'd see this as an optional capability.

Or, an alternative idea might be for the spec to define a websocket channel against which clients could subscribe for all changed objects, either those modified by the current user, or by any other user. I like this idea more, myself. It should still be an optional capability for frameworks to support.

If you have specific thoughts on any of these ideas, then raise an issue in the github repo for the spec [1]

Dan