# |
Jan 24th 2019, 21:20 |
royalty |
pc-world, are you using cakephp3? |
# |
Jan 24th 2019, 21:14 |
pc-world |
*s $this->FormHelper->create($entity) |
# |
Jan 24th 2019, 21:13 |
pc-world |
royalty: That's what I originally thought, but it's more of a general issue, see my previous message. It also happens without relations. If I change $entity->someAttribute = $newVal, and in the view pass it as $this->FormHelper->($entity), it ignores that I changed someAttribute because it only fetches from the request data. |
# |
Jan 24th 2019, 21:04 |
royalty |
pc-world, are you having issue with hasMany indexing? |
# |
Jan 24th 2019, 21:04 |
pc-world |
royalty: I think what you first wrote is true. However in my edit() action, I get the entity from $entity = $table->get($id) and use $table->patchEntity($requestData), and then modify said entity and pass it to FormHelper::create(). However FormHelper completely ignores my changes to $entity, as it gets all values from request data instead. |
# |
Jan 24th 2019, 21:02 |
royalty |
that is actually done via entity i think |
# |
Jan 24th 2019, 21:02 |
royalty |
oh wait |
# |
Jan 24th 2019, 21:01 |
royalty |
pc-world, formhelper uses request data to populate the data just entered |
# |
Jan 24th 2019, 20:52 |
pc-world |
The reason I don't understand is that as I'm passing the entity to Form->create() in the first place, I don't see why it should look at request data at all. |
# |
Jan 24th 2019, 20:48 |
pc-world |
(btw the slack bot seems to have reversed the order of my messages from 2 hours ago) |
# |
Jan 24th 2019, 20:48 |
pc-world |
Why is there no option to ignore request data, should there be one? |
# |
Jan 24th 2019, 20:48 |
pc-world |
However I don't understand: Why does it prefer request data over the entity itself, shouldn't it be the other way round? |
# |
Jan 24th 2019, 20:47 |
pc-world |
I've pinned my problem down to https://github.com/cakephp/cakephp/blob/d2bd61dbe40ec9db28057bc7e5004703452568e6/src/View/Helper/FormHelper.php#L2962 and https://github.com/cakephp/cakephp/blob/d2bd61dbe40ec9db28057bc7e5004703452568e6/src/View/Form/EntityContext.php#L238 |
# |
Jan 24th 2019, 19:48 |
slackebot1 |
<flashios09> |
# |
Jan 24th 2019, 19:47 |
flashios09 |
i found it, it’s on packagist :slightly_smiling_face: |
# |
Jan 24th 2019, 19:47 |
admad |
`4.x` |
# |
Jan 24th 2019, 19:46 |
flashios09 |
last question @admad in the github repo there is no *4.x-dev* branch, from where *composer* get the source code ? |
# |
Jan 24th 2019, 19:44 |
admad |
better with it |
# |
Jan 24th 2019, 19:43 |
flashios09 |
without prefer-dist flag ? |
# |
Jan 24th 2019, 19:39 |
admad |
use 4.x branch of cakephp/app. `composer create-project cakephp/app:4.x-dev` |
# |
Jan 24th 2019, 19:32 |
flashios09 |
how can i create a new app using the 4.x github branch ? |
# |
Jan 24th 2019, 19:31 |
flashios09 |
i want to play a little bit with cake4(i know there isn’t a release yet) |
# |
Jan 24th 2019, 19:30 |
flashios09 |
hi |
# |
Jan 24th 2019, 18:31 |
pc-world |
To workaround that issue, I need to modify the request body directly with $this->setRequest(), and reindex the associated array with array_values(), which is quite cumbersome. |
# |
Jan 24th 2019, 18:31 |
pc-world |
Then I remove the associated entity whose delete button was pressed from the main entity's association array. Now I don't want to save to the database yet, but reload the form again. However when the view is displayed again and I create form controls with e.g. 'associated.3.id', CakePHP messes up the indices and displays the old request body data, and ignores my changes to the entity that I passed to Form->create(). |
# |
Jan 24th 2019, 18:31 |
pc-world |
Is it a feature or a bug that for populating form values, FormHelper seems to prefer request body data over the actual entities? E.g. I have a form that displays hasMany relations with a delete button (and <input>s) on each. When the delete button is pressed, I use patchEntity with the request body (as you normally do in an edit() action). |
# |
Jan 24th 2019, 17:49 |
aro |
haha |
# |
Jan 24th 2019, 17:49 |
jeremyharris |
welcome back :) |
# |
Jan 24th 2019, 17:48 |
aro |
i havent done any php coding in like 7 weeks |
# |
Jan 24th 2019, 17:48 |
aro |
cool |
# |
Jan 24th 2019, 17:47 |
jeremyharris |
https://github.com/cakephp/cakephp/wiki |
# |
Jan 24th 2019, 17:47 |
aro |
where do i find that |
# |
Jan 24th 2019, 17:47 |
jeremyharris |
there is a roadmap though which might give you an inclination |
# |
Jan 24th 2019, 17:47 |
aro |
arrrrr ok |
# |
Jan 24th 2019, 17:47 |
jeremyharris |
releases don’t generally have a release date since all work is voluntary, it’d be almost impossible to set one :slightly_smiling_face: |
# |
Jan 24th 2019, 17:46 |
aro |
on that note, is there an estimated release date? |
# |
Jan 24th 2019, 17:45 |
adsc |
yeah, thx, i upgraded the vagrant box to xenial64 and now it works with php7 |
# |
Jan 24th 2019, 17:45 |
aro |
see, that would require going to github, logging in, clicking on cake, switching to tags, finding the appropriate branch/tag, go to it, and then seeing if there was any recent activity on said branch/tag. I was right here in slack, so it was much easier, and less effort - to simply type 'is there going to be a cake4'. So that was the approach i opted for! |
# |
Jan 24th 2019, 17:43 |
dereuromark |
if you kept track of the 4.x branch you would even have found the answer yourself. |
# |
Jan 24th 2019, 17:43 |
dereuromark |
aro: what kind of question is this? the answer would logically always be yes. |
# |
Jan 24th 2019, 17:42 |
dereuromark |
or at least latest 2.x, never use an outdated minor here |