UPDATE
i worked with my form inputs and the Controller a bit, and i DO have
functioning saves working again (for the next ten minutes until it breaks
again). i'll describe what i had to do, and why i don't like it.
Form inputs:
Basically, i have to scrap the idea of the ORM carrying data to the pivot
table. i have my main inputs all named according to their Listings column.
For the data that will go to ListingsAttributes, i prefix the input with
'attributes.column':
<!-- 3 is the index position of the input group, 1 is the actual record ID
-->
<input name="attributes[3][attribute_id]" value="1" type="checkbox">
<input name="attributes[3][value]" type="text">
In the Controller:
$listing = $this->Listings->newEntity();
if ($this->request->is('post')) {
// Grab the 'attributes' data - arrays of attribute_id / value pairs
$attributeData = $this->request->data['attributes'];
// Can't leave the 'attributes' in the request data for the entity
patch, Listings save fails.
unset($this->request->data['attributes']);
// NOTE: NO 'association' key. Just a single save action.
$listing = $this->Listings->patchEntity($listing, $this->request->data);
// Save the link records one-by-one
foreach ($attributeData as $attrData) {
$attribute = $this->Listings->Attributes->get($attrData[
'attribute_id']);
$attribute->_joinData = new Entity(['value' => $attrData['value']]);
$this->Listings->Attributes->link($listing, [$attribute]);
}
}
Of course there's the redirect after everything succeeds & so on.
Why this is awful:
1. Absolutely NOT what's documented for this approach OR for the
supposedly easier ['associated' => ['Attributes._joinData']] i was
struggling with.
2. Cramming inputs into the form only to extract them to a separate data
set, unset them from the original, then loop through them for individual
save actions. This is not what i envisioned ORM sweetness to be.
3. Non-transactional - at any point, a save can fail and i get PART of
the data, and can't roll back to make the user try the entire transaction
over again. Instead, i'd have to have cleanup code in my *add* action to
sweep up behind a failed save.
4. i suppose i *could* do it in a manually-set transaction, but that
goes right back to defeating the purpose of the ORM.
Since there was someone on IRC also experiencing the same struggle i'm
having, i'll hang out there a while to see if markstory comes back around
to address it. It just baffles me that this particular data scenario does
NOT work.
He even seemed to concede that the task we are trying to accomplish isn't
directly accounted for in the test cases. One of the tests is for a
Create/Update on both sides of the association, which i think is clear by
now i'm NOT trying to do. The other test case he showed us retrieves an
existing Entity and does an Update with a Create/Update on the other end
and _joinData in between. When we explained we want to save only on ONE
side & the pivot, and leave the other end untouched, he agreed the tests
don't specifically account for that. So if i can catch him online,
hopefully we can sort out whether it's something i'm still doing wrong, or
the ORM, the Marshaler, or whatever.
Thanks again for the help. i'll follow up if i learn anything more.
On Friday, 13 March 2015 13:13:30 UTC-4, heavyKevy wrote:
>
> I believe that is your answer you were looking for...
> I missed it too.
>
> Thanks Jose for pointing that one out.
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.
