Patch allows an implementing handler to act upon field change, e.g. act on hook_field_presave()
This patch is still not finished, as there are other operations that need to be invoked (all ops from _invoke_field), but I'm setting to needs review to see if this approach is acceptable.
My use case, is that OG can provide own handler with own field_validate| insert| update logic.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1343918-er-invoke-field-handler-5.patch | 3.49 KB | amitaibu |
| #4 | 1343918-er-invoke-field-handler-4.patch | 3.49 KB | amitaibu |
| #1 | 1343918-er-invoke-field-handler-1.patch | 2.3 KB | amitaibu |
| er-invoke-field-handler.patch | 1.4 KB | amitaibu |
Comments
Comment #1
amitaibuAdded insert/ update/ delete.
Comment #2
amitaibu@Damz, I've implemented this in OG7's new dev branch. Can you please let me know if it's an acceptable improvement?
Comment #3
damien tournoud commentedSo we have rewrote the Field API as a CTools plugin? :)
Yes, this is acceptable. I'm not a fan of the implementation, could we convert that into a single
call_user_func_array()? The signature of theentityreference_field_invoke_handler()scares me.Comment #4
amitaibuI've also added hook_field_load() -- My use case is here (although I'm not sure if it is indeed what OG will do in the end)
The patch doesn't work, because, well a bit embarrassing... but I didn't find how to pass the values by reference using call_user_func_array() :/ -- what am I missing there?
Comment #5
amitaibuOk, fixed the reference issue ;)
Comment #6
amitaibu> My use case is here (although I'm not sure if it is indeed what OG will do in the end)
Answering myself: It's actually looking pretty promising, so yes, hook_field_load() is also needed :)
Comment #8
amitaibuFixed in #1343854: Separate "Selection" and "behavior" to different plugins