Sounds great to me!
Solving these issues in this way seems to have a lot of beneficial
side-effects... Moving the configuration from the application config
to an ApplicationConfiguration class doesn't seem to be a big deal to
me. Ofcourse it can be unconvenient for some people, but i don't think
those 'efforts' will be to much if you look at the results you get
from it....
I'd say go for it!
Peter's €0.02
Fabien POTENCIER wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
