Commits
-------
83199ae [FrameworkBundle] Fix unintuitive merging behavior for assets_base_urls
4061114 [FrameworkBundle] fixes unintuitive merging behavior
Discussion
----------
[FrameworkBundle] fixes unintuitive merging behavior
---------------------------------------------------------------------------
by fabpot at 2011/09/16 10:04:53 -0700
I think this is a "bug", no? If this is the case, then we need to fix the 2.0 branch.
---------------------------------------------------------------------------
by schmittjoh at 2011/09/17 00:34:14 -0700
It is a change in behavior, but whether or how you want to merge this is really up to you.
---------------------------------------------------------------------------
by jmikola at 2011/09/19 08:09:26 -0700
I was about to create a PR for this very same quirk, as this was causing my CDN's for various environments to all get merged together. I think we can get away with merging it directly to 2.0 since `assets_base_urls` are hardly covered in the documentation at all.
Once this gets merged, I wouldn't mind writing up a blurb on them to explain how the shorthand syntax works and this merging strategy.
---------------------------------------------------------------------------
by jmikola at 2011/09/19 08:28:21 -0700
I just noticed this PR only fixes the `base_urls` config option under `packages`. We should also correct this behavior for `assets_base_urls`, which appears further up in FrameworkBundle's Configuration.php file.
---------------------------------------------------------------------------
by jmikola at 2011/09/19 08:44:57 -0700
@schmittjoh: I have the second commit for this sitting in https://github.com/jmikola/symfony/tree/configFix (rebased on your branch) if you'd prefer to merge that into your branch to update this PR.
---------------------------------------------------------------------------
by schmittjoh at 2011/09/19 08:55:42 -0700
Merged it in. Thanks.
---------------------------------------------------------------------------
by fabpot at 2011/09/19 09:01:27 -0700
ok, I'm going to merge this into master.
@jmikola: Can you submit documentation for the new way?
Commits
-------
9fe87be More explicit default value for assets_version_format
Discussion
----------
Fixed default asset version format
This is not needed as it is already the value that is set when null in ``Symfony\Component\Templating\Asset\Package`` but that would make it clearer for people who just read the configuration.
-- add missing files
-- tweak translation command files
-- dumpers are now responsive for writting the files
-- moved the twig extractor the bridge
-- clear temp files after unit tests
-- check the presence of dumper in translation writer
-- General cleaning of the code
-- clean phpDoc
-- fix PHPDoc
-- fixing class name in configuration
-- add unit tests for extractors (php and twig)
-- moved test to correct location
-- polish the code
-- polish the code
Commits
-------
41b7a19 Updated the tests so that tests will be marked as skipped when there is no MongoDB server present!
233c7db Updated the code to follow the symfony coding standards
7b24de5 Updated the code to follow the symfony coding standard using stof his remarks
fbcbdde - Fixed a small bug - Updated some phpdoc
00fdfec Added a MongoDbProfilerStorage engine
Discussion
----------
[2.1] [HttpKernel] MongoDb storage for Profiler
As a documentbased database like MongoDB is [supposedly fantastic in logging](http://blog.mongodb.org/post/172254834/mongodb-is-fantastic-for-logging) I implemented a storage engine for the profiler that should enable us to use this database as storage for this.
Activate it using this way:
framework:
profiler:
dsn: mongodb://user:pass@location/database/collection
---------------------------------------------------------------------------
by stof at 2011/07/24 11:23:06 -0700
btw, the MongoDB session storage has already be rejected from the core so this should probably be moved to the DoctrineMongoDBBundle (even if it uses only the PHP extension and not Doctrine). @fabpot thoughts about this ?
---------------------------------------------------------------------------
by Wotre at 2011/07/24 11:52:56 -0700
Just my personal opinion, if it is prefered that way I will move this into the DoctrineMongoDBBundle.
While it is reasonable to bundle all Mongo related things together, I do believe that in the case of logging we want to avoid as many depencies as possible. Some exceptions can occur pretty early inside the framework, and it would be a shame if those aren't logged because this layer is written on top of doctrine. I'm not exactly familliar enough with the symfony internals as I only started using it a few days ago, but I can imagine that this can make a difference with some exceptions.
---------------------------------------------------------------------------
by stof at 2011/07/24 11:59:10 -0700
I don't ask you to use Doctrine in this code. It is fine to use the extension directly if it is enough.
Btw, the profiler is *not* used early. :)
---------------------------------------------------------------------------
by Wotre at 2011/07/26 10:45:05 -0700
So... Any final remark whether this should be moved to [the DoctrineMongoDBBundle](https://github.com/symfony/DoctrineMongoDBBundle) or not?
If it has to be moved, any comment on where in that bundle this should be put?
Also, if it has to be moved, how can we arrange the configuration using DI? Currently I've put a line in the FrameworkExtension file to use this engine for everything with a $dsn starting with mongodb; I imagine this kind of ugly depency can't really exist between the FrameworkBundle and another one.
Although it seems completely illogical to me, I will move it, but I do need some directions on how to elegantly do this...
---------------------------------------------------------------------------
by stof at 2011/07/26 11:03:04 -0700
@fabpot what do you think ?
---------------------------------------------------------------------------
by stof at 2011/09/04 01:28:48 -0700
@fabpot what do you think about the place where this should be done ?
Commits
-------
9f0bd03 [HttpKernel] Update tests for FileProfilerStorage
b7032bc [HttpKernel] Update FileProfileStorage to search from EOF
188a5fa [HttpKernel] Override the existing tokens in FileProfilerStorage
b1b1424 [HttpKernel] Delete folders in the profiler cache
88bc3ec [HttpKernel] Fixes standards of FileProfilerStorage
affe66c Merge remote-tracking branch 'origin/master' into new-profiler-storage
ea916c3 [HttpKernel] Coding convention for the file profiler storage
9ae2c8d [HttpKernel] CS in file storage
b415efd [HttpKernel] Add a test for semicolon in file storage test
1c1215f [HttpKernel] Use subfolders for better storage in file storage of profiler
4b1dc1f [HttpKernel] Fix the folder attribute of file storage to private
70f73e1 [HttpKernel] Fix tests for the file storage of profiler
d5313d9 [HttpKernel] Add tests for the file profiler storage
09fc0a2 [HttpKernel] Add Symfony credits to the file storage class for the profiler
d1d5892 [HttpKernel] Finalize the file storage for the profiler
2f65cf2 Add POC for file storage system
Discussion
----------
[2.1] [HttpKernel] File storage for profiler
Symfony2 has some problems when dealing with multiple concurrency queries in the SQLite storage, resulting in a timeout error or terrible lack.
I've implemented after discussions with @fabpot a filesystem storage.
Enable it in your project with :
framework:
profiler:
dsn: "file:%kernel.cache_dir%/profiler"
I also studied the possibility to store only big data string in files and rest in the SQLite, but not concluant.
Results of my measures (4 concurrency, 120 total) :
* SQLite with data : 1057ms
* SQLite without data : 615ms
* MySQL : 40ms
* This File storage : 54ms
---------------------------------------------------------------------------
by alexandresalome at 2011/07/22 12:01:10 -0700
An idea for the find method : a csv file containing ip;url;token
The iteration could be done over a big file, without loading the whole file in memory.
---------------------------------------------------------------------------
by alexandresalome at 2011/07/23 14:22:32 -0700
OK new version, with as explained previously : a CSV file containing the index + file for each profile.
The speed is similar to the speed of MySQL, and no memory overhead should occur with this solution.
---------------------------------------------------------------------------
by alexandresalome at 2011/07/23 14:37:14 -0700
Hm... Created tests, duplicated from SqliteProfilerStorageTest.
Any idea on how to put this code in common ? Is it usual to create a base class for 2 tests ?
---------------------------------------------------------------------------
by alexandresalome at 2011/07/23 14:48:39 -0700
Just tested with 24.000 requests, the 24.001'th request still takes less than 50ms to execute.
The index file is about 2Mb, and iterating the whole file is fast.
---------------------------------------------------------------------------
by alexandresalome at 2011/07/23 14:53:19 -0700
I've filled the file with 120Mb of data, requests are still less than 50ms for executing.
Iterating the index takes more than 30s (so it crashed), but it's because of the amount of lines. 30 seconds = 1,400,000 lines in this computer. The file = 1,500,000 lines
---------------------------------------------------------------------------
by alexandresalome at 2011/07/23 14:56:54 -0700
I've tested it with Linux, is someone can test with Windows
---------------------------------------------------------------------------
by stloyd at 2011/07/24 00:32:32 -0700
IMO to speedup it a bit more and not end up with "crash" (to not end with "limit" of files per directory, also to many files in dir slow down every OS) you should use same method to write as Twig, split up files in to directories. If you do this you can speed up index more, because you can create smaller one per directory.
Also you should fix CS (coding standards).
---------------------------------------------------------------------------
by stloyd at 2011/07/24 02:10:20 -0700
Tested on Win 7, seems ok. Similar speed to sqlite, dunno why ;-) but used a bit less of memory.
---------------------------------------------------------------------------
by alexandresalome at 2011/07/24 02:13:21 -0700
Did you tried with concurrent requests ? It makes sense when you use assetic
and your browser hits the application 4 times simultaneously for CSS
generation
---------------------------------------------------------------------------
by alexandresalome at 2011/07/24 02:17:23 -0700
I used Apache Benchmark for producing results :
ab -c 4 -n 120 URL
---------------------------------------------------------------------------
by alexandresalome at 2011/07/24 02:56:55 -0700
OK I used subfolders, based on last characters (because the first part of token is mostly the same between queries.
---------------------------------------------------------------------------
by stof at 2011/09/04 01:27:15 -0700
@fabpot any news about it ? Can it be merged ?
This commit also fixes exception pages when Twig is not enabled as a templating engine.
Instead of just displaying the raw Twig template as before, we now fallback to the default
exception handler introduced some time ago.
Commits
-------
9bcce9f fix tests
fc4787a fix non-extensible router
Discussion
----------
Router fix
Right now, the router is hard to overwrite (you need always a compiler pass). This commit fixes this.
---------------------------------------------------------------------------
by fabpot at 2011/07/18 01:15:36 -0700
Why do you need a complier pass to override the router?
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 01:47:47 -0700
How would you suggest to overwrite it?
Basically, I want to do something like this:
```yml
services:
router:
parent: router.default
class: MyClass
calls:
- [moreDeps, []]
```
---------------------------------------------------------------------------
by Seldaek at 2011/07/18 05:07:19 -0700
Then maybe we should somehow support redefining services with the same name while keeping the old one as parent, otherwise we need this foo.default for every service out there?
---------------------------------------------------------------------------
by fabpot at 2011/07/18 06:30:34 -0700
as @Seldeak said, why do that for the router and not all services?
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 06:38:39 -0700
I have designed the SecurityBundle this way where extension is encouraged.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 11:15:57 -0700
I should add that this is mainly a problem for services where you still want to use the semantic configuration that is provided by the bundle. For services which are not configured by the extension, this is not so much of an issue.
Anyway, if you don't want to merge it, just close the PR. I have no problem with using a compiler pass.
---------------------------------------------------------------------------
by fabpot at 2011/07/18 11:55:11 -0700
We already have such a case with translator and translator.real. I will review the existing services to see where it makes sense to implement the same strategy.
---------------------------------------------------------------------------
by Seldaek at 2011/07/18 12:20:55 -0700
I guess you'd do it anyway, but we should pick a winner between .real and .default
---------------------------------------------------------------------------
by lsmith77 at 2011/07/18 12:26:52 -0700
I would prefer ".default" as ".real" always confused me.
The current implementation is not ready for inclusion in 2.0. It has several
known problems (security, not possible to disable it, not "cloud-compatible",
...) and it's not a must have feature anyway.
Some references:
* Security issue in FileType: https://github.com/symfony/symfony/issues/1001
* Validation fails on file, still stored in TemporaryStorage: https://github.com/symfony/symfony/issues/908
* Add a size argument & ability to configure TemporaryStorage: https://github.com/symfony/symfony/pull/748
This feature should be reworked and discussed for inclusion in 2.1.
Here are the new simplified rules:
* Required cache warmers are *always* executed when the Kernel boots for the first time;
* Optional cache warmers are *only* executed from the CLI via cache:warmup
These new rules means that all the configuration settings for the cache
warmers have been removed. So, if you want the best performance, remember to
warmup the cache when going to production.
This also fixed quite a few bugs.
* Seldaek/events:
[EventDispatcher] Removed temporary code
[FrameworkBundle] Improved code readability
[FrameworkBundle] Clarified code and fixed regression
Update Core and Security events to latest model
[EventDispatcher] Allow registration of arbitrary callbacks
[EventDispatcher] Remove useless code
[EventDispatcher] Minor memory optimization to getListeners()
[FrameworkBundle] Small optimization, remove some function calls
This in effect removes the direct link between event name and the method name on the handler.
Any callback can be given as a handler and the event name becomes an arbitrary string. Allowing for easier namespacing (see next commit)
This feature added complexity to the framework but wasn't used in the core anyway.
You can still use the Map class loader in your application though. But most of the time, using the APC
autoloader is just better.
* noelg/session-storage-bug:
Fixed a bug when the storage service is initialized later by another bundle. In this case, we can't add the storage class to the compiled class as the service does not exists.
This has been removed for several reasons:
* the framework does not know where the document root is and should not care
* as the document root was static, it was impossible to have several document roots depending on some business rules (see next one)
* sometimes, the document root is not under the web root directory (so the logic of getWebPath() is not always correct)
* the feature was not used anywhere in the core
* bschussek/form-extensions:
[Form] Refactored code from CoreExtension to new ValidatorExtension
[Form] Added FormTypeExtensionInterface
[Form] Reorganized code into "form extensions"
With implementations of this interface, existing types can be amended.
The Csrf extension, for example, now contains a class FormTypeCsrfExtension
that adds CSRF capabilities to the "form" type.
To register new type extensions in the DIC, tag them with "form.type_extension"
and the name of the extended type as alias.
The extension classes are now the only constructor argument of the FormFactory class. They replace the existing "type loader" classes.
new FormFactory(array(
new CoreExtension($validator, $storage),
new CsrfExtension($csrfProvider),
new DoctrineOrmExtension($em),
));
Together with a few upcoming commits this mechanism will make
* extension of the form framework in bundles and
* usage of the forms outside of Symfony2
much easier.
* made the options array only for "global" options that are valid for all session storages
* changed the PDO session storage constructor signature to accept an array of options for DB configuration
* changed the storage_id to be the full service id, instead of just part of it
* removed the class parameter for session as it can be changed via the .class parameter (it was the only example in the framework)
* removed the configuration for the PDO session storage for now
* kriswallsmith/dic/method-renames:
added method renames to UPDATE
[DependencyInjection] renamed ContainerBuilder::remove() as removeDefinition() to be more consistent with other definition-related methods
[DependencyInjection] renamed Definition::setArgument() as replaceArgument() to be more specific
The _scheme requirement can be used to force routes to always match one given scheme
and to always be generated with the given scheme.
So, if _scheme is set to https, URL generation will force an absolute URL if the
current scheme is http. And if you request the URL with http, you will be redirected
to the https URL.
* schmittjoh/diLogging:
[DependencyInjection] enable debug related passes only in debug environment
[DependencyInjection] removed pass time
[DependencyInjection] fixes a bug which might have occurred when using property injection under certain circumstances
[DependencyInjection] fixed method name
[FrameworkBundle] whitespace fix
[DependencyInjection] refactored code a bit, added some more logging messages
[DependencyInjection] dump a readable format
[DependencyInjection] better logging
* vicb/locate_template2:
[FrameworkBundle] Enforce templates instances of TemplateReferenceInterface
[FrameworkBundle] Add unit tests for the CacheTemplateLocator class
[FrameworkBundle] Add unit tests for the TemplateLocator class
[TwigBundle] Fix the cache warmer
[TwigBundle] Tweak cache warmer configuration
[FrameworkBundle] Fix resource inheritance in the template cache warmer
The parameter has been removed and the service moved to the XML file (for consistency).
The behavior is still the same as before as any non-public service
which is not referenced anywhere will be automatically removed by a
compiler pass.
We a currently working on a project were a single requested URL typically
leads to some hundred controller calls. Using the dev controller got
incredibly slow since recent Symfony2 changes because for each controller
invocation a new entry gets added to the profiler storage (totalling over
100mb of data on each request in our case).
With the new configuration attribute "only-master-requests" it is possible
to limit the profiler storage to the master requests, keeping the profiler
usable for us.
* vicb/cfg_rebase:
[Config] Ability to add and override node types without having to subclass NodeBuilder
[DoctrineBundle] Fix some typos
[SwiftMailerBundle] Fix a merge issue in the configuration
Tweak PHPDocs in the extension configuration files
[Config] Component refactoring
The Config component API have changed and the extension configuration files must be updated accordingly:
1. Array nodes must enclosed their children definition in ->children() ... ->end() calls:
Before:
$treeBuilder->root('zend', 'array')
->arrayNode('logger')
->scalarNode('priority')->defaultValue('INFO')->end()
->booleanNode('log_errors')->defaultFalse()->end()
->end();
After:
$treeBuilder->root('zend', 'array')
->children()
->arrayNode('logger')
->children()
->scalarNode('priority')->defaultValue('INFO')->end()
->booleanNode('log_errors')->defaultFalse()->end()
->end()
->end()
->end();
2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition)
Before:
$treeBuilder->root('doctrine', 'array')
->arrayNode('dbal')
->builder($this->getDbalConnectionsNode())
->end();
After:
$treeBuilder->root('doctrine', 'array')
->children()
->arrayNode('dbal')
->append($this->getDbalConnectionsNode())
->end()
->end();
3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition):
Before:
$root = $treeBuilder->root('doctrine', 'array');
$this->addDbalSection($root);
public function addDbalSection(NodeBuilder $node)
{
...
}
After:
$root = $treeBuilder->root('doctrine', 'array');
$this->addDbalSection($root);
public function addDbalSection(ArrayNodeDefinition $node)
{
...
}
4. The NodeBuilder API has changed (this is seldom used):
Before:
$node = new NodeBuilder('connections', 'array');
After:
The recommended way is to use a tree builder:
$treeBuilder = new TreeBuilder();
$node = $treeBuilder->root('connections', 'array');
An other way would be:
$builder = new NodeBuilder();
$node = $builder->node('connections', 'array');
Some notes:
- Tree root nodes should most always be array nodes, so this as been made the default:
$treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine')
- There could be more than one ->children() ... ->end() sections. This could help with the readability:
$treeBuilder->root('doctrine')
->children()
->scalarNode('default_connection')->end()
->end()
->fixXmlConfig('type')
->children()
->arrayNode('types')
....
->end()
->end()
This command uses a new container pass which dumps the ContainerBuilder into a cache file by serializing it. It's possible that we don't want this to run when kernel.debug = false, but I don't see the harm of generating the file and running the container:debug in, for example, the prod environment seems to make sense.
The only missing part is ContainerAwareEventManager::addEventSubscriberService(),
because I'm not sure how to find out the class name of a service in the DIC.
Also, inline documentation of this code needs to be finished once it is accepted.
Doctrine's EventManager implementation has several advantages over the
EventDispatcher implementation of Symfony2. Therefore I suggest that we
use their implementation.
Advantages:
* Event Listeners are objects, not callbacks. These objects have handler
methods that have the same name as the event. This helps a lot when
reading the code and makes the code for adding an event listener shorter.
* You can create Event Subscribers, which are event listeners with an
additional getSubscribedEvents() method. The benefit here is that the
code that registers the subscriber doesn't need to know about its
implementation.
* All events are defined in static Events classes, so users of IDEs benefit
of code completion
* The communication between the dispatching class of an event and all
listeners is done through a subclass of EventArgs. This subclass can be
tailored to the type of event. A constructor, setters and getters can be
implemented that verify the validity of the data set into the object.
See examples below.
* Because each event type corresponds to an EventArgs implementation,
developers of event listeners can look up the available EventArgs methods
and benefit of code completion.
* EventArgs::stopPropagation() is more flexible and (IMO) clearer to use
than notifyUntil(). Also, it is a concept that is also used in other
event implementations
Before:
class EventListener
{
public function handle(EventInterface $event, $data) { ... }
}
$dispatcher->connect('core.request', array($listener, 'handle'));
$dispatcher->notify('core.request', new Event(...));
After (with listeners):
final class Events
{
const onCoreRequest = 'onCoreRequest';
}
class EventListener
{
public function onCoreRequest(RequestEventArgs $eventArgs) { ... }
}
$evm->addEventListener(Events::onCoreRequest, $listener);
$evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...));
After (with subscribers):
class EventSubscriber
{
public function onCoreRequest(RequestEventArgs $eventArgs) { ... }
public function getSubscribedEvents()
{
return Events::onCoreRequest;
}
}
$evm->addEventSubscriber($subscriber);
$evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...));
How to upgrade?
For XML configuration files:
* All extensions should now use the config tag (this is just a convention as
the YAML configurations files do not use it anymore):
* The previous change means that the doctrine and security bundles now are
wrapped under a main "config" tag:
<doctrine:config>
<doctrine:orm />
<doctrine:dbal />
</doctrine:config>
<security:config>
<security:acl />
...
</security:config>
For YAML configuration files:
* The main keys have been renamed as follows:
* assetic:config -> assetic
* app:config -> framework
* webprofiler:config -> web_profiler
* doctrine_odm.mongodb -> doctrine_mongo_db
* doctrine:orm -> doctrine: { orm: ... }
* doctrine:dbal -> doctrine: { dbal: ... }
* security:config -> security
* security:acl -> security: { acl: ... }
* twig.config -> twig
* zend.config -> zend
This allows for better conventions and better error messages if you
use the wrong configuration alias in a config file.
This is also the first step for a bigger refactoring of how the configuration
works (see next commits).
* Bundle::registerExtensions() method has been renamed to Bundle::build()
* The "main" DIC extension must be renamed to the new convention to be
automatically registered:
SensioBlogBundle -> DependencyInjection\SensioBlogExtension
* The main DIC extension alias must follow the convention:
sensio_blog for SensioBlogBundle
* If you have more than one extension for a bundle (which should really
never be the case), they must be registered manually by overriding the
build() method
* If you use YAML or PHP for your configuration, renamed the following
configuration entry points in your configs:
app -> framework
webprofiler -> web_profiler
doctrine_odm -> doctrine_mongo_db