Re: Editing resources

Hi Kev

There's quite a lot of code so I haven't looked into details. However I like the general outlook! For starters it would be great to introduce some unit tests for the underlying processing of Hydra metadata. Also some examples for the base services would be nice.

I've got some question and thoughts about using AngularJs with Hydra

1. Is the underlying processing of Hydra independent from the controllers etc?

2. I ask the previous question because I see that you use ngRoute. I've been thinking that uiRouter may be a better fit. Here's how I think it could work. Please bear in mind that I don't mean any of this for a generic client but rather a tailored one.

A. Initial request must translate the $location to some resource URL
resource idntifier - $location mapping would be somehow mapped
full URIs could also be used for routing - this way the application could work with unanticipated URL patterns

B. Resource is retirieved and a $state is chosen based on the resource's representation
the simplest idea is to create states mapped to rdf classes. Also nested states can be defined and handling hierarchical views should be simpiefied, wouldn't it?

C. Whenever the user follows a Link of performs an Operation a new state is then again chosen based on the result resource's type.
I think that this approach is more suitable to REST where the client's state is tied to the current resource. 

Does this make sense? How do you think your work fits into my ideas?

3. In what JsonLd form do you pass a resource's representation to the controller?

@Cedric, @Markus - how do you guys find my ideas?

Regards,
Tom

November 7 2014 6:19 PM, "Kev Kirkland" <kev@dataunity.org> wrote:

> I've just dropped the latest version of my AngularJS Hydra client into GitHub:
> 
> https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js
> 
> The main code starts at line 120 (the code before this is part of an extension mechanism to
> override the default behaviour).
> 
> It works very well with my API(!), but probably wont work with other APIs just yet. I've listed the
> main issues on the Readme page [1]. The issues aren't major, I was aiming to fix them before
> releasing the project but I've got serious time issues at the moment.
> 
> Lots of the code is support code for things like RDF namespaces and reading JSON-LD. The
> controllers are probably the first thing to look at (line 769 for the 'item' controller, with the
> others following). There's a very brief overview of the methodology in the GitHub readme.
> 
> What would be a great help is if anyone has a copy of the Events demo API with CORs headers (or a
> similar demo API). It would be good to have something to test the client against other than my API,
> which isn't ready for public release yet. If someone has the code for a demo API could they chuck
> it up on a heroku instance (or something similar)?
> 
> Thanks,
> 
> Kev

Received on Saturday, 8 November 2014 20:19:20 UTC