On Tuesday, March 3, 2015 at 2:43:55 PM UTC+1, Joe T. wrote:
- Had to add `id` to the Attributes $_accessible field array (as described by heavyKevy in a post above). If making foreign table IDs available for a joint table is necessary, why isn't the bake process doing that when it analyzes the foreign key structure?
It is not needed, unless you want to do everything manual. The usual workflow where making this column accessible is not needed is when you have a code like the following
$post = $this->Posts->get(1, ['associated' => ['Tags']]);
$this->set(compact($post));
The $post will contain its tags with their '_joinData' (including the id). Having the id in the result is important when you render the form:
$this->From->input('tags.0.id);
$this->From->input('tags.0._joinData.another_column');
Based on the id of the tag, the data that was modified will be matched when you do the patch entity:
$post = $this->Posts->patchEntity($post, $this->request->data, ['Tags._joinData']);
There are numerous tests and other apps doing this successfully, as the other person that tried to help you showed.
- Manually setting join data dirty after the entity patch: $listing->dirty('attributes._
joinData', true); - The documentation's examples for doing this are when you manually set entity data outside an entity-related call. patchEntity implies there will be dirty data, so it should handle it internally. Besides, when it comes to editing & i go to patch the existing entity with the POST data, maybe the _joinData is unaltered, and therefore manually setting it dirty is incorrect. i can't make assumptions with the POST data on what's dirty or not. That, to me, is exactly what patchEntity is for. However, i haven't even managed to get the joint record to save without all the modifications described in Kevin's previous post.
This is not true, patchEntity will mark the property as dirty if it changed in any way. If you are certain (or very suspicious) it is not working the way it should, please open a ticket so the core team can take a look at it.
- In the ListingsAttributesTable validation, it doesn't seem correct that allowEmpty for the two foreign IDs should be required to save the data, but it doesn't seem to work otherwise. In fact, if either of those IDs is empty for the joint table, validation should fail, but these validations will permit it.
Those columns are going to be set automatically for you, so it makes no sense to have validation for them. Instead, use the rule system if you want to enforce some validation for foreign keys: http://book.cakephp.org/3.0/en/orm/saving-data.html#foreign-key-rules
And none of that explains why, after following the documentation examples & Kevin's gracious effort to help me out, why the `listings_attributes.value` column still doesn't receive the _joinData.value POST data...
Is "value" for the entity resenting the joinData accessible? Dos it pass its validation?
Like Us on FaceBook https://www.facebook.com/CakePHP
Find us on Twitter http://twitter.com/CakePHP
---
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cake-php+unsubscribe@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment