| # |
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: |
| # |
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? |