-
-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add symfony request factory in sonata runtime #1739
Add symfony request factory in sonata runtime #1739
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this wasn't needed before the runtime then ?
see my comment. initial MR was the right strategy. This side effect was introduced by skiping RequestFactory in the runtime and using directly SiteRequest::createFromGlobals() |
it doesn't make sense works with |
924cab2
to
90891f8
Compare
@@ -27,6 +28,21 @@ public function getRunner(?object $application): RunnerInterface | |||
return parent::getRunner($application); | |||
} | |||
|
|||
Request::setFactory( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok here we go, it was the reason!
into the RequestFactory, it was calling this code.
I don't know why they were adding this. does it create a main request? or does it create a new request? I am not sure. But the thing is: it solves the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok here we go, it was the reason!
into the RequestFactory, it was calling this code.
I don't know why they were adding this. does it create a main request? or does it create a new request? I am not sure. But the thing is: it solves the issue.
yes the initial goal was to override the main request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you have any idea why do we need to do this?
Well it is the same behaviour of RequestFactory, my only point here is, we don't know why do we need this.
why do we need to override the main request 😢 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by the way issue is fixed and no extra params is needed. So this should be accepted to be merged
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for your information, it was an implementation from Symfony 2 🤯
2b70f81#diff-2d4fd4a3aac457940ec248d6e8421c65f88a2fc4035a3494416b29826bac53e5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by the way issue is fixed and no extra params is needed. So this should be accepted to be merged
yeah I know, I just want to know if we should add this or check if it is a main request on event.
because after this be released, I guess we can't just remove it, probably we need to keep some BC :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer the mainRequest check, but if subrequest is used and if it is, may be siteRequest is needed. Could this Request::setFactory thing coould be deprecated for the 5.x release maybe ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer the mainRequest
me too, the current approach sounds like workaround, check the main request is more common to see in symfony's doc
Can we have release asap? |
you can still keep using the old implementation until we release it. But I guess it won't take too much time, I just want to hear @VincentLanglet opinion about it. |
I dont know a lot about this bundle especially the legacy code. I trust you about the fact that the solution is working. The more code we can stop to use and deprecate, the better it is. So if the mainrequest check solve the issue and avoid BC break, it's great. |
it is more of an hassle to remove runtime than update this bundle :) |
Then let's check if it is main request on event, My felling is when he introduced this feature, he needs to have to be able pass the correct Request here $response = $kernel->handle($request); But as we are using runtime, it will be done automatically. how tests was written make me believe this he checks if it is SiteRequest or Request to pass to then let's check on event, in case it doesn't work, I can open a new PR doing the old way. |
It depends ; you dont know the review process, the release process, when I'll have a computer in front of me soon. Downgrading take you time. A new release take my time. I think Im already pretty quick in general. It's never nice to hear "asap". |
really quickly btw 😄 |
Use this in your index.php. Be aware that the main issue was 1 year old. I think you can wait for few hours/days. |
if you check the last commit I was using the old implementation Request::create, But we decided to check if it is main quest into the HostPath requests for more information check the descussion on this pr: sonata-project#1739 Note: use this approach was a try to remove a strange implementation that is not clear how it works. But there isn't other reason, it was just to try to use more symfony's example. Note 2: In case you know why Request::create is needed, please open a issue or document this somewhere.
e36521b
to
90891f8
Compare
I tried 😄 But there are some tests doing some stuffs with sub requests, then I will keep this implementation. in the future if someone wants to do something with sub request, then we could have this more documented. it was the errors using check into the event.
|
note to my self: don't use "asap" even if I mean well and meant that take the time you need. |
What I really meant was that current latest version is broken so it would be nice to have new release. I can imagine that asap can some point come out as a curse word but that was not what I meant. |
Current release do not break your app, it brings you the ability to use the new symfony way. So in the meantime use the old way that works for years :) i guess few hours to fix this is far away from what 've seen in my past jobs where new feature fix have to wait for ... the next two sprints (i've seen this yes... lol) |
Sure, but:
I let @eerison @GeraudBourdin discuss about the right approach, and I invite you @haivala to help about it if you want a quicker release. The sooner you all agree on the right solution, the sooner the PR can be merged/released. @eerison To me it's currently not clear if we should change the runtime or add a |
the right
th right decision should be to keep the Request::setFactory in the runtime. Not the nicest, but the securiest for old apps. |
So to merge the current state of this PR ? @haivala does it fix your issue ? |
you mean that subrequest check break tests ? |
yes it does |
Yep |
@VincentLanglet, change the runtime is the correct one, because there are some tests checking sub requests, then they expect that sub request works, page bundle is doing something with this sub request. then this PR is with the correct code to merge. |
Thanks |
Add symfony request factory into sonata runtime
I am targeting this branch, because runtime is released on 4.x.
Closes #1738.
Changelog
To do
Tests
in theory just main request should be handled by This runtime, But should be good someone else give me a hint that it is working as expected.
@haivala @GeraudBourdin @tdumalin