Hi all,
The symfony 1.1 release comes along nicely but I still have 2
major/blocking problems which need to be fixed before 1.1-beta1 and I
have no simple solution:
* Plugins are unable to register routes (#2408)
* It's not possible to connect listeners early on
I've tried very hard to find a solution to those 2 problems with no
luck. This is mainly due to the introduction of the event dispatcher and
how objects now communicate together automagically.
* Short story for problem 1: The possibility for a plugin to register
routes in symfony 1.0 works because sfRouting is a singleton. So plugins
can just get the instance of the routing and add routes. In symfony 1.1,
the sfRouting class is not a singleton anymore, so if you want to add
routes you need to get the sfContext instance which does not exist yet.
If you get it, you trigger the sfContext initialization early (with all
the possible side effects it might have) and when you have the instance,
the request is already parsed by the routing object, so your route
registration won't have any effect.
* Short story for problem 2: The dispatcher is created by the
sfContext::initialize() method where the factories are also loaded. So,
there is no way to do something between the dispatcher creation are the
loading of the factories. It means that it's impossible for the
developer to register its own listeners for the event that are notified
by core objects during initialization.
I can give you more information about the solution I tried and why they
do not work.
But I have a solution that fix those 2 problems and have a lot of other
benefits. As it introduces a lot of changes, I want your feedback before
committing anything. The solution is already implemented and was
expected to be committed for symfony 1.2 but I really think we need it
for 1.1.
The solution is to introduce a new object called sfConfiguration. This
object is responsible for the configuration of an application. The
sfContext is not a singleton anymore and now takes a sfConfiguration
object as an argument. This fixes a lot of things:
* The dispatcher is created very early in the process by the
sfConfiguration object, before sfContext is initialized.
* The developer can create its own configuration
(ApplicationConfiguration) and do whatever he wants very early (with
access to the dispatcher)
* The sfConfiguration class has all the sfLoader:: static methods (but
they are not static anymore). So, it's not possible to override sfLoader
(#2288)
* The sfConfiguration class initializes the directory structure. So,
if you want to change the web root directory, it's just a matter of
calling the ->setWebRootDir() method in
ApplicationConfiguration::configure() method. The same goes for any
other directory structure customization. This is perhaps the most
frequently asked question on the mailing-list.
* As the context is not a singleton anymore, it's now possible to
create a link for a frontend action from a backend module. Hmm, this IS
the most frequently asked question on the mailing-list and the forum.
* Initialization is separated in 2 different phases: The
initialization of the framework (sfConfiguration) and the initialization
of a request (sfContext). It eases testing a lot.
* Unit tests are easier because you just need a sfConfiguration object
(symfony 1.0 sometimes requires a sfContext with all the problem of
loading factories, generating cache files, ...)
* All constants are removed (SF_APP, ...). They are just
sfConfiguration constructor arguments. In fact, all singletons are also
removed.
* and many other things I can't remember right now
The major change is the front controller script:
<?php
include dirname(__FILE__).'/../config/config.php';
require_once $sf_symfony_lib_dir.'/config/sfConfiguration.class.php';
require_once $sf_symfony_lib_dir.'/util/sfContext.class.php';
$configuration = new ApplicationConfiguration('##APP_NAME##', 'prod',
false, dirname(__FILE__).'/..', $sf_symfony_lib_dir, $sf_symfony_data_dir);
sfContext::createInstance($configuration)->dispatch()->send();
To upgrade projects, we will need to change the front controllers and
people will have to move the customization they made in their
application config.php file into the ApplicationConfiguration class.
Please, give your feedback,
Fabien
--
Fabien Potencier
Sensio CEO - symfony lead developer
http://www.sensiolabs.com/
http://www.symfony-project.com/
Sensio Labs
Tél: +33 1 40 99 80 80
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
