thank you for this .. works perfectly.
note we discussed at length if this should go into the TwigBundle or into WebProfilerBundle. in the end we agreed on putting it into TwigBundle since this way one can even put template using this tag into production where the profiler is usually disabled.

I would have put the code into the Twig bridge instead as this is where the integration of Twig and components happens. That would make the tag easily available for Drupal and Silex for instance.

ah doh .. makes sense.

@fabpot I've moved the code to the twig bridge

Great! That deserves a "living on the edge" blog entry :-)

You should add a note in the CHANGELOG of the Twig bridge about this addition.

What happens when u have multiple stopwatch blocks with the same name? Does it get aggregated or overwritten?

{% stopwatch foo %}... some things that gets timed{% endstopwatch %}uninteresting stuff{% stopwatch foo %}... some things that gets timed{% endstopwatch %}

Tests are missing

btw, usingNAME_TYPE forbids having dots in the event name. Shouldn't we allow using a string too ?

And would it make sense to allow passing any Twig expression instead of only compile-time values ? Nothing in the current code requires to be able to use the event name at compile-time so we could make it dynamic.

@stof should I add a StopwatchTokenParserTest? And what exactly do you mean with your last paragraph? Allowing string is a great idea, I'll add it.

@Tobion due to the way the stopwatch works, only the first one is recorded. I'll throw an error if the name already exists.

Todo

• Add test
• Allow strings
• Throw error when name already exists
• Make it dynamic (?)

We should usestart,stop instead to allow what@Tobion describe. Adn we should also support categories.

@fabpot I can understand it wrong, but I already use start and stop?

@wouterj here is what I mean:

{%stopwatch'foo'%}{# equivalent of current stopwatch foo #}{%endstopwatch%}{%setbar ='foo'%}{%stopwatchbar%}{# uses the variable #}{%endstopwatch%}{%stopwatch (bar ~'test')|upper%}{# uses a complex expression #}{%endstopwatch%}

hmm, it could cause an issue to stop as we would need to stop the one we started, not to re-evaluate the expression as variables could have changed inside the body

Thanks for the explaination! But do you really think it's worth it? The core block tag doesn't support it and I don't think people will use such a things for debugging.

@wouterj block names have to be known at compile time. So it is a bad comparison

I think it would be good to support{% endstopwatch 'name' %} to make sure the right stopwatch is stopped. As far as I can see, it is also not possible to nest these tags, am I right?

@matthiasnoback The end tag should stop the corresponding opening tag. So passing the name explicitly is only a way to allow mistakes as it must be the same value.

And nothing forbids you to nest them if you use different names

I've implemented everything that is said here, except for 2 things:

• Dynamic names. I fail to see when this is used.
• Fabien's last comment (I can't follow that one). It throws an exception now if 2 names are equal

ping@fabpot

Closing in favor of#8719