| # |
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: |
| # |
Jul 14th 2017, 21:20 |
phantomwatson |
@maymeow , what do you mean by it doesn't work? Your line with `toString()` doesn't appear to be doing anything with the string it generates. |
| # |
Jul 14th 2017, 20:31 |
maymeow |
can i pass array of objects to view template? For example `$log`and if i want to get items i doing it like this ``` foreach ($log as $item) { $item->getAuthor()->toString()); ``` but in templates it doesnt work... |
| # |
Jul 14th 2017, 20:20 |
savant |
markstory^ |
| # |
Jul 14th 2017, 20:19 |
phantomwatson |
It's been awhile since I've submitted a pull request. Is it preferred that they be pointed at new feature branches, development, or master? I'm looking to fix an old codesniffer bug. |
| # |
Jul 14th 2017, 19:43 |
sturm |
Oh? Hmmm… |
| # |
Jul 14th 2017, 19:40 |
admad |
And it's free :slightly_smiling_face: |
| # |
Jul 14th 2017, 19:40 |
admad |
@sturm eclipse pdt also shows you similar info |
| # |
Jul 14th 2017, 18:50 |
siran |
@sturm I wish they had a community edition... but at least there's a 'personal' $8.90/month license `https://www.jetbrains.com/phpstorm/buy/#edition=personal ` |
| # |
Jul 14th 2017, 18:48 |
cleptric |
No, the getters work the same as the old ones :slightly_smiling_face: The `getBody()` method is part of the `MessageInterface` so it just returns the stream object now. IIRC, you could just (string) typecast them to get the content |
| # |
Jul 14th 2017, 18:43 |
siran |
@cleptric you mean `getBody()`? what does inmutable means here? |
| # |
Jul 14th 2017, 18:33 |
cleptric |
@siran The new request/response methods handle your object in a immutable way |