On 27 Jun., 20:20, Fabien POTENCIER <[EMAIL PROTECTED]>
wrote:
> So, here is a summary of the things I changed in the trunk:
>
> - sfI18N is not a singleton anymore. This one is was really simple. The
> sfI18N wasn't really used as a singleton! The i18n object is now
> configurable in your factories.yml. No change is needed to your code.
>
> - sfRouting is not a singleton anymore. This is one was a bit more
> challenging but most of the time, you don't have to change your code.
> The only thing to check is if you use sfRouting::getInstance() in your
> code, you will have to change it to
> sfContext::getIntance()->getRouting(). The routing class is also
> configurable in the factories.yml and I implemented a simple sfNoRouting
> class as an example of a very simple routing class.
>
> - sfContext is now a multi-singleton. The getInstance() takes a name
> parameter and I implemented the switchTo() method. To be really useful,
> more work is needed (I need to de-singleton-ize sfConfig for example).
The recent changes are pretty cool.
> - You can now store your own object in the context instance:
>
> $context = sfContext::getInstance();
> $context->setObject('name', $myObject);
> $object = $context->getObject('name');
The "context object storage" is that what I wanted with my attempt to
implement "beans" from Garden. But I realized that it is too much &
too complex.
The only thing I don't like is the sfFactoryConfigHandler and the fact
that the factories(.yml) are all instantiated during initialize()
What about moving the object creation and initialization from the
foreach/switch into a factory method in the respective classes. And
only pass parameters from factories to the factory() method. Thus
these objects could be lazy loaded. For example move it into
sfRequest::factory(), sfResponse::factory(), sfController::factory(),
sfUser::factory().
This would also make it possible to cache factories.yml as array which
seems to get very important in context of making symfony faster.
I have another suggestion for 1.1 related to enhancement of the view
layer and a theme plugin I would like to contribute this August:
I would like to have "virtualization of views". What's that? Well.. I
would like to have the possibility to override/change module/action/
template at all relevant places. Not sure but I guess the places are
sfPHPView, get_partial() and get_component() helpers. I don't want to
change anything with the default behavior of loading templates but I
need a way to hook into it. I need to change template sources to
arbitrary other locations. I think the best solution for that is to
move the loading/locations of templates into a
"sfTemplateLocatorAdapter" !? Like you already did with sfRouting!
One other request is: I need a directory where I can safely place
(write) files but they must not be in web directory.. and I think they
also must not be in the cache dir. Where should I place them? Would't
it make sence to provide such a "private" data/media/whatever dir?
Regards,
Matthias
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
