+1 I just ran into the problem of not being able to prepend my routes
from my plugins - I hate it! (but I love everything else 1.1). I agree
with Carl Vondrick: if we're breaking compatability, let's do it now.
Plus, I can think of no good solution to the registering routes of
plugins, except something that would be messy and weak, and then just
be changed again on the next release.
I REALLY think we should push this.
On Jan 2, 4:22 am, "Alistair Stead" <[EMAIL PROTECTED]>
wrote:
> +1 This would allow me to achieve some of the functionality I have been
> trying to build for a multi site CMS solution
>
> On 01/01/2008, Dustin Whittle <[EMAIL PROTECTED]> wrote:
>
>
>
> > +1 for this in 1.1... This sounds ideal.. It provides better
> > extensibility (dimensions concept) and better separation for testing.
>
> > - Dustin
>
> > On Dec 27 2007, 10:52 pm, Fabien POTENCIER <[EMAIL PROTECTED]
> > project.com> 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
> > developerhttp://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
-~----------~----~----~----~------~----~------~--~---
