| # |
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 |
| # |
Jul 14th 2017, 22:34 |
savant |
might be easier to just move to the new solution from now on? |
| # |
Jul 14th 2017, 22:34 |
ben |
We prefer to keep them all together, and it's not such a "nested" path within our projects directory structure. |
| # |
Jul 14th 2017, 22:33 |
ben |
Yes, we have an existing path for migrations in our project with existing migrations, although not created using CakePHP's migration solution. |
| # |
Jul 14th 2017, 22:30 |
savant |
is there a reason you want it at another path? |
| # |
Jul 14th 2017, 22:30 |
ben |
That's it. Thanks, @savant. I see we can probably roll our own customized copy/version of method getOperationsPath() in this trait definition to make it happen. |
| # |
Jul 14th 2017, 22:23 |
savant |
does that answer help, @ben? |
| # |
Jul 14th 2017, 22:23 |
savant |
because it gets tricky with plugins |
| # |
Jul 14th 2017, 22:23 |
savant |
not sure there is an easy way to override this |
| # |
Jul 14th 2017, 22:23 |
savant |
https://github.com/cakephp/migrations/blob/1353d08cedfcde83fe4c1e493a977b62907439ef/src/Util/UtilTrait.php#L54 |
| # |
Jul 14th 2017, 22:22 |
savant |
yeah i think its in --source |
| # |
Jul 14th 2017, 22:20 |
savant |
let me check |
| # |
Jul 14th 2017, 22:20 |
savant |
we might hardcode the path, either within cakephp or in phinx itself |
| # |
Jul 14th 2017, 22:19 |
savant |
@ben not sure its configurable |
| # |
Jul 14th 2017, 22:17 |
ben |
We've done some digging through the code and docs, but it wasn't readily apparent. |
| # |
Jul 14th 2017, 21:57 |
slackebot |
"migrations" command issued)? If so, in what file(s) or where is it configured? |
| # |
Jul 14th 2017, 21:57 |
ben |
We're considering adopting CakePHP's migrations, especially because of its simple and powerful snapshot and DIFF feature implementation (i.e. simple compared the Doctrine), but would like to configure a custom path/location for the migration [class] files so they're created/maintained in another path within our project's directory structure. Is this configurable in a persistent manner (i.e. other than by specifying the "--source" option with each |
| # |
Jul 14th 2017, 21:56 |
ben |
I asked this earlier today, but the question didn't attract much attention, so I'm trying again: |