symfony 1.1 : I really need everybody's opinion - symfony developers

Message from discussion symfony 1.1 : I really need everybody's opinion
MIME-Version: 1.0
Message-ID: <48226c29-0397-416a-8ec1-a6076e2b5d9e@d4g2000prg.googlegroups.com>
Date: Fri, 28 Dec 2007 01:20:46 -0800 (PST)
In-Reply-To: <47749D26.2060709@symfony-project.com>
References: <47749D26.2060709@symfony-project.com>
User-Agent: G2/1.0
Subject: Re: symfony 1.1 : I really need everybody's opinion
From: lionslair <webmas...@lionslair.net.au>
To: symfony developers <symfony-devs@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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-
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 =3D 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.sy=
mfony-project.com/
> Sensio Labs