| # |
Jul 15th 2017, 04:41 |
aro |
let me test that |
| # |
Jul 15th 2017, 04:41 |
 savant |
so I think when it json encodes, it decides it sees integers and reorders |
| # |
Jul 15th 2017, 04:41 |
aro |
i know that |
| # |
Jul 15th 2017, 04:41 |
savant |
php doesnt have any concept of ordered arrays if the keys are all integers |
| # |
Jul 15th 2017, 04:41 |
aro |
so i figured id try doing a data view using the template, so i added .json to my request url, and now i get 404 errors |
| # |
Jul 15th 2017, 04:40 |
aro |
instead of the way it appears in the php array |
| # |
Jul 15th 2017, 04:40 |
aro |
like ordered by key |
| # |
Jul 15th 2017, 04:40 |
aro |
it shows up in my json view as reordered |
| # |
Jul 15th 2017, 04:39 |
aro |
but when i do $this->set(compact('products')); $this->set('_serialized', ['products']); |
| # |
Jul 15th 2017, 04:39 |
aro |
which works great |
| # |
Jul 15th 2017, 04:39 |
aro |
well, i do a $this->Products->find('list')->order([my => 'asc'])->toArray(); |
| # |
Jul 15th 2017, 04:38 |
savant |
what do you mean by serialized list |
| # |
Jul 15th 2017, 04:38 |
savant |
you’re probably not sending all requests to php-fpm or php-fastcgi |
| # |
Jul 15th 2017, 04:38 |
aro |
do we need any specific config for nginx to make that work? |
| # |
Jul 15th 2017, 04:38 |
aro |
also when i send ajax requests to cake with the extension .json, i get 404 errors from nginx |
| # |
Jul 15th 2017, 04:17 |
aro |
it keeps ordering them by key |
| # |
Jul 15th 2017, 04:17 |
aro |
is there a way to get a serialized list from a find to be in order by value? |
| # |
Jul 15th 2017, 03:46 |
admad |
@jagspecx checkout muffin/webservice plugin |
| # |
Jul 15th 2017, 01:00 |
savant |
https://book.cakephp.org/3.0/en/core-libraries/httpclient.html |
| # |
Jul 15th 2017, 01:00 |
savant |
are you using the http client? |
| # |
Jul 15th 2017, 00:54 |
jagspecx |
Ok, I’ve been working on this all day and feel no closer than when I started - I’m trying to consume an external API/webservice in CakePHP 3 but I can’t find a clear example on which I can base my implementation. Can someone please point me to a good sample implementation? Or something in the Book I might have overlooked? I have to believe that I’m not the first person to need something like this. Thanks in advance! |
| # |
Jul 15th 2017, 00:04 |
ben |
:beers: |
| # |
Jul 14th 2017, 23:34 |
savant |
whatever works, ship it |
| # |
Jul 14th 2017, 23:34 |
savant |
but again, your business, your rules :slightly_smiling_face: |
| # |
Jul 14th 2017, 23:34 |
savant |
that seems to actually be the opposite of beneficial as it is introducing an extra layer of indirection and more work for the business |
| # |
Jul 14th 2017, 23:33 |
savant |
but I dont know what business/operational benefit there would be to using a new path for something that works fine as is, especially if replacing an existing system |
| # |
Jul 14th 2017, 23:33 |
savant |
I dont really feel like arguing the point, especially as you’re going to make the change as you see fit |
| # |
Jul 14th 2017, 23:32 |
slackebot |
business/operational benefit, but primarily to remain on a current framework release that's widely-adopted and well-documented. My point is that there are benefits to the conventions of frameworks like CakePHP, Laravel, Symfony, etc., but they come with some compromises that aren't necessarily in the best interest of every project. |
| # |
Jul 14th 2017, 23:32 |
ben |
On the broader topic of conventions, I think there are a range of reasonable opinions in the community. I also think we principally agree. There are clear benefits to any project in the full-adoption of many PHP frameworks such as RAD and a certain set of standards/conventions, but also some compromises. Mainly, with any active project of longevity (5+ years), a tight coupling between a project and a framework often portends substantial refactori |
| # |
Jul 14th 2017, 23:14 |
ben |
Thanks for your help @savant! |
| # |
Jul 14th 2017, 22:53 |
ben |
I agree there are clear benefits to conventions, which is why we've adopted a number of the PSRs put out by the PHP-FIG. Also, it's slightly less convoluted than it might seem since our legacy approach to "migrations" is a strictly-SQL approach. |
| # |
Jul 14th 2017, 22:44 |
savant |
and then you’re like “well which migration is old and which is phinx” |
| # |
Jul 14th 2017, 22:44 |
savant |
the other thing is that now you have some other folder |
| # |
Jul 14th 2017, 22:44 |
savant |
¯\_(ツ)_/¯ |
| # |
Jul 14th 2017, 22:42 |
ben |
I agree. We're just not *ready* for all the conventions. ;) |
| # |
Jul 14th 2017, 22:41 |
savant |
you’re free to make that change - and pull requests are welcome - but it seems of limited utility |
| # |
Jul 14th 2017, 22:41 |
savant |
but if you’re going to use cakephp/migrations, the point of cake is to have conventions |
| # |
Jul 14th 2017, 22:40 |
savant |
If you were going to use phinx directly, sure |
| # |
Jul 14th 2017, 22:40 |
savant |
just seems like busy work |
| # |
Jul 14th 2017, 22:38 |
ben |
Since migrations are a common are shared concept, it seems a bit more flexible, at least for us, to have a path for our migration files that's independent of any particular external solution, library, framework, etc. |
| # |
Jul 14th 2017, 22:35 |
savant |
seems like a hack for a legacy method that isnt going to be used further |