RE: Editing resources

On Sunday, November 02, 2014 8:02 PM, Kev Kirkland wrote:
> I understand what you're saying. My question is about how a Hydra
> client should behave when editing a resource. I want my version of the
> Hydra Client to behave in a different way to the official Hydra client
> [1]. Sorry if I didn't explain it very well before, I'll try to be
> clearer.
> 
> To reproduce the issue:
> 1.  go to the Hydra events demo [1] and click the 'Load' button
> 2.  notice that each member in the events collection only have "@id"
> and "@type" information (the member doesn't contain a full
> representation for the resource)
> 3.  click on the first event's "@id" attribute to open the Hydra
> operations dialog box
> 4.  select PUT from the drop down list
> 5.  notice that fields for 'name', 'description' and 'start_date' are
> blank, even though values are available for them (which you can confirm
> by doing a GET on the resource)
> 
> My question is - should the fields in the PUT form be blank? In my

The HydraConsole doesn't have any understanding of what operations mean since we removed the CRUD operations we predefined before (see ISSUE-11).


> version of the Hydra Client I would like the fields to be populated
> with the data for the event (by automatically doing a GET request for
> the resource).

You could tweak the HydraConsole to, e.g., understand http://schema.org/ReplaceAction and make the UI act as you described. I'd probably merge a PR doing so if you would file one ;-P


> I think the fields should be populated because:
> 
> 1.  a human user would want to see the current values to provide some
> context
> 2.  A user might want to correct a typo rather than retype every entry
> (possibly introducing more typos)
> 3.  a user might want to leave some values unchanged when they edit the
> resource
> 4.  a machine agent might use the Hydra Client to edit the data, for
> example you could write a machine agent to capitalise the first letter
> of every rdfs:label in the API across all resources. If the fields in
> the PUT request aren't populated with data then the agent wont work
> (this is a contrived example, my point is that we should consider non
> human users of the client as well as human users)
> 
> I hope that clarifies things, otherwise let me know.

Yeah, you always have to keep in mind though that it depends on what the client intends to/should do. We are not describing how user interfaces look like or behave. We just describe what consequences a specific HTTP request probably (it could fail for instance) has.


HTH,
Markus



> [1] http://www.markus-lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra/event-api/events/
> 
> On 2 November 2014 15:40, <tomasz@t-code.pl> wrote:
> Hi
> 
> comments inline
> 
> October 30 2014 11:35 AM, "Kev Kirkland" <kev@dataunity.org> wrote:
> > I've been looking at how to edit resources with Hydra.
> >
> > I don't think this has been implemented in the demos yet. For example if you go to the events list
> > demo [1] and choose the PUT operation for one of the events, the form's input boxes are blank
> > rather than having the current event's details filled in.
> >
> > I'm looking to put editing into my AngularJS Hydra client. To fill in the PUT form with the details
> > of the resource you are editing, do you do a GET request to the form's URL to get the
> > representation of the item you are editing then use it to populate the input boxes on the form? So
> > for the events demo would the sequence be:
> >
> > find an event to edit (e.g. /hydra/event-api/events/1)
> > choose the PUT operation for the event
> > do a GET request to fetch the resource's representation (e.g. GET hydra/event-api/events/1)
> >
> 
> I don't understand this order. What does the first step mean? How do you "find an event to edit"?
> 
In general RESTful services work by first retrieving a resource representation and then following links or invoking actions. Each subsequent resource retrieved is your application state. That resource's representation together with some metadata (Hydra fulfills that role in our case) lets you decide what > will be the next request.
> 
So, my point is that typically you would first get the resource and only then discover that a PUT is allowed. Otherwise you are making assumptions. Even if > you knew the URI, you don't have enough explicit information required to act upon it.
> 
> >
> > use the GET request's data to fill in the input boxes on the PUT form
> > submit the PUT request (with user's edits) to the url of the event (e.g.
> > /hydra/event-api/events/1)?
> >
> > Thanks,
> >
> > Kev
> >
> > [1]
> > http://www.markus-lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra/event-api/e
> > ents/
> >
> > --  www.dataunity.org twitter: @data_unity
> 
> 
> 
> 
> -- 
> www.dataunity.org
> twitter: @data_unity

Received on Tuesday, 4 November 2014 22:36:58 UTC