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.
I tried to use the 1.1 version today and quickly had to go back
because none of the plugins works. From further reading I take it you
are trying to consolidate a lot of classes into a number of major
classes. I think routing logging and configuration you are trying to
move into the one class. I assume this is for a speed advantage.
Without making use of your new methods it is very hard to give you an
answer. Can it be done with proxy calls from the old methods to the
new ones to overcome these issues so when people upgrade there current
sites using symfony they do not break.
I may be completely off track to what you are asking but I do see
where you are trying to go. Keep up the awesome work you are doing :)
On Dec 28, 3:52 pm, Fabien POTENCIER <fabien.potenc...@symfony-
> 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';
> 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.
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....
> 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';
> 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.
> 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
Certainly the first issue here is something that's critical to sf1.1 being released - I've not played with the dispatcher in 1.1 so I can't really comment on the second.
Other then a change to the controller, what are the downsides of your suggestions?
This sounds great to me, given the number of improvements sfConfiguration would allow. Apart from the changes in the controlers, which other disadvantages would imply the solution that you propose ? For how long would these changes postpone symfony 1.1 ?
> * 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.
- From my humble point of view, this is the most decisive point, as such a separation /makes sense/. So, go for it !
> 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';
> 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.
* symfony 1.1 will take a bit longer to be released as the changes will need some testing * people will have to move their custom changes from config.php to the new ApplicationConfiguration class (I think this is only marginal) * documentation will need to be updated to reflect the changes
Ian P. Christian wrote: > 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
> Certainly the first issue here is something that's critical to sf1.1 > being released - I've not played with the dispatcher in 1.1 so I can't > really comment on the second.
> Other then a change to the controller, what are the downsides of your > suggestions?
we don't have a single (pre-)release of symfony 1.1 yet.
On the other hand: if these things you wrote about are already
implemented and working - why not merging them into sf 1.1?
Your suggestions definately justify a bit more work on upgrading a
project!
Maybe you could even write an upgrade class(?) to update the front
controller scripts?
+ 1 for your suggestions!
Regards,
Matthias
On 28 Dez., 07:52, Fabien POTENCIER <fabien.potenc...@symfony-
> 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';
> 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.
> * symfony 1.1 will take a bit longer to be released as the changes > will need some testing > * people will have to move their custom changes from config.php to the > new ApplicationConfiguration class (I think this is only marginal) > * documentation will need to be updated to reflect the changes
> Ian P. Christian wrote: > > 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
> > Certainly the first issue here is something that's critical to sf1.1 > > being released - I've not played with the dispatcher in 1.1 so I can't > > really comment on the second.
> > Other then a change to the controller, what are the downsides of your > > suggestions?
On 28 Dez., 11:30, Fabien POTENCIER <fabien.potenc...@symfony-
project.com> wrote:
> The downsides are:
> * symfony 1.1 will take a bit longer to be released as the changes
> will need some testing
> * people will have to move their custom changes from config.php to the
> new ApplicationConfiguration class (I think this is only marginal)
> * documentation will need to be updated to reflect the changes
suggestions?
IMHO only the first point is the problem. No idea for the routing
problem? I think the event problem is not that critical..
What do you think means "a bit longer"? A week, a month, 3 months?
Anyway, it seems that the changes really make sense, so... to hell
with some more time. ;-)
Matthias N. wrote: > Anyway, it seems that the changes really make sense, so... to hell > with some more time. ;-)
I agree - even if the extra testing will take some time, I think it needs doing - these changes are pretty critical - and if they were goign to get done in sf1.2 anyway... well, we might as well :)
It makes sense to also remove the rendering filter, but we can leave it for 1.1 and make this step in 1.2 The only problem with doing it with 1.2 is people will have to upgrade their front controller to upgrade to 1.2 (the upgrade task can do it automatically).
> Can the new configuration object be included without touching the > rendering filter and the rest of the filter chain?
> Francois
> 2007/12/28, Fabien POTENCIER <fabien.potenc...@symfony-project.com>: >> The downsides are:
>> * symfony 1.1 will take a bit longer to be released as the changes >> will need some testing >> * people will have to move their custom changes from config.php to the >> new ApplicationConfiguration class (I think this is only marginal) >> * documentation will need to be updated to reflect the changes
>> Ian P. Christian wrote: >>> 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 >>> Certainly the first issue here is something that's critical to sf1.1 >>> being released - I've not played with the dispatcher in 1.1 so I can't >>> really comment on the second.
>>> Other then a change to the controller, what are the downsides of your >>> suggestions?
> On 28 Dez., 11:30, Fabien POTENCIER <fabien.potenc...@symfony- > project.com> wrote: >> The downsides are:
>> * symfony 1.1 will take a bit longer to be released as the changes >> will need some testing >> * people will have to move their custom changes from config.php to the >> new ApplicationConfiguration class (I think this is only marginal) >> * documentation will need to be updated to reflect the changes > suggestions?
> IMHO only the first point is the problem. No idea for the routing > problem? I think the event problem is not that critical.. > What do you think means "a bit longer"? A week, a month, 3 months? > Anyway, it seems that the changes really make sense, so... to hell > with some more time. ;-)
fabien.potenc...@symfony-project.com said on Friday, December 28, 2007:
>The downsides are:
> * symfony 1.1 will take a bit longer to be released as the changes >will need some testing > * people will have to move their custom changes from config.php to the >new ApplicationConfiguration class (I think this is only marginal) > * documentation will need to be updated to reflect the changes
I don't see these as significant downsides. I'd rather see you take more time and resolve these issues than have to spend time hacking around the problem in 1.1, only to do it correctly in 1.2. The changes make sense in that they seem to increase functionality as well as fixing some broken functionality. It then becomes a decision of the developers as to when they will spend the time upgrading to 1.1 or 1.2.
Thanks for all of your hard work Fabien! Much appreciated!
>Ian P. Christian wrote: >> 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
>> Certainly the first issue here is something that's critical to sf1.1 >> being released - I've not played with the dispatcher in 1.1 so I can't >> really comment on the second.
>> Other then a change to the controller, what are the downsides of your >> suggestions?
Given the benefits, the constraints seem very light.
And as it's been said before, the existence of a global Configuration
class would have a lot of good side-effects, and may solve more
problems you didn't touch yet ;)
I think it's not only a great idea, but even a needed feature ;)
On 28 déc, 15:35, Charley Tiggs <char...@cisprint.com> wrote:
> fabien.potenc...@symfony-project.com said on Friday, December 28, 2007:
> >The downsides are:
> > * symfony 1.1 will take a bit longer to be released as the changes
> >will need some testing
> > * people will have to move their custom changes from config.php to
> the
> >new ApplicationConfiguration class (I think this is only marginal)
> > * documentation will need to be updated to reflect the changes
> I don't see these as significant downsides. I'd rather see you take
> more time and resolve these issues than have to spend time hacking
> around the problem in 1.1, only to do it correctly in 1.2. The changes
> make sense in that they seem to increase functionality as well as fixing
> some broken functionality. It then becomes a decision of the developers
> as to when they will spend the time upgrading to 1.1 or 1.2.
> Thanks for all of your hard work Fabien! Much appreciated!
> >Ian P. Christian wrote:
> >> 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
> >> Certainly the first issue here is something that's critical to sf1.1
> >> being released - I've not played with the dispatcher in 1.1 so I
> can't
> >> really comment on the second.
> >> Other then a change to the controller, what are the downsides of your
> >> suggestions?
On Friday, December 28, 2007, Fabien POTENCIER wrote: > Definitely not 3 months. 1 month seems doable.
I think sfConfiguration should be implemented in 1.1. If you are going to break compatibility, this is the time to do it. And it makes the eventual upgrade to 1.2 one step easier.
All I see if very positive changes. So it delays the release a bit
longer, I think most people can live with that.
The only thing I (only slightly) worry about is that the upgrade path
will be slightly harder. Yet, even that does not seem to be very
problematic. So all I can say is: yes, go for it. :)
Stefan
On Dec 28, 7:52 am, Fabien POTENCIER <fabien.potenc...@symfony-
> 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';
> 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.
> 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';
> 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.
> +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 <fabien.potenc...@symfony- > 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:
> > 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.
+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" <threethirdsf...@googlemail.com>
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 <dustin.whit...@gmail.com> 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 <fabien.potenc...@symfony-
> > 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:
> > > 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 put it in the 1.1 release. Since you already have a solution,
the question is about timing.
I personally am waiting for Propel 1.3 but you want to give the early
adopters and plugin developers a head start.
In general do what fragments the user base least in the long run.
On Thursday, December 27, 2007, Fabien POTENCIER wrote: > 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:
Hi, Another blocking issue I've discovered (that I presume would be fixed by sfConfiguration) is that symfony serves a white screen if it cannot find a matching route for a URL. This is because an exception is thrown in the first sfContext::getInstance(), which is not in the main try/catch block.
I can create a ticket on the trac about this, but it seems like it would be automatically solved once sfConfiguration rolls in.
> 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
Hi Fabien,
Do you have any plans to make these changes soon?
I'm quite in need of them for an existing project :)
Ian P. Christian wrote: > 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
> Hi Fabien,
> Do you have any plans to make these changes soon?
> I'm quite in need of them for an existing project :)
I'm coming late to this discussion, but hope I can add a small
contribution. I've only recently started using Symfony, but I'm very
impressed so far.
On Dec 28 2007, 6:52 am, Fabien POTENCIER <fabien.potenc...@symfony-
project.com> wrote:
> ...
> 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:
> ...
This sounds a lot like the inversion of control/dependency injection
pattern. Martin Fowler wrote an excellent paper summarising the
pattern:
In short it's a way of eliminating the common situation of components
having dependencies on a framework. Instead, all dependencies are
passed as constructor arguments to components (or possibly through
setters). If the components are used within a container, then the
container manages the provision of dependencies, but the components
can also be used and tested without reference to the framework or
container.
There was a port done some time ago of PicoContainer to PHP by Pawel
Kozlowski, but I couldn't find out whether it's still actively
maintained. In any case once you've understood the pattern and the
principles then it's very easy to implement. As I said, I think you've
arrived at a very similar solution. Maybe reading Fowler's paper would
help to confirm your design decisions.
On Wed, Feb 20, 2008 at 12:51 PM, heathd <dgheat...@gmail.com> wrote: > In short it's a way of eliminating the common situation of components > having dependencies on a framework. Instead, all dependencies are > passed as constructor arguments to components (or possibly through > setters). If the components are used within a container, then the > container manages the provision of dependencies, but the components > can also be used and tested without reference to the framework or > container.
|
