wimleers
Use Node Resource Back-end, instead of per-field
I ran into Crell on my way from the code sprint and we talked about whether it made sense to make a REST resource for updating single fields to support the Edit modules current approach to updating node information on edit field-by-field.
He had a few serious concerns about the field-level editing approach, starting with the fact that D8 likely will not support the ability to edit at the field level, and as such reworking the Spark code for D8 may require some substantial refactoring, not just swapping out the sync method.
He also pointed out that field level editing of nodes definitely complicates the issue of node revisioning, and may invalidate node versioning completely or create an extremely large number of revisions (having the same result). While neither of us are familiar enough with the FAPE module's inner workings to really evaluate it in this regard, it's hard to see how that problem could be solved.
I'd propose using POST calls to the node resource with only the changed properties specified, instead of field-level calling. As discussed at the REST API Design panel, POST should ignore any properties not included in a call, and this is the way that Services' node implementation works. In the case of a create, using a POST without the nid property specified would conform to REST standards and be supported by existing modules.
Using Services can get us form validation, though a custom resource would likely be needed to get the form elements (this could still use FAPE, though it might not have to).
This will still require some changes to backbone sync, since Backbone uses PUT for updates by default, and we'd need to change that to using POST w/ nid specified, but that's still "proper" REST and should be fairly low lift.
I will invite Crell to comment on this as well, as he has a better understanding of the likely D8 architecture than I.
Two quick remarks:
- now that we're using Create.js, in reality saving (and fetching!) works always with full VIE entities. This means the per-field saving is a feature of the custom Backbone.sync implementation @wimleers is writing to be Drupal 7 compatible, not something Edit imposes internally any longer
- The default Backbone.sync has a nice config option for using POST instead of PUT and DELETE: http://backbonejs.org/#Sync-emulateHTTP
emulateHTTP looks right on.
Re: field vs. node as server resource, I suppose my main question is whether field is easier on the D7 backend side, or may be more trouble than it's worth.
On Mon, Aug 27, 2012 at 1:18 PM, Henri Bergius [email protected]:
Two quick remarks:
now that we're using Create.js, in reality saving (and fetching!) works always with full VIE entities. This means the per-field saving is a feature of the custom Backbone.sync implementation @wimleershttps://github.com/wimleersis writing to be Drupal 7 compatible, not something Edit imposes internally any longer
The default Backbone.sync has a nice config option for using POST instead of PUT and DELETE: http://backbonejs.org/#Sync-emulateHTTP
— Reply to this email directly or view it on GitHubhttps://github.com/wimleers/edit-createjs/issues/1#issuecomment-8063075.
The main concern is that with the way Entity API is going in Drupal 8, there won't be a field-save operation. It simply won't exist. You'll have to save the entire node. Add in revisions, and saving after every field edit is going to, at best, bloat your database, and at worst royally expletive deleted your content moderation.
Plus, I disagree that immediate-save is good usability anyway, as then you have no undo command.
I really think the better approach is to queue up changes and send them all when the user clicks Save/Commit/Done/whatever. Whether we then send back a full node or a partial node, eh, I don't greatly care. If we use PUT it will have to be a full node, but I'm not sure off hand if PUT and revisions are strictly speaking compatible.
@Crell I think I remember @wimleers mentioning that the per-field save button is going away. The Storage widget is already keeping track of which entities (and their fields) have changed, and so it is mostly just UX decision how actual Backbone model save operations are triggered, and in what granularity (all changed entities, just one entity, just one property of entity).
Backbone itself only knows about entity and collection level sync, so the per-field saving was supposed to be a Drupal 7 -specific implementation.
@Crell The problem is that it is an absolute requirement to be able to make changes to a field, and immediately after stopping to edit that specific field, to have it rerendered as it would look if it were saved. If we are going to have that possibility in the API, then that's fine :)
As @bergie already said: thanks to Backbone, Edit's JS won't have to care whether the underlying layer is actually saving per-field, or per-entity. What matters is that the user can make small changes and immediately see the impact.
Fago is the person we want to talk to here. We need to loop him in.
Wim, what you're describing may require using the new TempStore, perhaps? Either way, with Entity-level storage and entity-level revisioning, for-reals saving individual fields rather than Entity-at-a-time is, I believe, simply not in the cards. I don't think there's any way we can get away from a "Save" button to commit all changes to an entity, even if there's been preview-like rendering before that.
@Crell, Fago joined the IKS Project recently, and I understand he has plans on working with JSON-LD. This means we should indeed talk ASAP and try to synchronise these efforts.
http://www.iks-project.eu/community/people/wolfgang-ziegler
Some more details on what Fago and Scor are doing: http://blog.iks-project.eu/enriching-drupals-content-with-apache-stanbol-3/