It seems the usage of the environments in config files is inconsistent. Since the configuration cache is stored based on environment, is there any reason to restrict certain files from not having support for environments? I think configuration files like filters.yml and view.yml should be customizable based on environment.
Also, there is some inconsistency with default/all. Can we change all to default for consistency?
Also, what do you think about adding database manager as a factories.yml factory? There is a view_cache factory, but I think we should add a cache factory as well (for internal caching apc/xcache/eaccellerator) and optimize some parts of the core to use apc/xcache (like caching the path lookups for finding templates + configs, or caching routing)..
Also, is it just me or could the web debug timers use a refactor? (they seem to always not add up)
On Friday, February 08, 2008, Dustin Whittle wrote: > Also, is it just me or could the web debug timers use a refactor? (they > seem to always not add up)
I think it's impossible for them to add up. I haven't looked too extensively at this part of the source, but it seems the toolbar timer is the time for the entire request and the pop down contains specific timers that can appear in various parts of the source code.
It can't add up because timers can contain other timers:
I also wanted at at least one point to have a custom view.yml for each environment so I fully agree on that and I can also see this being helpful for filters.yml. For me it is much more clear to have a all: setting rather than default: as it is more clear and I tend to use all: in all the configuration files. Are you talking about the database manager because of the Propel/Docrtine issues or? I also agree that pretty much everybody is using an op code cache and it would seem normal to start using such a cache in the core as it will speed disk lookups (by not making them :))
> It seems the usage of the environments in config files is > inconsistent. Since the configuration cache is stored based on > environment, is there any reason to restrict certain files from not > having support for environments? I think configuration files like > filters.yml and view.yml should be customizable based on environment.
> Also, there is some inconsistency with default/all. Can we change all > to default for consistency?
> Also, what do you think about adding database manager as a > factories.yml factory? There is a view_cache factory, but I think we > should add a cache factory as well (for internal caching – > apc/xcache/eaccellerator) and optimize some parts of the core to use > apc/xcache (like caching the path lookups for finding templates + > configs, or caching routing)..
> Also, is it just me or could the web debug timers use a refactor? > (they seem to always not add up)
> It seems the usage of the environments in config files is inconsistent. > Since the configuration cache is stored based on environment, is there any > reason to restrict certain files from not having support for environments? I > think configuration files like filters.yml and view.yml should be > customizable based on environment.
There is no "real" reason. I'm not sure if it makes sense to have different filters or different view configuration based on environments. But if there's a need, we can change the behavior. We will then need to write an update task to ensure a smooth upgrade.
> Also, there is some inconsistency with default/all. Can we change all to > default for consistency?
Which inconsistency? default is used in the default config files (and means the default symfony value) and all means configuration for all environments.
> Also, what do you think about adding database manager as a factories.yml > factory?
That's possible but I don't see a need for this as sfDatabaseManager is already an abstraction for database management.
> There is a view_cache factory, but I think we should add a cache > factory as well (for internal caching apc/xcache/eaccellerator)
+1
> and optimize some parts of the core to use apc/xcache (like caching the path > lookups for finding templates + configs, or caching routing)..
+1 if you use the factory which can be sfNoCache. But don't tie symfony to APC or XCache.
> Also, is it just me or could the web debug timers use a refactor? (they seem > to always not add up)
That's "normal". It's an indication of the time required by some layers, but not symfony layers.
> It seems the usage of the environments in config files is inconsistent. > Since the configuration cache is stored based on environment, is there any > reason to restrict certain files from not having support for environments? I > think configuration files like filters.yml and view.yml should be > customizable based on environment.
> Also, there is some inconsistency with default/all. Can we change all to > default for consistency?
> Also, what do you think about adding database manager as a factories.yml > factory?
After some thoughts, I don't think this is a good idea. As I said before, sfDatabaseManager is already an abstraction class. Moreover, this class is used at several places to initialize Propel. So, if you define your own class, a lot of things will break.
> There is a view_cache factory, but I think we should add a cache > factory as well (for internal caching apc/xcache/eaccellerator) and > optimize some parts of the core to use apc/xcache (like caching the path > lookups for finding templates + configs, or caching routing)..
> Also, is it just me or could the web debug timers use a refactor? (they seem > to always not add up)
>> It seems the usage of the environments in config files is inconsistent. >> Since the configuration cache is stored based on environment, is there any >> reason to restrict certain files from not having support for environments? I >> think configuration files like filters.yml and view.yml should be >> customizable based on environment.
> There is no "real" reason. I'm not sure if it makes sense to have > different filters or different view configuration based on environments. > But if there's a need, we can change the behavior. We will then need to > write an update task to ensure a smooth upgrade.
I will apply this in my branch in the next few weeks.
>> Also, there is some inconsistency with default/all. Can we change all to >> default for consistency?
> Which inconsistency? default is used in the default config files (and > means the default symfony value) and all means configuration for all > environments.
I meant the inconsistency between a config file supporting environments and not. The difference is petty, but compare cache.yml and app.yml.
>> It seems the usage of the environments in config files is inconsistent. >> Since the configuration cache is stored based on environment, is there any >> reason to restrict certain files from not having support for environments? I >> think configuration files like filters.yml and view.yml should be >> customizable based on environment.
>> Also, there is some inconsistency with default/all. Can we change all to >> default for consistency?
>> Also, what do you think about adding database manager as a factories.yml >> factory?
> After some thoughts, I don't think this is a good idea. As I said > before, sfDatabaseManager is already an abstraction class. Moreover, > this class is used at several places to initialize Propel. So, if you > define your own class, a lot of things will break.
I see what you mean. This suggestion was more about making all of the factories customizable, rather needed for a real purpose.
>> There is a view_cache factory, but I think we should add a cache >> factory as well (for internal caching apc/xcache/eaccellerator) and >> optimize some parts of the core to use apc/xcache (like caching the path >> lookups for finding templates + configs, or caching routing)..
>> Also, is it just me or could the web debug timers use a refactor? (they seem >> to always not add up)
On a sidenote im working on porting the sfErrorLogPlugin to Doctrine. It requires the serializing of the request object to work, but that means serializing the sfContext object, then the sfDatabaseManager object, and in case you are using Doctrine this leads to trying to serialize the PDO connection object, which results in a fatal error. So i could use a factory for the db manager class, to include a __sleep method.
Anyways i'll make a patch for sfDataBaseManager, and create a ticket when i'm done.
Zsolt
On 2/11/08, Dustin Whittle <dustin.whit...@symfony-project.com> wrote:
> >> It seems the usage of the environments in config files is inconsistent. > >> Since the configuration cache is stored based on environment, is there any > >> reason to restrict certain files from not having support for environments? I > >> think configuration files like filters.yml and view.yml should be > >> customizable based on environment.
> >> Also, there is some inconsistency with default/all. Can we change all to > >> default for consistency?
> >> Also, what do you think about adding database manager as a factories.yml > >> factory?
> > After some thoughts, I don't think this is a good idea. As I said > > before, sfDatabaseManager is already an abstraction class. Moreover, > > this class is used at several places to initialize Propel. So, if you > > define your own class, a lot of things will break.
> I see what you mean. This suggestion was more about making all of the > factories customizable, rather needed for a real purpose.
> >> There is a view_cache factory, but I think we should add a cache > >> factory as well (for internal caching apc/xcache/eaccellerator) and > >> optimize some parts of the core to use apc/xcache (like caching the path > >> lookups for finding templates + configs, or caching routing)..
> >> Also, is it just me or could the web debug timers use a refactor? (they seem > >> to always not add up)
I already ported sfErrorLogPlugin to Doctrine for private purposes. A different solution than yours (although a little hacky) is to override the sfWebRequest object (via factory) and add a __sleep method that unsets the associated context object.
Regards,
Bernhard
On Feb 11, 2008 9:35 AM, Zsolt Takács <zsolti...@gmail.com> wrote:
> On a sidenote im working on porting the sfErrorLogPlugin to Doctrine. > It requires the serializing of the request object to work, but that > means serializing the sfContext object, then the sfDatabaseManager > object, and in case you are using Doctrine this leads to trying to > serialize the PDO connection object, which results in a fatal error. > So i could use a factory for the db manager class, to include a > __sleep method.
> Anyways i'll make a patch for sfDataBaseManager, and create a ticket > when i'm done.
> Zsolt
> On 2/11/08, Dustin Whittle <dustin.whit...@symfony-project.com> wrote:
> > Fabien,
> > >> It seems the usage of the environments in config files is inconsistent. > > >> Since the configuration cache is stored based on environment, is there any > > >> reason to restrict certain files from not having support for environments? I > > >> think configuration files like filters.yml and view.yml should be > > >> customizable based on environment.
> > >> Also, there is some inconsistency with default/all. Can we change all to > > >> default for consistency?
> > >> Also, what do you think about adding database manager as a factories.yml > > >> factory?
> > > After some thoughts, I don't think this is a good idea. As I said > > > before, sfDatabaseManager is already an abstraction class. Moreover, > > > this class is used at several places to initialize Propel. So, if you > > > define your own class, a lot of things will break.
> > I see what you mean. This suggestion was more about making all of the > > factories customizable, rather needed for a real purpose.
> > >> There is a view_cache factory, but I think we should add a cache > > >> factory as well (for internal caching apc/xcache/eaccellerator) and > > >> optimize some parts of the core to use apc/xcache (like caching the path > > >> lookups for finding templates + configs, or caching routing)..
> > >> Also, is it just me or could the web debug timers use a refactor? (they seem > > >> to always not add up)
I'm nearly finished too, i added a __sleep method returning an empty array to sfDoctrineDatabase so i dont need to scrap the whole context. I'll submit that patch when i'll have some time (and the plugin too if the patch is accepted).
Regards,
Zs.
On 2/20/08, Bernhard Schussek <bschus...@gmail.com> wrote:
> I already ported sfErrorLogPlugin to Doctrine for private purposes. A > different solution than yours (although a little hacky) is to override > the sfWebRequest object (via factory) and add a __sleep method that > unsets the associated context object.
> Regards,
> Bernhard
> On Feb 11, 2008 9:35 AM, Zsolt Takács <zsolti...@gmail.com> wrote:
> > On a sidenote im working on porting the sfErrorLogPlugin to Doctrine. > > It requires the serializing of the request object to work, but that > > means serializing the sfContext object, then the sfDatabaseManager > > object, and in case you are using Doctrine this leads to trying to > > serialize the PDO connection object, which results in a fatal error. > > So i could use a factory for the db manager class, to include a > > __sleep method.
> > Anyways i'll make a patch for sfDataBaseManager, and create a ticket > > when i'm done.
> > Zsolt
> > On 2/11/08, Dustin Whittle <dustin.whit...@symfony-project.com> wrote:
> > > Fabien,
> > > >> It seems the usage of the environments in config files is inconsistent. > > > >> Since the configuration cache is stored based on environment, is there any > > > >> reason to restrict certain files from not having support for environments? I > > > >> think configuration files like filters.yml and view.yml should be > > > >> customizable based on environment.
> > > >> Also, there is some inconsistency with default/all. Can we change all to > > > >> default for consistency?
> > > >> Also, what do you think about adding database manager as a factories.yml > > > >> factory?
> > > > After some thoughts, I don't think this is a good idea. As I said > > > > before, sfDatabaseManager is already an abstraction class. Moreover, > > > > this class is used at several places to initialize Propel. So, if you > > > > define your own class, a lot of things will break.
> > > I see what you mean. This suggestion was more about making all of the > > > factories customizable, rather needed for a real purpose.
> > > >> There is a view_cache factory, but I think we should add a cache > > > >> factory as well (for internal caching apc/xcache/eaccellerator) and > > > >> optimize some parts of the core to use apc/xcache (like caching the path > > > >> lookups for finding templates + configs, or caching routing)..
> > > >> Also, is it just me or could the web debug timers use a refactor? (they seem > > > >> to always not add up)
