José
i appreciate your response. Please forgive my frustration, i'm *trying* to
learn what i'm doing wrong (and i do still believe i'm doing something
wrong, but can't figure out WHAT). Your comments make sense, and i was
originally working under those assumptions. However, the original approach
didn't work. i followed the documentation at
http://book.cakephp.org/3.0/en/orm/saving-data.html#saving-additional-data-to-the-joint-table
http://book.cakephp.org/3.0/en/views/helpers/form.html#associated-form-inputs
which are what gave me inputs and POST data matching exactly what the
documentation describes. But when feeding the POST into patchEntity, the
association data *disappears*.
i re-baked my models and the Controller, dealing almost entirely with the
automatic code (changing only what i needed for views/layouts - nothing
affecting data). It didn't work. The furthest i could get with that was the
Listing record, but the Listing entity never had the associated Attribute
data. The first time anything DID save to ListingsAttributes was with
Kevin's changes.
The only discrepancy i see is the documentation calling
$this->Students->newEntity($data, // POST data
['associated' => ['Courses._joinData']]);
while your comment below used
$this->Posts->patchEntity($post, $this->request->data,
['Tags._joinData']);
Leaving aside the object differences, is that options array correct?
i *was* using newEntity to create it directly from POST, as the
documentation does. The re-baked Controller switched it to patchEntity &
Kevin's changes did the same, so i went that way.
i've been calling
$this->Listings->patchEntity($listing, $this->request->data,
['associated' => ['Attributes._joinData']]);
i've tried to be very clear about what i was originally doing, and Kevin
had the same problem: no associated record saved. He was very helpful,
offering clear instructions for what he changed to get it to work, which is
where i am now. All the points i listed are from changes *he* had to make
to get the ListingsAttributes record to save. Only AFTER making the same
changes am i now seeing the ListingsAttributes record saved, but the `value`
from POST never makes it into the Listing Entity.
i will try again tonight, but i'm at a loss for what i can do differently.
Kevin's help is the only thing that has even *partially* worked so far, but
you're telling me that's doing it wrong. So what's left?
Thank you.
On Tuesday, 3 March 2015 10:13:53 UTC-5, José Lorenzo wrote:
>
>
>
> On Tuesday, March 3, 2015 at 2:43:55 PM UTC+1, Joe T. wrote:
>>
>>
>> 1. 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.
>
>>
>> 1. 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.
>
>>
>> 1. 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 [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.
