-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Profiler] Ajax #3340
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
[Profiler] Ajax #3340
Conversation
@vicb please rebase |
@@ -53,6 +55,7 @@ public function panelAction($token) | |||
'panel' => $panel, | |||
'page' => $page, | |||
'templates' => $this->getTemplates($profiler), | |||
'isajax' => $request->isXmlHttpRequest() |
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.
please use a camel cased name: isAjax
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.
@vicb this has not been fixed
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.
it has been during my forced push: https://github.com/symfony/symfony/pull/3340/files#L1R59
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.
ah, you changed it in the controller only, not in the templates
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.
It was hard to refrain myself from doing this but the CS seem different there collector.calledlisteners
, collector.notcalledlisteners
, ...
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.
really ? We use lowercased names in Twig everywhere instead of respecting the case ? @fabpot ?
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.
My personal preference would be to rename this to is_ajax
.
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.
ah yeah, the Twig official CS are about using underscores.
@vicb just FYI, this conflicts with master so you will need to rebased it before it can be merged. Otherwise, what are the remaining points ? |
I am still wondering if the second commit is a good idea or not ? |
@stof isn't the branch based on the latest master ? |
Well, github tells me it cannot be merged automatically. so either there is a conflict, either their conflict detection failed last time you pushed. |
I did fail. |
I'm -1 on the second commit. |
Thanks all for the feedback. @fabpot ready ! |
Well I did revert the use of " What I mean is that |
btw @fabpot it makes me wonder if underscored variable names is a good idea, this will force us to mix (i.e. |
I still prefer |
At a larger scale how do fix the inconsistency described in my previous message ?
|
@vicb we also use underscores for variables used in the form themes. the official Twig CS are basically the one used by Sf2 in the form theme |
I don't see any inconsistencies here. One a variable name and the other is a method call/property name. So, my vote is a don't fix. |
I agree but then we loose one advertised benefit a twig: "Easy to learn: The syntax is easy to learn and has been optimized to allow web designers to get their job done fast without getting in their way". The designers should now be aware of the underlying implementation (i.e. Am I dealing with a variable or a function ?) Edit: race condition here... I agree with @stof |
@vicb they see that |
variables and functions are underscored. |
I think that the beauty of Twig comes from the fact that designers do not have to wonder if "something" is an array / an object / a variable / a method / a property. |
@fabpot would you mind if I open a PR against twig to check for existence of |
ready ! |
The problem is that the |
Commits ------- ed028d5 [WebProfilerBundle] Made is_ajax available to the view when rendering panels Discussion ---------- [Profiler] Ajax The first commit should be merged as `app` is not always accessible in the twig template due to the ways the templating system is used. Then there is currently no way to check if we are dealing with an ajax request in the view. The second commit use ajax to load the panels. This should make the interface more responsive as you don't have to load the layout each time + the panels are cached. Loading via AJAX would also work if your panel does not extend the ajax layout (legacy support) - this would be less efficient though as you would load the layout and filter it out afterwards. I am not sure if the second commit is worth merging, maybe it is useless ? --------------------------------------------------------------------------- by stof at 2012-02-12T20:40:16Z @vicb please rebase --------------------------------------------------------------------------- by stof at 2012-02-13T17:48:48Z @vicb just FYI, this conflicts with master so you will need to rebased it before it can be merged. Otherwise, what are the remaining points ? --------------------------------------------------------------------------- by vicb at 2012-02-13T17:57:27Z I am still wondering if the second commit is a good idea or not ? --------------------------------------------------------------------------- by vicb at 2012-02-13T18:28:17Z @stof isn't the branch based on the latest master ? --------------------------------------------------------------------------- by stof at 2012-02-13T19:32:52Z Well, github tells me it cannot be merged automatically. so either there is a conflict, either their conflict detection failed last time you pushed. --------------------------------------------------------------------------- by vicb at 2012-02-13T22:20:06Z I did fail. Should be ok now. --------------------------------------------------------------------------- by fabpot at 2012-02-14T23:27:08Z I'm -1 on the second commit. --------------------------------------------------------------------------- by vicb at 2012-02-15T07:44:25Z Thanks all for the feedback. @fabpot ready ! --------------------------------------------------------------------------- by stof at 2012-02-15T07:46:53Z @vicb not ready: you reverted all use of ``is_ajax`` in the templates (and you did not renamed it to the underscored name preferred by @fabpot) --------------------------------------------------------------------------- by vicb at 2012-02-15T07:54:30Z Well I did revert the use of "`isajax`" (prefer not to mix CS here, the scope of this PR is not to fix CS) because it is not used (this should be applied to the Doctrine profiler). _What I mean is that `isajax` in all the Sf templates w/o the associated js is useless, basically all or nothing_ --------------------------------------------------------------------------- by vicb at 2012-02-15T08:26:41Z btw @fabpot it makes me wonder if underscored variable names is a good idea, this will force us to mix (i.e. `is_ajax` vs `request.isxmlhttprequest`). What do you think ? --------------------------------------------------------------------------- by fabpot at 2012-02-15T10:09:20Z I still prefer `is_ajax` as it makes things more readable. --------------------------------------------------------------------------- by vicb at 2012-02-15T10:16:13Z At a larger scale how do fix the inconsistency described in my previous message ? Options are: * fix twig cs * create twig cs specific to sf2 * don't fix (= keep & live with some inconsistency) --------------------------------------------------------------------------- by stof at 2012-02-15T10:22:13Z @vicb we also use underscores for variables used in the form themes. the official Twig CS are basically the one used by Sf2 in the form theme --------------------------------------------------------------------------- by fabpot at 2012-02-15T10:24:46Z I don't see any inconsistencies here. One a variable name and the other is a method call/property name. So, my vote is a don't fix. --------------------------------------------------------------------------- by vicb at 2012-02-15T10:28:53Z I agree but then we loose one advertised benefit a twig: _"Easy to learn: The syntax is easy to learn and has been optimized to allow web designers to get their job done fast without getting in their way"_. The designers should now be aware of the underlying implementation (i.e. Am I dealing with a variable or a function ?) Edit: race condition here... I agree with @stof --------------------------------------------------------------------------- by stof at 2012-02-15T10:45:49Z @vicb they see that ``isXmlHttpRequest`` is not a variable. They are accessing it on the ``request`` variable (well, recurse here to reach the variable) --------------------------------------------------------------------------- by fabpot at 2012-02-15T10:46:57Z variables and functions are underscored. --------------------------------------------------------------------------- by vicb at 2012-02-15T10:51:28Z I think that the beauty of Twig comes from the fact that designers do not have to wonder if "something" is an array / an object / a variable / a method / a property. But never mind, I'll update the PR. --- FF7F ------------------------------------------------------------------------ by vicb at 2012-02-15T10:55:06Z @fabpot would you mind if I open a PR against twig to check for existence of `collector::getNotCalledListeners()` when a designer writes `collector.not_called_listeners`, then we are all happy ? --------------------------------------------------------------------------- by vicb at 2012-02-15T11:21:55Z ready ! --------------------------------------------------------------------------- by fabpot at 2012-02-15T11:31:50Z The problem is that the `Twig_Template::getAttribute()` is already the bottleneck
@fabpot I understand and as I am not a dsesigner I can leave with the current CS. |
Commits ------- ed028d5 [WebProfilerBundle] Made is_ajax available to the view when rendering panels Discussion ---------- [Profiler] Ajax The first commit should be merged as `app` is not always accessible in the twig template due to the ways the templating system is used. Then there is currently no way to check if we are dealing with an ajax request in the view. The second commit use ajax to load the panels. This should make the interface more responsive as you don't have to load the layout each time + the panels are cached. Loading via AJAX would also work if your panel does not extend the ajax layout (legacy support) - this would be less efficient though as you would load the layout and filter it out afterwards. I am not sure if the second commit is worth merging, maybe it is useless ? --------------------------------------------------------------------------- by stof at 2012-02-12T20:40:16Z @vicb please rebase --------------------------------------------------------------------------- by stof at 2012-02-13T17:48:48Z @vicb just FYI, this conflicts with master so you will need to rebased it before it can be merged. Otherwise, what are the remaining points ? --------------------------------------------------------------------------- by vicb at 2012-02-13T17:57:27Z I am still wondering if the second commit is a good idea or not ? --------------------------------------------------------------------------- by vicb at 2012-02-13T18:28:17Z @stof isn't the branch based on the latest master ? --------------------------------------------------------------------------- by stof at 2012-02-13T19:32:52Z Well, github tells me it cannot be merged automatically. so either there is a conflict, either their conflict detection failed last time you pushed. --------------------------------------------------------------------------- by vicb at 2012-02-13T22:20:06Z I did fail. Should be ok now. --------------------------------------------------------------------------- by fabpot at 2012-02-14T23:27:08Z I'm -1 on the second commit. --------------------------------------------------------------------------- by vicb at 2012-02-15T07:44:25Z Thanks all for the feedback. @fabpot ready ! --------------------------------------------------------------------------- by stof at 2012-02-15T07:46:53Z @vicb not ready: you reverted all use of ``is_ajax`` in the templates (and you did not renamed it to the underscored name preferred by @fabpot) --------------------------------------------------------------------------- by vicb at 2012-02-15T07:54:30Z Well I did revert the use of "`isajax`" (prefer not to mix CS here, the scope of this PR is not to fix CS) because it is not used (this should be applied to the Doctrine profiler). _What I mean is that `isajax` in all the Sf templates w/o the associated js is useless, basically all or nothing_ --------------------------------------------------------------------------- by vicb at 2012-02-15T08:26:41Z btw @fabpot it makes me wonder if underscored variable names is a good idea, this will force us to mix (i.e. `is_ajax` vs `request.isxmlhttprequest`). What do you think ? --------------------------------------------------------------------------- by fabpot at 2012-02-15T10:09:20Z I still prefer `is_ajax` as it makes things more readable. --------------------------------------------------------------------------- by vicb at 2012-02-15T10:16:13Z At a larger scale how do fix the inconsistency described in my previous message ? Options are: * fix twig cs * create twig cs specific to sf2 * don't fix (= keep & live with some inconsistency) --------------------------------------------------------------------------- by stof at 2012-02-15T10:22:13Z @vicb we also use underscores for variables used in the form themes. the official Twig CS are basically the one used by Sf2 in the form theme --------------------------------------------------------------------------- by fabpot at 2012-02-15T10:24:46Z I don't see any inconsistencies here. One a variable name and the other is a method call/property name. So, my vote is a don't fix. --------------------------------------------------------------------------- by vicb at 2012-02-15T10:28:53Z I agree but then we loose one advertised benefit a twig: _"Easy to learn: The syntax is easy to learn and has been optimized to allow web designers to get their job done fast without getting in their way"_. The designers should now be aware of the underlying implementation (i.e. Am I dealing with a variable or a function ?) Edit: race condition here... I agree with @stof --------------------------------------------------------------------------- by stof at 2012-02-15T10:45:49Z @vicb they see that ``isXmlHttpRequest`` is not a variable. They are accessing it on the ``request`` variable (well, recurse here to reach the variable) --------------------------------------------------------------------------- by fabpot at 2012-02-15T10:46:57Z variables and functions are underscored. --------------------------------------------------------------------------- by vicb at 2012-02-15T10:51:28Z I think that the beauty of Twig comes from the fact that designers do not have to wonder if "something" is an array / an object / a variable / a method / a property. But never mind, I'll update the PR. --------------------------------------------------------------------------- by vicb at 2012-02-15T10:55:06Z @fabpot would you mind if I open a PR against twig to check for existence of `collector::getNotCalledListeners()` when a designer writes `collector.not_called_listeners`, then we are all happy ? --------------------------------------------------------------------------- by vicb at 2012-02-15T11:21:55Z ready ! --------------------------------------------------------------------------- by fabpot at 2012-02-15T11:31:50Z The problem is that the `Twig_Template::getAttribute()` is already the bottleneck
The first commit should be merged as
app
is not always accessible in the twig template due to the ways the templating system is used. Then there is currently no way to check if we are dealing with an ajax request in the view.The second commit use ajax to load the panels. This should make the interface more responsive as you don't have to load the layout each time + the panels are cached. Loading via AJAX would also work if your panel does not extend the ajax layout (legacy support) - this would be less efficient though as you would load the layout and filter it out afterwards.
I am not sure if the second commit is worth merging, maybe it is useless ?