Is it possible to use this module in conjunction with editable views? Apparently EditableViews support editing entity metadata properties if a setter has been defined for the property. When using this feature of the EditableViews module in a Data Module view there properties drop down list is empty. I guess there's no setter callback defined?
If this is not currently possible I would appreciate some guidance of how to implement a custom solution allowing for in-line editing of Data Entity properties.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | editableviews-support-2662936-7.patch | 669 bytes | strainyy |
| #5 | editableviews-support-2662936-5.patch | 1.7 KB | strainyy |
| #3 | editableviews-support-2662936-3.patch | 2.14 KB | strainyy |
Comments
Comment #2
joachim commentedIt's probably just a case of defining a setter callback on the properties we declare for Data table fields.
In *most* cases, we can use 'entity_property_verbatim_set'.
Comment #3
strainyy commentedI've figured it out and produced a patch.
Just note that with the current patch all your column names in your table must be lower case, otherwise the entity properties can't be found!
Comment #4
joachim commentedThanks for the patch. A few things I'm not sure about though:
This belongs in Data Entity module, not here, as Data tables are only entity types if Data Entity sets them up.
Are you sure this is in the right hook? I've looked at Entity module, and I'm pretty sure this belongs in hook_entity_info().
Also, are you sure we need this? Look at entity_save() -- we can get by without this if we specify a controller implementing EntityAPIControllerInterface, which our controller does.
Please avoid changing whitespace in patches!
Comment #5
strainyy commentedjoachim, thanks for reviewing!
Apologies for the patch cleanliness - I'm a relatively new contributor.
Please review the updated patch. Hopefully it addresses most of the issues you raised above.
For the second issue you raised around using entity_save instead of the custom callback, that doesn't seem to work as you need to pass "entity_type" as a parameter into entity_save. Whatever function you pass into the 'save callback' argument of hook_entity_info() only receives the particular entity being saved.
Comment #6
joachim commented> For the second issue you raised around using entity_save instead of the custom callback, that doesn't seem to work as you need to pass "entity_type" as a parameter into entity_save. Whatever function you pass into the 'save callback' argument of hook_entity_info() only receives the particular entity being saved.
I don't really follow what you mean.
entity_save() is *always* a correct way to save an entity.
This is the code for entity_save():
So that tries several things:
1. if the entity class has a save method, it calls that
2. if the entity info has a save callback, it calls that
3. if the entity controller class implements the EntityAPIControllerInterface interface, then it calls save() on the controller.
Option 3 is the same as the code you've put in your save callback. So with your code, option 2 happens, and then the controller save() is called. Without your save callback, the controller save() is called. Same thing, less code :)
Comment #7
strainyy commentedAh! I get you now. Indeed, I've tested it without defining a 'save callback' argument and it everything's fine and dandy.
Might have experienced the magic of drush cc and conflated that with adding the 'save callback' argument...
In any case, I've attached the small code change needed as a patch for your review.
Thanks again joachim :)
Comment #8
strainyy commentedComment #9
ar-jan commentedThanks for the patch, it works nicely.
Comment #11
joachim commented@ar-jan: feel free to mark issues as RTBC when you review them.
Thanks everyone! Committed, and I'll make a new release soon.