Re: Editing resources

Hi Tom,

Thanks for the comments, they make sense. I've put some notes inline:


> 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.
>
Yes, totally agree. The project started as a learning exercise so I didn't
develop tests alongside the code unfortunately. They should be in there.

Markus has kindly put up a copy of the 'events' API which will be a good
basis for an example.


> I've got some question and thoughts about using AngularJs with Hydra
>
> 1. Is the underlying processing of Hydra independent from the controllers
> etc?
>
I've tried to keep the Hydra processing out of the controllers because the
code is shared across multiple controllers. For example there's a service
called 'apiDocHelper' (line 344) which will find SupportedClasses and
SupportedProperties in the API Documentation. There's another service
called 'apiResources' which deals with fetching resources from the server
(line 512). These are all designed to be independent parts of the system.


> 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
>
I briefly looked at uiRouter, but I'm not really familiar with it. I
thought I'd try to go with a pure AngularJS solution first, but as things
get more complicated it might make sense to introduce uiRouter.

>
> 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.

Yes, sounds good (more on this below);


> Also nested states can be defined and handling hierarchical views should
> be simpiefied, wouldn't it?

I have tried to keep things simple initially because the Hypermedia process
is very simple and contained at each step through the API. In other words
the Hypermedia process isn't hierarchical as I see it (you are dealing with
one step at a time, even if that step is part of a tree). However I have
come up a scenario where hierarchical views might be handy.

I'd like to let people pursue paths through the Hydra API in a dialog box.
This means a user can have more than one path through the Hypermedia API
going at a time. The motivation is that they can edit a resource whilst
still keeping the original resource information in the background. This is
quite common in web applications, where you have a pop-up edit box. For
example in GMail you can have your email inbox state in the background, but
start a new 'Compose Email' process in a dialog box on top.

I wasn't really going to advertise this feature of the AngularJS console as
it might require some features outside of Hydra (for example getting API
processes to communicate, like asking a resource view to refresh when an
edit process is complete). Would be interesting to know if other people
think this will be useful for them. Sounds like uiRouter might possibly
help with this.


> 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?
>
Yes, that makes sense. I would prefer that state is based on the current
resource rather than encoding some Hydra information into the link url like
the console does at the moment. I remember I tried this originally but I
came up against some problems, I can't remember what the problem was, but
think it was something to do with tracking data between viewing a resource
and editing the resource with a form - you have to remember the state of
the previous resource before moving to the form view. I'm sure there's way
around the issue. It's all early stage code, so I'm sure we'll find better
ways like you suggest.


> 3. In what JsonLd form do you pass a resource's representation to the
> controller?
>
I'm not sure I understand which bit this refers to. However I store some
resource information in something called a 'pageItem'. This is a wrapper
around some API information which gets passed to the view/directives.

The pageItem wrapper brings together the resource state plus the Hydra
information (like which SupportedOperations are used). When the user clicks
an operation in the user interface the information in pageItem is used to
call the next behaviour in the controller. This will be a lot clearer when
there's a demo up I think. I'm sure there's lot of room to improve this
process.

Let me know if I haven't interpreted your question correctly.

Thanks for the comments. It might take me a while to reply to messages over
the next couple of weeks due to workload, but appreciate the input.

Thanks,

Kev