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
Commits
-------
3dd3d58 [EventListener] Fix an issue with sub-requests
71bf279 cleanup
acdb325 [StopWatch] Provide a cleaner API
acd1287 [Stopwatch] rename the section event to avoid collisions
eb540be [Profiler] Allow profiling the terminate event
4ccdc53 [HttpKernel] Cleanup of PdoProfilerStorage
814876f [HttpKernel] Tweak the code of the ProfilerListener
Discussion
----------
[Profiler] Allow profiling the terminate event
This PR is mainly about allowing to profile the terminate event (i.e. see it in the timeline panel)
There are some other tweaks.
---------------------------------------------------------------------------
by vicb at 2012-02-02T14:43:20Z
please don't merge for now. good question. bad answer.
---------------------------------------------------------------------------
by vicb at 2012-02-06T15:05:46Z
While first commits were focused on problem solving, the last brings a clean API with the ability to re-open an existing section in order to add events (re-setting event origins and merging them were just hacks).
Should be ready to be merged.
_Edit: Sorry, couldn't resist adding a private helper class again!_
---------------------------------------------------------------------------
by stof at 2012-02-06T18:30:09Z
@vicb you should stop adding such classes defined in the same file. Otherwise we will have to change the CS (and to stop telling we respect the PSR-0 standard)
---------------------------------------------------------------------------
by vicb at 2012-02-06T18:33:36Z
Once again PSR-0 is about autoloading which is exactly why I do not want in such cases. CS are an other matter and yes I think they should be changed to allow this (and I am going to submit a PR right now).
The only argument I could accept is whether this class should be private or not.
---------------------------------------------------------------------------
by vicb at 2012-02-06T19:57:06Z
Thanks for your valuable feedback @stof
---------------------------------------------------------------------------
by fabpot at 2012-02-11T20:53:03Z
Have you tested it on a project? Because it breaks my simple examples (where I have some sub-requests).
---------------------------------------------------------------------------
by vicb at 2012-02-12T09:47:23Z
my bad, should be ok now.
Commits
-------
ac59db7 cleanup
64ea95d [WebProfilerBundle] Add redirection info to the router panel
826bd23 [FrameworkBundle] fix phpDoc of ControllerResolver::createController()
e3cf37f [HttpFoundation] RedirectResponse: add the ability to retrieve the target URL, add unit tests
50c85ae [WebProfiler] Add info to the router panel
Discussion
----------
[WIP][Profiler] Routing
former #3206 part 3 (depends on part 1 - #3280)
The goal of this PR is to fix#3264 by adding redirection infos on the router panel.
Done:
* Add info on the target url / route
To do:
* Display an accurate URL matching process (when using the RedirectableUrlMatcher)
Commits
-------
0d4d7e0 [WebProfilerBundle] Make the toolbar use the common JS
a440279 [WebProfilerBundle] Adds panel pages
762d90d [Profiler] Buid a common infrastructure
Discussion
----------
[Profiler] Provide a common infrastructure
former #3206 part 3
* base JS (provides ajax, toggle, css class helpers),
* panel pages (used only by the Doctrine panel for now).
Successfuly tested with the (future version of the) Doctrine panel.
Commits
-------
a52c675 [WebProfilerBundle] Improve the logger panel
Discussion
----------
[WebProfilerBundle] Improve the logger panel
No more need to hit 'refresh'
