Matthias N. wrote:
> 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.
Hmmm, this is a good idea but I think we will have some problem with the
initialization ordering. All factories are created in a first pass, then
initialized() in a second pass to satisfy dependencies. So, I'm not sure
we can move this to each object factory. I will have a look later to see
if it's posiible. Thanks for the suggestion.
>
> 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!
The View system is also one of the sub-framework I want to refactor for
1.1 or 1.2. I want to create 2 distinct layers: a view layer and a
template layer. This distinction will allow easier integration of
templating systems like phptal or smarty. The link between the view and
the template will be done via a new sfTemplateContext object. This
object will hold all the variables to be passed to the template
(instance variables from the action or the global ones created by sfView
- sf_*). It will allow the developer to inject some global variables
into the template context and to use the templating system for partial
without initializing a new view object (so, it will be much faster).
This object will also holds the helper objects... Yes, I also want to
convert helpers to classes (This is one of oldest design changes we
discussed here on the ML).
>
> 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?
The data directory is here to provide such storage. I'm not sure it
makes sense to define a sub-directory under data/. It's really up to you
and depends on your needs.
>
> 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
-~----------~----~----~----~------~----~------~--~---
