Closed gregturn closed 9 years ago
This is a really good idea.
Can you include a complete example for reference?
Does it handle nested attributes? Suppose my post needs to be:
"person" : {
"first_name" : "Josh",
"last_name" : "Cohen"
}
thinking about this, another approach is just to let people specify a customPostForm
which is a Backbone.View
that takes an options object that includes the properties of the link (ie. the link relation url and the target url of the link as well)
CustomPostForm = Backbone.View.extend({
initialize: function(opts) {
this.link_rel_href = opts.link_rel_href;
},
render: function() {
var self = this;
http_get(this.link_rel_href, function(response) {
self.$el.html(this.template({ form_params: response.form_params }));
});
}
// template: _.template( etc...
// etc, etc.
});
HAL.customPostForm = CustomPostForm;
Here is my example, (which hasn't been updated to match the new function names yet in this PR) => https://github.com/gregturn/hal-browser/blob/alps/js/custom.js#L5-L48
I have an ALPS document available from the same place as my RESTful service, so most of the code involves doing another ajax call, and then using JSONPath to create an array of values => ["firstName", "lastName"].
Then, I use it in a different template => https://github.com/gregturn/hal-browser/blob/alps/browser.html#L183-L196
This variant of the template swaps out the Body textarea, and instead iterates over ["firstName", "lastName"] to generate an array of fields.
Finally, my extraction code just uses jQuery to pull out the values, assembled a JSON object, and stringify them.
@mikekelly An important thing I want to get in here is having not only the href of the link, but also the name of the rel. There is much metadata invested in rel names for Spring Data REST.
I have an ALPS document available from the same place as my RESTful service, so most of the code involves doing another ajax call, and then using JSONPath to create an array of values => ["firstName", "lastName"].
This is my concern. I think an array-of-fields interface here is not general enough. The relation URL may have a complex schema document specifying types of input, value ranges, enums, etc.
This is what led to my above proposal; it seems like this could me modelled as a custom view that can be injected.
See #66 for my updated version. @mikekelly based on your suggestion of creating an alternative Backbone view, I found that approach much simpler and less invasive. Hopefully we can push this through quicker.
This patch provides the means to inject a different non-GET dialog. The default dialog requires useres to type in a JSON document for POST support, requiring the user to know what is required. By offering an extension, developers can code a more intelligent pop-up based upon alternative metadata not supplied by this module.
After this is merged, and I can use this in my own project, I am happy to update the documentation with a polished example of using this extension.
Resolves #63