[symfony-devs] question re: include_javascripts_for_form()
Hi, I've recently created my own widget and have overriden the getJavascripts() to return an array of javascript files to support the widget. The form is used in the admin generator, and the include_javascripts_for_form() helper is used to add
[symfony-devs] Re: question re: include_javascripts_for_form()
Thanks, I'll take a look On May 28, 5:51 pm, Andrei Dziahel wrote: > Hi, Andy. > > There's a patch (http://trac.symfony-project.org/ticket/5908) but it is > still unreviewed. > > 2009/5/28 arri...@gmail.com > > > > > > > Hi, > > > I've recently created my own widget and have overriden the getJavascripts() > > to return an array of javascript files to support the widget. > > > The form is used in the admin generator, and the > > include_javascripts_for_form() helper is used to add
[symfony-devs] problem overriding webdebug toolbar
hi - i think I may have found a bug in overriding the db panel in the
web debug toolbar. I've been following
http://www.symfony-project.org/blog/2008/08/27/new-in-symfony-1-2-customize-the-web-debug-toolbar
and have created a new class, ctWebDebugPanelPropel. I want this to
replace the db panel that is already there.
public function configureWebDebugToolbar(sfEvent $event)
{
$webDebugToolbar = $event->getSubject();
$webDebugToolbar->setPanel('db', new ctWebDebugPanelPropel
($webDebugToolbar));
}
This doesn't override the panel, but keeps the original. However, if i
change the name to 'newdb' from 'db' it adds another panel with my
mods. In contrast, if i change the name to 'logs' this *does*
overwrite the logs panel and replaces it with my new panel.
Looks like the 'db' panel is added after the initial configuration,
overwriting the one that is there. Not a massive issue as I can use
the 'newdb' name to add extra panel and have 2 db panels, but it would
be nice if I could replace the existing one somehow.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: problem overriding webdebug toolbar
Thanks Fabian, this pointed me in the right direction. Now I have
overriden initialize() in my application configuration and added the
event connection there. Since I now connect the event after the propel
plugin does, my 'db' panel now overwrites the one from the propel
plugin :)
public function initialize()
{
parent::initialize();
$this->dispatcher->connect('debug.web.load_panels', array($this,
'configureWebDebugToolbar'));
}
Thanks for the help,
Andy.
On Jun 3, 10:12 am, Fabian Lange
wrote:
> Hi,
> this is because the db panel is not created by (core) symfony.
> It is created by the (core) PropelPlugin: sfWebDebugPanelPropel
>
> It listens to the debug.web.filter_logs event and then sets the DB Panel.
>
> so if you are setting the DB panel before proepl is active, propel
> overwrites you.
>
> I think this partially intended, but we might think of it being what we want
> it to be :-)
>
> Fabian
>
> On Wed, Jun 3, 2009 at 10:54 AM, arri...@gmail.com wrote:
>
>
>
> > hi - i think I may have found a bug in overriding the db panel in the
> > web debug toolbar. I've been following
>
> >http://www.symfony-project.org/blog/2008/08/27/new-in-symfony-1-2-cus...
> > and have created a new class, ctWebDebugPanelPropel. I want this to
> > replace the db panel that is already there.
>
> > public function configureWebDebugToolbar(sfEvent $event)
> > {
> > $webDebugToolbar = $event->getSubject();
> > $webDebugToolbar->setPanel('db', new ctWebDebugPanelPropel
> > ($webDebugToolbar));
> > }
>
> > This doesn't override the panel, but keeps the original. However, if i
> > change the name to 'newdb' from 'db' it adds another panel with my
> > mods. In contrast, if i change the name to 'logs' this *does*
> > overwrite the logs panel and replaces it with my new panel.
>
> > Looks like the 'db' panel is added after the initial configuration,
> > overwriting the one that is there. Not a massive issue as I can use
> > the 'newdb' name to add extra panel and have 2 db panels, but it would
> > be nice if I could replace the existing one somehow.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] new sfMailer code + web debug
Hi,
Been running the new sfMailer code, looks excellent and yesterday was
pleased to see the mail icon appearing in the web debug toolbar. Very
useful! However, after an update this morning the icon no longer
appears. A call to sfContext::getInstance()->getMailer()->compose(...)
still works ok - the mail is sent.
Looking into the mailer debug panel, it looks like inititialize() is
never called. Also, hasMailer() always returned false for me. Changing
the function to:
public function __construct(sfWebDebug $webDebug)
{
parent::__construct($webDebug);
//$this->mailer = sfContext::getInstance()->hasMailer() ?
sfContext::getInstance()->getMailer() : null;
$this->mailer = sfContext::getInstance()->getMailer();
}
resolves the issue for me, but I see in the commit logs there was
concern over errors with apps using swiftmail 3 and hasMailer() was
introduced.
I appreciate this is alpha code and things are changing, but any
ideas?
Thanks,
Andy.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: new sfMailer code + web debug
Hi, I had tried this by copying the whole mailer: section from symfony/
lib/config/config/factories.yml, but the icon still didn't appear. I
added the 'cut down' lines from the changeset under the all: section
of my factories.yml but the icon still doesn't appear sorry.
On Sep 10, 2:56 pm, Fabian Lange
wrote:
> Hi,
> you need to add the mailer to the factories.
> This is documented here:http://trac.symfony-project.org/changeset/21832
>
> Fabian
>
> On Thu, Sep 10, 2009 at 2:37 PM, arri...@gmail.com wrote:
>
> > Hi,
>
> > Been running the new sfMailer code, looks excellent and yesterday was
> > pleased to see the mail icon appearing in the web debug toolbar. Very
> > useful! However, after an update this morning the icon no longer
> > appears. A call to sfContext::getInstance()->getMailer()->compose(...)
> > still works ok - the mail is sent.
>
> > Looking into the mailer debug panel, it looks like inititialize() is
> > never called. Also, hasMailer() always returned false for me. Changing
> > the function to:
>
> > public function __construct(sfWebDebug $webDebug)
> > {
> > parent::__construct($webDebug);
> > //$this->mailer = sfContext::getInstance()->hasMailer() ?
> > sfContext::getInstance()->getMailer() : null;
> > $this->mailer = sfContext::getInstance()->getMailer();
> > }
>
> > resolves the issue for me, but I see in the commit logs there was
> > concern over errors with apps using swiftmail 3 and hasMailer() was
> > introduced.
>
> > I appreciate this is alpha code and things are changing, but any
> > ideas?
>
> > Thanks,
> > Andy.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: new sfMailer code + web debug
To followup, in my action var_dump($this->getContext()->hasMailer());
returns false
On Sep 10, 3:26 pm, "arri...@gmail.com" wrote:
> Hi, I had tried this by copying the whole mailer: section from symfony/
> lib/config/config/factories.yml, but the icon still didn't appear. I
> added the 'cut down' lines from the changeset under the all: section
> of my factories.yml but the icon still doesn't appear sorry.
>
> On Sep 10, 2:56 pm, Fabian Lange
> wrote:
>
> > Hi,
> > you need to add the mailer to the factories.
> > This is documented here:http://trac.symfony-project.org/changeset/21832
>
> > Fabian
>
> > On Thu, Sep 10, 2009 at 2:37 PM, arri...@gmail.com
> > wrote:
>
> > > Hi,
>
> > > Been running the new sfMailer code, looks excellent and yesterday was
> > > pleased to see the mail icon appearing in the web debug toolbar. Very
> > > useful! However, after an update this morning the icon no longer
> > > appears. A call to sfContext::getInstance()->getMailer()->compose(...)
> > > still works ok - the mail is sent.
>
> > > Looking into the mailer debug panel, it looks like inititialize() is
> > > never called. Also, hasMailer() always returned false for me. Changing
> > > the function to:
>
> > > public function __construct(sfWebDebug $webDebug)
> > > {
> > > parent::__construct($webDebug);
> > > //$this->mailer = sfContext::getInstance()->hasMailer() ?
> > > sfContext::getInstance()->getMailer() : null;
> > > $this->mailer = sfContext::getInstance()->getMailer();
> > > }
>
> > > resolves the issue for me, but I see in the commit logs there was
> > > concern over errors with apps using swiftmail 3 and hasMailer() was
> > > introduced.
>
> > > I appreciate this is alpha code and things are changing, but any
> > > ideas?
>
> > > Thanks,
> > > Andy.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: new sfMailer code + web debug
After a bit of poking around, the bottom of my cached copy of the
factories.yml (config_factories.yml.php) looks like below. Looks like
there is no $this->factories['mailer'] = ... line
$this->factories['viewCacheManager'] = new sfViewCacheManager
($this, $cache);
}
else
{
$this->factories['viewCacheManager'] = null;
}
require_once sfConfig::get('sf_symfony_lib_dir').'/vendor/swiftmailer/
classes/Swift/Mailer.php';
spl_autoload_register(array('sfMailer', 'autoload'));
$this->setMailerConfiguration(array_merge(array('class' =>
sfConfig::get('sf_factory_mailer', 'sfMailer')), sfConfig::get
('sf_factor
y_mailer_parameters', array (
'logging' => '1',
'charset' => 'utf-8',
'delivery_strategy' => 'none',
'transport' =>
array (
'class' => 'Swift_SmtpTransport',
'param' =>
array (
'host' => 'localhost',
'port' => 25,
'encryption' => NULL,
'username' => NULL,
'password' => NULL,
),
),
;
On Sep 10, 3:30 pm, "arri...@gmail.com" wrote:
> To followup, in my action var_dump($this->getContext()->hasMailer());
> returns false
>
> On Sep 10, 3:26 pm, "arri...@gmail.com" wrote:
>
> > Hi, I had tried this by copying the whole mailer: section from symfony/
> > lib/config/config/factories.yml, but the icon still didn't appear. I
> > added the 'cut down' lines from the changeset under the all: section
> > of my factories.yml but the icon still doesn't appear sorry.
>
> > On Sep 10, 2:56 pm, Fabian Lange
> > wrote:
>
> > > Hi,
> > > you need to add the mailer to the factories.
> > > This is documented here:http://trac.symfony-project.org/changeset/21832
>
> > > Fabian
>
> > > On Thu, Sep 10, 2009 at 2:37 PM, arri...@gmail.com
> > > wrote:
>
> > > > Hi,
>
> > > > Been running the new sfMailer code, looks excellent and yesterday was
> > > > pleased to see the mail icon appearing in the web debug toolbar. Very
> > > > useful! However, after an update this morning the icon no longer
> > > > appears. A call to sfContext::getInstance()->getMailer()->compose(...)
> > > > still works ok - the mail is sent.
>
> > > > Looking into the mailer debug panel, it looks like inititialize() is
> > > > never called. Also, hasMailer() always returned false for me. Changing
> > > > the function to:
>
> > > > public function __construct(sfWebDebug $webDebug)
> > > > {
> > > > parent::__construct($webDebug);
> > > > //$this->mailer = sfContext::getInstance()->hasMailer() ?
> > > > sfContext::getInstance()->getMailer() : null;
> > > > $this->mailer = sfContext::getInstance()->getMailer();
> > > > }
>
> > > > resolves the issue for me, but I see in the commit logs there was
> > > > concern over errors with apps using swiftmail 3 and hasMailer() was
> > > > introduced.
>
> > > > I appreciate this is alpha code and things are changing, but any
> > > > ideas?
>
> > > > Thanks,
> > > > Andy.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: new sfMailer code + web debug
Hi,
Unfortunately I still don't get the icon. As far as I can see,
listenForMailerConfigure() doesn't get called? I stuck a die() in
there but my code still ran.
Thanks for your help,
Andy.
On Sep 10, 4:45 pm, Kris Wallsmith wrote:
> Hello,
>
> I've fixed the regression I introduced yesterday. Can you see if the
> icon show up for you now?
>
> Thanks,
> Kris
>
> --
>
> Kris Wallsmith | Release Manager
> kris.wallsm...@symfony-project.com
> Portland, Oregon USA
>
> http://twitter.com/kriswallsmith
>
> On Sep 10, 2009, at 7:43 AM, arri...@gmail.com wrote:
>
>
>
> > After a bit of poking around, the bottom of my cached copy of the
> > factories.yml (config_factories.yml.php) looks like below. Looks like
> > there is no $this->factories['mailer'] = ... line
>
> >
> > $this->factories['viewCacheManager'] = new sfViewCacheManager
> > ($this, $cache);
> > }
> > else
> > {
> > $this->factories['viewCacheManager'] = null;
> > }
>
> > require_once sfConfig::get('sf_symfony_lib_dir').'/vendor/swiftmailer/
> > classes/Swift/Mailer.php';
> > spl_autoload_register(array('sfMailer', 'autoload'));
> > $this->setMailerConfiguration(array_merge(array('class' =>
> > sfConfig::get('sf_factory_mailer', 'sfMailer')), sfConfig::get
> > ('sf_factor
> > y_mailer_parameters', array (
> > 'logging' => '1',
> > 'charset' => 'utf-8',
> > 'delivery_strategy' => 'none',
> > 'transport' =>
> > array (
> > 'class' => 'Swift_SmtpTransport',
> > 'param' =>
> > array (
> > 'host' => 'localhost',
> > 'port' => 25,
> > 'encryption' => NULL,
> > 'username' => NULL,
> > 'password' => NULL,
> > ),
> > ),
> > ;
>
> > On Sep 10, 3:30 pm, "arri...@gmail.com" wrote:
> >> To followup, in my action var_dump($this->getContext()->hasMailer());
> >> returns false
>
> >> On Sep 10, 3:26 pm, "arri...@gmail.com" wrote:
>
> >>> Hi, I had tried this by copying the whole mailer: section from
> >>> symfony/
> >>> lib/config/config/factories.yml, but the icon still didn't appear. I
> >>> added the 'cut down' lines from the changeset under the all: section
> >>> of my factories.yml but the icon still doesn't appear sorry.
>
> >>> On Sep 10, 2:56 pm, Fabian Lange
> >>> wrote:
>
> >>>> Hi,
> >>>> you need to add the mailer to the factories.
> >>>> This is documented here:http://trac.symfony-project.org/changeset/
> >>>> 21832
>
> >>>> Fabian
>
> >>>> On Thu, Sep 10, 2009 at 2:37 PM, arri...@gmail.com
> >>>> wrote:
>
> >>>>> Hi,
>
> >>>>> Been running the new sfMailer code, looks excellent and
> >>>>> yesterday was
> >>>>> pleased to see the mail icon appearing in the web debug toolbar.
> >>>>> Very
> >>>>> useful! However, after an update this morning the icon no longer
> >>>>> appears. A call to sfContext::getInstance()->getMailer()->compose
> >>>>> (...)
> >>>>> still works ok - the mail is sent.
>
> >>>>> Looking into the mailer debug panel, it looks like inititialize
> >>>>> () is
> >>>>> never called. Also, hasMailer() always returned false for me.
> >>>>> Changing
> >>>>> the function to:
>
> >>>>> public function __construct(sfWebDebug $webDebug)
> >>>>> {
> >>>>> parent::__construct($webDebug);
> >>>>> //$this->mailer = sfContext::getInstance()->hasMailer() ?
> >>>>> sfContext::getInstance()->getMailer() : null;
> >>>>> $this->mailer = sfContext::getInstance()->getMailer();
> >>>>> }
>
> >>>>> resolves the issue for me, but I see in the commit logs there was
> >>>>> concern over errors with apps using swiftmail 3 and hasMailer()
> >>>>> was
> >>>>> introduced.
>
> >>>>> I appreciate this is alpha code and things are changing, but any
> >>>>> ideas?
>
> >>>>> Thanks,
> >>>>> Andy.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] 1.3 - admin generator sfException
hi,
Using 1.3 branch, the admin generator (for propel at least) is
currently broken. see (snipped) stack trace below. Problem is
doConvertObjectToArray() in sfPropelRoute class.
...
try
{
$method = 'get'.call_user_func(array($className,
'translateFieldName'), $variable, BasePeer::TYPE_FIELDNAME,
BasePeer::TYPE_PHPNAME);
}
...
$classname is the object class and not the Peer class, so
translateFieldName fails.
Appending "Peer" to $classname before the call resolves the issue for
me, but no idea if this is 'correct' fix!
Thanks,
Andy
# at sfOutputEscaperGetterDecorator->get()
in SF_ROOT_DIR\lib\vendor\symfony\lib\plugins\sfPropelPlugin\lib
\routing\sfPropelRoute.class.php line 110 ...
107. $method = 'get'.sfInflector::camelize($variable);
108. }
109.
110. $parameters[$variable] = $object->$method();
111. }
112.
113. return $parameters;
# at sfPropelRoute->doConvertObjectToArray(object
('sfOutputEscaperObjectDecorator'))
in SF_ROOT_DIR\lib\vendor\symfony\lib\routing\sfObjectRoute.class.php
line 214 ...
211. $parameters = array();
212. }
213.
214. return array_merge($parameters, $this-
>doConvertObjectToArray($object));
215. }
216.
217. protected function doConvertObjectToArray($object)
# at sfObjectRoute->convertObjectToArray(array('sf_subject' => object
('sfOutputEscaperObjectDecorator')))
in SF_ROOT_DIR\lib\vendor\symfony\lib\routing\sfObjectRoute.class.php
line 81 ...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] sfYaml commit has broken symfony 1.3 checkout
Hi,
Commit http://trac.symfony-project.org/changeset/21883 for sfYaml has
broken a checkout of symfony 1.3 (not checked other versions) as
values set to 'off' for example are no longer converted to a boolean
value. e.g. sfConfig::get('mod_'.strtolower
($moduleName).'_is_internal') returns "off" which evaluates to true.
This makes the controller stop all actions as it thinks they are
internal.
Just thought you should know...
Cheers,
Andy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: sfYaml commit has broken symfony 1.3 checkout
OK, seen the note in the UPGRADE file now - will work to resolve.
Thanks,
Andy
On Sep 11, 9:07 am, "arri...@gmail.com" wrote:
> Hi,
>
> Commithttp://trac.symfony-project.org/changeset/21883for sfYaml has
> broken a checkout of symfony 1.3 (not checked other versions) as
> values set to 'off' for example are no longer converted to a boolean
> value. e.g. sfConfig::get('mod_'.strtolower
> ($moduleName).'_is_internal') returns "off" which evaluates to true.
> This makes the controller stop all actions as it thinks they are
> internal.
>
> Just thought you should know...
>
> Cheers,
> Andy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: sfYaml commit has broken symfony 1.3 checkout
Thanks Fabien, all sorted now
On Sep 11, 9:14 am, Fabien Potencier wrote:
> Running the project:upgrade will tell you the files you need to change.
>
> Fabien
>
> --
> Fabien Potencier
> Sensio CEO - symfony lead developer
> sensiolabs.com | symfony-project.org | fabien.potencier.org
> Tél: +33 1 40 99 80 80
>
> arri...@gmail.com wrote:
> > OK, seen the note in the UPGRADE file now - will work to resolve.
>
> > Thanks,
> > Andy
>
> > On Sep 11, 9:07 am, "arri...@gmail.com" wrote:
> >> Hi,
>
> >> Commithttp://trac.symfony-project.org/changeset/21883forsfYaml has
> >> broken a checkout of symfony 1.3 (not checked other versions) as
> >> values set to 'off' for example are no longer converted to a boolean
> >> value. e.g. sfConfig::get('mod_'.strtolower
> >> ($moduleName).'_is_internal') returns "off" which evaluates to true.
> >> This makes the controller stop all actions as it thinks they are
> >> internal.
>
> >> Just thought you should know...
>
> >> Cheers,
> >> Andy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: 1.3 - admin generator sfException
i think this might be related to the recent routing mods - for more
info, our cache is still enabled for this. Not sure if that would
affect it.
On Sep 10, 9:53 pm, "arri...@gmail.com" wrote:
> hi,
>
> Using 1.3 branch, the admin generator (for propel at least) is
> currently broken. see (snipped) stack trace below. Problem is
> doConvertObjectToArray() in sfPropelRoute class.
>
> ...
> try
> {
> $method = 'get'.call_user_func(array($className,
> 'translateFieldName'), $variable, BasePeer::TYPE_FIELDNAME,
> BasePeer::TYPE_PHPNAME);}
>
> ...
>
> $classname is the object class and not the Peer class, so
> translateFieldName fails.
>
> Appending "Peer" to $classname before the call resolves the issue for
> me, but no idea if this is 'correct' fix!
>
> Thanks,
> Andy
>
> # at sfOutputEscaperGetterDecorator->get()
> in SF_ROOT_DIR\lib\vendor\symfony\lib\plugins\sfPropelPlugin\lib
> \routing\sfPropelRoute.class.php line 110 ...
>
> 107. $method = 'get'.sfInflector::camelize($variable);
> 108. }
> 109.
> 110. $parameters[$variable] = $object->$method();
> 111. }
> 112.
> 113. return $parameters;
>
> # at sfPropelRoute->doConvertObjectToArray(object
> ('sfOutputEscaperObjectDecorator'))
> in SF_ROOT_DIR\lib\vendor\symfony\lib\routing\sfObjectRoute.class.php
> line 214 ...
>
> 211. $parameters = array();
> 212. }
> 213.
> 214. return array_merge($parameters,
> $this->doConvertObjectToArray($object));
>
> 215. }
> 216.
> 217. protected function doConvertObjectToArray($object)
>
> # at sfObjectRoute->convertObjectToArray(array('sf_subject' => object
> ('sfOutputEscaperObjectDecorator')))
> in SF_ROOT_DIR\lib\vendor\symfony\lib\routing\sfObjectRoute.class.php
> line 81 ...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: new sfMailer code + web debug
Ah, thanks Kris - previously it was showing with a 0 - never thought
to try sending an email to see if that caused it to show!
On Sep 11, 12:35 pm, Kris Wallsmith wrote:
> You should not see the mailer panel show up with a zero (0), just as
> you don't see the database panel show up with a zero. This is the
> existing standard; I don't see any reason to change it for this panel...
>
> --
>
> Kris Wallsmith | Release Manager
> kris.wallsm...@symfony-project.com
> Portland, Oregon USA
>
> http://twitter.com/kriswallsmith
>
> On Sep 10, 2009, at 8:56 AM, arri...@gmail.com wrote:
>
>
>
> > Hi,
>
> > Unfortunately I still don't get the icon. As far as I can see,
> > listenForMailerConfigure() doesn't get called? I stuck a die() in
> > there but my code still ran.
>
> > Thanks for your help,
> > Andy.
>
> > On Sep 10, 4:45 pm, Kris Wallsmith > project.com> wrote:
> >> Hello,
>
> >> I've fixed the regression I introduced yesterday. Can you see if the
> >> icon show up for you now?
>
> >> Thanks,
> >> Kris
>
> >> --
>
> >> Kris Wallsmith | Release Manager
> >> kris.wallsm...@symfony-project.com
> >> Portland, Oregon USA
>
> >>http://twitter.com/kriswallsmith
>
> >> On Sep 10, 2009, at 7:43 AM, arri...@gmail.com wrote:
>
> >>> After a bit of poking around, the bottom of my cached copy of the
> >>> factories.yml (config_factories.yml.php) looks like below. Looks
> >>> like
> >>> there is no $this->factories['mailer'] = ... line
>
> >>>
> >>> $this->factories['viewCacheManager'] = new sfViewCacheManager
> >>> ($this, $cache);
> >>> }
> >>> else
> >>> {
> >>> $this->factories['viewCacheManager'] = null;
> >>> }
>
> >>> require_once sfConfig::get('sf_symfony_lib_dir').'/vendor/
> >>> swiftmailer/
> >>> classes/Swift/Mailer.php';
> >>> spl_autoload_register(array('sfMailer', 'autoload'));
> >>> $this->setMailerConfiguration(array_merge(array('class' =>
> >>> sfConfig::get('sf_factory_mailer', 'sfMailer')), sfConfig::get
> >>> ('sf_factor
> >>> y_mailer_parameters', array (
> >>> 'logging' => '1',
> >>> 'charset' => 'utf-8',
> >>> 'delivery_strategy' => 'none',
> >>> 'transport' =>
> >>> array (
> >>> 'class' => 'Swift_SmtpTransport',
> >>> 'param' =>
> >>> array (
> >>> 'host' => 'localhost',
> >>> 'port' => 25,
> >>> 'encryption' => NULL,
> >>> 'username' => NULL,
> >>> 'password' => NULL,
> >>> ),
> >>> ),
> >>> ;
>
> >>> On Sep 10, 3:30 pm, "arri...@gmail.com" wrote:
> >>>> To followup, in my action var_dump($this->getContext()->hasMailer
> >>>> ());
> >>>> returns false
>
> >>>> On Sep 10, 3:26 pm, "arri...@gmail.com" wrote:
>
> >>>>> Hi, I had tried this by copying the whole mailer: section from
> >>>>> symfony/
> >>>>> lib/config/config/factories.yml, but the icon still didn't
> >>>>> appear. I
> >>>>> added the 'cut down' lines from the changeset under the all:
> >>>>> section
> >>>>> of my factories.yml but the icon still doesn't appear sorry.
>
> >>>>> On Sep 10, 2:56 pm, Fabian Lange >>>>> project.com>
> >>>>> wrote:
>
> >>>>>> Hi,
> >>>>>> you need to add the mailer to the factories.
> >>>>>> This is documented here:http://trac.symfony-project.org/
> >>>>>> changeset/
> >>>>>> 21832
>
> >>>>>> Fabian
>
> >>>>>> On Thu, Sep 10, 2009 at 2:37 PM, arri...@gmail.com
> >>>>>> wrote:
>
> >>>>>>> Hi,
>
> >>>>>>> Been running the new sfMailer code, looks excellent and
> >>>>>>> yesterday was
> >>>>>>> pleased to see the mail icon appearing in the web debug toolbar.
> >>>>>>> Very
> >>>>>>> useful! However, after an update this morning the icon no longer
> >>>>>>> appears. A call to sfContext::getInstance()->getMailer()-
> >>>>>>> >compose
> >>>>>>> (...)
> >>>>>>> still works ok - the mail is sent.
>
> >>>>>>> Looking into the mailer debug panel, it looks like inititialize
> >>>>>>> () is
> >>>>>>> never called. Also, hasMailer() always returned false for me.
> >>>>>>> Changing
> >>>>>>> the function to:
>
> >>>>>>> public function __construct(sfWebDebug $webDebug)
> >>>>>>> {
> >>>>>>> parent::__construct($webDebug);
> >>>>>>> //$this->mailer = sfContext::getInstance()->hasMailer() ?
> >>>>>>> sfContext::getInstance()->getMailer() : null;
> >>>>>>> $this->mailer = sfContext::getInstance()->getMailer();
> >>>>>>> }
>
> >>>>>>> resolves the issue for me, but I see in the commit logs there
> >>>>>>> was
> >>>>>>> concern over errors with apps using swiftmail 3 and hasMailer()
> >>>>>>> was
> >>>>>>> introduced.
>
> >>>>>>> I appreciate this is alpha code and things are changing, but any
> >>>>>>> ideas?
>
> >>>>>>> Thanks,
> >>>>>>> Andy.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: 1.3 - admin generator sfException
Hi,
Yes, using 1.3 as of revision 21907 - we like bleeding edge here :)
On Sep 11, 12:05 pm, Fabien Potencier wrote:
> Are you using the latest version of 1.3. As I think I have fixed this
> issue yesterday.
>
> Fabien
>
> --
> Fabien Potencier
> Sensio CEO - symfony lead developer
> sensiolabs.com | symfony-project.org | fabien.potencier.org
> Tél: +33 1 40 99 80 80
>
> arri...@gmail.com wrote:
> > i think this might be related to the recent routing mods - for more
> > info, our cache is still enabled for this. Not sure if that would
> > affect it.
>
> > On Sep 10, 9:53 pm, "arri...@gmail.com" wrote:
> >> hi,
>
> >> Using 1.3 branch, the admin generator (for propel at least) is
> >> currently broken. see (snipped) stack trace below. Problem is
> >> doConvertObjectToArray() in sfPropelRoute class.
>
> >> ...
> >> try
> >> {
> >> $method = 'get'.call_user_func(array($className,
> >> 'translateFieldName'), $variable, BasePeer::TYPE_FIELDNAME,
> >> BasePeer::TYPE_PHPNAME);}
>
> >> ...
>
> >> $classname is the object class and not the Peer class, so
> >> translateFieldName fails.
>
> >> Appending "Peer" to $classname before the call resolves the issue for
> >> me, but no idea if this is 'correct' fix!
>
> >> Thanks,
> >> Andy
>
> >> # at sfOutputEscaperGetterDecorator->get()
> >> in SF_ROOT_DIR\lib\vendor\symfony\lib\plugins\sfPropelPlugin\lib
> >> \routing\sfPropelRoute.class.php line 110 ...
>
> >> 107. $method = 'get'.sfInflector::camelize($variable);
> >> 108. }
> >> 109.
> >> 110. $parameters[$variable] = $object->$method();
> >> 111. }
> >> 112.
> >> 113. return $parameters;
>
> >> # at sfPropelRoute->doConvertObjectToArray(object
> >> ('sfOutputEscaperObjectDecorator'))
> >> in SF_ROOT_DIR\lib\vendor\symfony\lib\routing\sfObjectRoute.class.php
> >> line 214 ...
>
> >> 211. $parameters = array();
> >> 212. }
> >> 213.
> >> 214. return array_merge($parameters,
> >> $this->doConvertObjectToArray($object));
>
> >> 215. }
> >> 216.
> >> 217. protected function doConvertObjectToArray($object)
>
> >> # at sfObjectRoute->convertObjectToArray(array('sf_subject' => object
> >> ('sfOutputEscaperObjectDecorator')))
> >> in SF_ROOT_DIR\lib\vendor\symfony\lib\routing\sfObjectRoute.class.php
> >> line 81 ...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: new sfMailer code + web debug
Just to confirm this is working fine now that I actually send a
message. Feel a bit silly :)
Thanks for your help,
Andy.
On Sep 11, 12:40 pm, "arri...@gmail.com" wrote:
> Ah, thanks Kris - previously it was showing with a 0 - never thought
> to try sending an email to see if that caused it to show!
>
> On Sep 11, 12:35 pm, Kris Wallsmith
> project.com> wrote:
> > You should not see the mailer panel show up with a zero (0), just as
> > you don't see the database panel show up with a zero. This is the
> > existing standard; I don't see any reason to change it for this panel...
>
> > --
>
> > Kris Wallsmith | Release Manager
> > kris.wallsm...@symfony-project.com
> > Portland, Oregon USA
>
> >http://twitter.com/kriswallsmith
>
> > On Sep 10, 2009, at 8:56 AM, arri...@gmail.com wrote:
>
> > > Hi,
>
> > > Unfortunately I still don't get the icon. As far as I can see,
> > > listenForMailerConfigure() doesn't get called? I stuck a die() in
> > > there but my code still ran.
>
> > > Thanks for your help,
> > > Andy.
>
> > > On Sep 10, 4:45 pm, Kris Wallsmith > > project.com> wrote:
> > >> Hello,
>
> > >> I've fixed the regression I introduced yesterday. Can you see if the
> > >> icon show up for you now?
>
> > >> Thanks,
> > >> Kris
>
> > >> --
>
> > >> Kris Wallsmith | Release Manager
> > >> kris.wallsm...@symfony-project.com
> > >> Portland, Oregon USA
>
> > >>http://twitter.com/kriswallsmith
>
> > >> On Sep 10, 2009, at 7:43 AM, arri...@gmail.com wrote:
>
> > >>> After a bit of poking around, the bottom of my cached copy of the
> > >>> factories.yml (config_factories.yml.php) looks like below. Looks
> > >>> like
> > >>> there is no $this->factories['mailer'] = ... line
>
> > >>>
> > >>> $this->factories['viewCacheManager'] = new sfViewCacheManager
> > >>> ($this, $cache);
> > >>> }
> > >>> else
> > >>> {
> > >>> $this->factories['viewCacheManager'] = null;
> > >>> }
>
> > >>> require_once sfConfig::get('sf_symfony_lib_dir').'/vendor/
> > >>> swiftmailer/
> > >>> classes/Swift/Mailer.php';
> > >>> spl_autoload_register(array('sfMailer', 'autoload'));
> > >>> $this->setMailerConfiguration(array_merge(array('class' =>
> > >>> sfConfig::get('sf_factory_mailer', 'sfMailer')), sfConfig::get
> > >>> ('sf_factor
> > >>> y_mailer_parameters', array (
> > >>> 'logging' => '1',
> > >>> 'charset' => 'utf-8',
> > >>> 'delivery_strategy' => 'none',
> > >>> 'transport' =>
> > >>> array (
> > >>> 'class' => 'Swift_SmtpTransport',
> > >>> 'param' =>
> > >>> array (
> > >>> 'host' => 'localhost',
> > >>> 'port' => 25,
> > >>> 'encryption' => NULL,
> > >>> 'username' => NULL,
> > >>> 'password' => NULL,
> > >>> ),
> > >>> ),
> > >>> ;
>
> > >>> On Sep 10, 3:30 pm, "arri...@gmail.com" wrote:
> > >>>> To followup, in my action var_dump($this->getContext()->hasMailer
> > >>>> ());
> > >>>> returns false
>
> > >>>> On Sep 10, 3:26 pm, "arri...@gmail.com" wrote:
>
> > >>>>> Hi, I had tried this by copying the whole mailer: section from
> > >>>>> symfony/
> > >>>>> lib/config/config/factories.yml, but the icon still didn't
> > >>>>> appear. I
> > >>>>> added the 'cut down' lines from the changeset under the all:
> > >>>>> section
> > >>>>> of my factories.yml but the icon still doesn't appear sorry.
>
> > >>>>> On Sep 10, 2:56 pm, Fabian Lange > >>>>> project.com>
> > >>>>> wrote:
>
> >
[symfony-devs] Re: 1.3 - admin generator sfException
Thanks Fabien, yes that's fixed it. I didn't see your previous email
until now, so have not created a ticket for it.
Thanks for your help,
Andy
On Sep 11, 3:59 pm, Fabien Potencier wrote:
> I think it's fixed now.
>
> Fabien
>
> --
> Fabien Potencier
> Sensio CEO - symfony lead developer
> sensiolabs.com | symfony-project.org | fabien.potencier.org
> Tél: +33 1 40 99 80 80
>
> arri...@gmail.com wrote:
> > i think this might be related to the recent routing mods - for more
> > info, our cache is still enabled for this. Not sure if that would
> > affect it.
>
> > On Sep 10, 9:53 pm, "arri...@gmail.com" wrote:
> >> hi,
>
> >> Using 1.3 branch, the admin generator (for propel at least) is
> >> currently broken. see (snipped) stack trace below. Problem is
> >> doConvertObjectToArray() in sfPropelRoute class.
>
> >> ...
> >> try
> >> {
> >> $method = 'get'.call_user_func(array($className,
> >> 'translateFieldName'), $variable, BasePeer::TYPE_FIELDNAME,
> >> BasePeer::TYPE_PHPNAME);}
>
> >> ...
>
> >> $classname is the object class and not the Peer class, so
> >> translateFieldName fails.
>
> >> Appending "Peer" to $classname before the call resolves the issue for
> >> me, but no idea if this is 'correct' fix!
>
> >> Thanks,
> >> Andy
>
> >> # at sfOutputEscaperGetterDecorator->get()
> >> in SF_ROOT_DIR\lib\vendor\symfony\lib\plugins\sfPropelPlugin\lib
> >> \routing\sfPropelRoute.class.php line 110 ...
>
> >> 107. $method = 'get'.sfInflector::camelize($variable);
> >> 108. }
> >> 109.
> >> 110. $parameters[$variable] = $object->$method();
> >> 111. }
> >> 112.
> >> 113. return $parameters;
>
> >> # at sfPropelRoute->doConvertObjectToArray(object
> >> ('sfOutputEscaperObjectDecorator'))
> >> in SF_ROOT_DIR\lib\vendor\symfony\lib\routing\sfObjectRoute.class.php
> >> line 214 ...
>
> >> 211. $parameters = array();
> >> 212. }
> >> 213.
> >> 214. return array_merge($parameters,
> >> $this->doConvertObjectToArray($object));
>
> >> 215. }
> >> 216.
> >> 217. protected function doConvertObjectToArray($object)
>
> >> # at sfObjectRoute->convertObjectToArray(array('sf_subject' => object
> >> ('sfOutputEscaperObjectDecorator')))
> >> in SF_ROOT_DIR\lib\vendor\symfony\lib\routing\sfObjectRoute.class.php
> >> line 81 ...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] routing performance issue 1.3 (prob 1.2 too)
Hi.
Noticed the routing has had performance changes in 1.3 which is great.
The cache is now recommended to be off but we have a severe impact on
our system if we do that.
Would like to open a discussion re: possible improvement if this is
ok.
We have lots of routes - our app is built around admin generator and
therefore sfPropelRouteCollection. The routing performance changes in
1.3 appear to be when loading routes, but the performance penalty for
our app is when matching a route i.e. url_for().
e.g. below is output from xhprof
Current Function
sfPatternRouting::getRouteThatMatchesParameters 56 0.1% 1,360,102
82.9%
Exclusive Metrics for Current Function 173,620 12.8%
Parent function
sfPatternRouting::generate 56 100.0% 1,360,102 100.0%
Child functions
sfObjectRoute::matchesParameters 22,455 48.5% 1,115,255 82.0%
sfRoute::setDefaultParameters 23,148 50.0% 50,048 3.7%
sfRoute::matchesParameters 693 1.5% 21,179 1.6%
Bit difficult to read sorry, but basically
sfPatternRouting::getRouteThatMatchesParameters() is called 56 times
(for the 56 links we have) but it takes 1.3 seconds to execute this
code. This is on athlon x2 4600+.
The problem seems to be that sfObjectRoute::matchesParameters() is
called 22,455 times taking 1.1 seconds of the total time.
OK, so if we enable the file cache we get good speeds again, however
the problem is the amount of data in this cache. Because we have so
many routes and are using admin gen, we hit this problem:
route is
supplier:
class: sfPropelRouteCollection
options:
model: Supplier
module: supplier
prefix_path: supplier
with_wildcard_routes: true
if we have 1000 suppliers, we get an entry in the routing cache for
each of these urls. Also, in the layout of the pages we have menu
links. e.g. menu/admin, menu/stock. (there's approx 100 of these)
The problem is, because the url is supplier/1/edit, supplier/2/edit,
supplier/3/edit the context when generating the cache key is different
because the uri changes. This means for every supplier, we also have
all the menu links stored in the cache for that instance of supplier.
So in the cache we have 1,000*100 = 100,000 entries in the cache - and
that is for one module (we currently have 64 admin generated modules +
30 odd non-admin gen). e.g. our routing cache contains this:
["parse_/supplier/1/edit_2ed71130b65896bc589714492c3cc85c"]=>
array(3) {
...
["parse_/supplier/2/edit_8179119534b860346bafa3dedb2bad53"]=>
array(3) {
...
["parse_/supplier/3/edit_118c94f897cfc7ae68a124e8dd692f4a"]=>
array(3) {
and
["generate_logout_e4ed1a882c44f3cf31e7ed18e8686b65_516891fa3258fae54e8eaed2b2727dcb"]
=>
string(7) "/logout"
...
["generate_logout_e4ed1a882c44f3cf31e7ed18e8686b65_54e6d2c24d12203af92e3f785f1a567d"]
=>
string(7) "/logout"
...
["generate_logout_e4ed1a882c44f3cf31e7ed18e8686b65_2ed71130b65896bc589714492c3cc85c"]
=>
string(7) "/logout"
i.e. a application "logout" link for each of the 3 supplier pages I
have just visited - the last md5 is different for each one (different
context)
Other concern is the size of the data will get so large that the
overhead of read/unserialize()/serialize()/write() will cause a large
performance penalty.
Specifying each route by name is an option, though not one I wish to
go down if possible - plus I don't think it will correct the 'size of
data' issue.
Possible solution (though I do not understand the routing enough) but
is it possible to not generate the cache key on the parameter values,
but just on the parameter keys? so, md5(serialize(array_keys
($params))) instead. Or can the value of a param determine a different
route? Similarly, is it possible for the context to not include the
uri, or use the internal uri instead of real one e.g. supplier/:id/
edit - that way the context would be the same regardless of id.
Hope this makes sense. I'm sure it's not an easy one to resolve...
Thanks,
Andy.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] question re: trac #4822
Hi, http://trac.symfony-project.org/ticket/4822 - I notice that this ticket has been closed in the last few days, however I was expecting the same feature in sfPropelPlugin for 1.3. As far as I can tell this hasn't been implemented. Is there a reason for this? We were looking forward to this useful feature for propel forms too. If it's a time issue I may be able to work to submit a patch, however if it's just not possible for some technical reason let me know :) Thanks, Andy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~--~~~~--~~--~--~---
[symfony-devs] Re: question re: trac #4822
Thanks, good news On Sep 16, 1:01 pm, Fabian Lange wrote: > Hi, > Fabien misunderstood the question. > It will not come to sf 1.2 But of course can still be done for Propel in 1.3 > I reopened the ticket for that > Fabian > > On Wed, Sep 16, 2009 at 1:33 PM, arri...@gmail.com wrote: > > > Hi, > > >http://trac.symfony-project.org/ticket/4822- I notice that this > > ticket has been closed in the last few days, however I was expecting > > the same feature in sfPropelPlugin for 1.3. As far as I can tell this > > hasn't been implemented. Is there a reason for this? We were looking > > forward to this useful feature for propel forms too. > > > If it's a time issue I may be able to work to submit a patch, however > > if it's just not possible for some technical reason let me know :) > > > Thanks, > > Andy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~--~~~~--~~--~--~---
[symfony-devs] Re: routing performance issue 1.3 (prob 1.2 too)
Hi,
Turning off the cache isn't really an option for us due to our
(relatively) large number of routes and the number of calls to them.
Our config_routing.yml.php contains 615 routes. For 56 links, we'd be
back to 1.3 secs just for the routing to work out the links.
re: lookup_cache_dedicated_keys in #5811 - this is an option, however
I think it suffers from the same problem i.e. a cache per instance of
url. Please correct me if i'm wrong. With APC cache i think we will
start getting short of ram pretty quick.
On Sep 16, 1:47 pm, Fabian Lange
wrote:
> Hi,
> not an complete answer, but try "cache: null" instead of the sfNoCache,
> because null will prevent any serialisation calls like here:
>
> if (!is_null($this->cache))
> {
> $this->cache->set('symfony.routing.configuration',
> serialize($this->routes));
> }
>
> sfNoCache will not prevent these lines to run. cache==null will
>
> Fabian
>
> On Wed, Sep 16, 2009 at 2:10 PM, Jarno Rantanen
> wrote:
>
> > Hi,
>
> > We recently ran to a similar issue after upgrading from 1.2.4 to 1.2.8 on a
> > site with busy forums and hence quite a lot of different URLs; the size of
> > the routing data cache became huge (the file was around 30 MB). Needless to
> > say, unserialize()ing a string of 30 MB or so is a bit inefficient.
> > Combined with some obscure bug in PHP (5.2.8) which allowed this operation
> > to bypass the memory_limit-directive, our server quickly ate up its 16 GB or
> > RAM and started swapping. Down we went.
>
> > It was particularly troublesome to identify what caused the huge memory
> > consumption, since because of the bug we didn't get any "memory exhausted"
> > PHP fatal errors in our logs. When we finally did, the situation was
> > immediately resolved by turning off the routing data cache (substituting
> > sfFileCache with sfNoCache in factories.yml). The performance penalty of
> > not having this cache on seems negligible.
>
> > I found some related discussion in:
>
> >http://www.symfony-project.org/blog/2009/04/03/lazy-routing-deseriali...
> >http://trac.symfony-project.org/ticket/6308and
> >http://trac.symfony-project.org/ticket/5811
>
> > Especially depressing was the comment in #5811 "cause sites encountering
> > the issue have people that know how to fix it". :) I realize producing a
> > one-size-fits-all solution for this is nontrivial, but this really took us
> > by surprise and caused quite a headache. Since, according to the benchmarks
> > by "rs" in #5811, the single-key caching strategy doesn't really serve any
> > number of URLs well, should the default strategy be somehow changed in a
> > future release?
>
> > My 0.02 €,
>
> > - Jarno
>
> > On Wed, 2009-09-16 at 03:24 -0700, arri...@gmail.com wrote:
>
> > Hi.
>
> > Noticed the routing has had performance changes in 1.3 which is great.
> > The cache is now recommended to be off but we have a severe impact on
> > our system if we do that.
>
> > Would like to open a discussion re: possible improvement if this is
> > ok.
>
> > We have lots of routes - our app is built around admin generator and
> > therefore sfPropelRouteCollection. The routing performance changes in
> > 1.3 appear to be when loading routes, but the performance penalty for
> > our app is when matching a route i.e. url_for().
>
> > e.g. below is output from xhprof
>
> > Current Function
> > sfPatternRouting::getRouteThatMatchesParameters 56 0.1% 1,360,102
> > 82.9%
> > Exclusive Metrics for Current Function 173,620 12.8%
>
> > Parent function
> > sfPatternRouting::generate 56 100.0% 1,360,102 100.0%
>
> > Child functions
> > sfObjectRoute::matchesParameters 22,455 48.5% 1,115,255 82.0%
> > sfRoute::setDefaultParameters 23,148 50.0% 50,048 3.7%
> > sfRoute::matchesParameters 693 1.5% 21,179 1.6%
>
> > Bit difficult to read sorry, but basically
> > sfPatternRouting::getRouteThatMatchesParameters() is called 56 times
> > (for the 56 links we have) but it takes 1.3 seconds to execute this
> > code. This is on athlon x2 4600+.
>
> > The problem seems to be that sfObjectRoute::matchesParameters() is
> > called 22,455 times taking 1.1 seconds of the total time.
>
> > OK, so if we enable the file cache we get good speeds again, however
> > the problem is the amount of data in this cache. Because we have so
> > many routes and are using admin gen, we hit this problem:
>
> > route is
> > supplier:
> > class: sfPropelRouteCo
[symfony-devs] Re: routing performance issue 1.3 (prob 1.2 too)
Hi Jarno, just so I'm clear on this, am I correct in saying
routing config cache = cache/backend/dev/config/config_routing.yml.php
routing data cache = cache/backend/dev/config/routing/
symfony.routing.data.cache
The config cache runs fine for us - using APC (after upping
apc.max_file_size - it's 1.9MB) loads in ~0.06 secs
The impact for us too is the data cache - if we disable it, we don't
use RAM, avoid the un/serialize() problem, but performance impact is
high when it has to match a number of routes.
If we enable it, we will either get a v. large
symfony.routing.data.cache file or if we use
lookup_cache_dedicated_keys we will use up ram in apc due to the per-
url caching of all the routes on the page.
Interested on the thoughts of caching in real PHP file to take
advantage of APC opcode cache, but I'm still concerned this file will
be v. large.
Thanks,
Andy
On Sep 16, 2:23 pm, Jarno Rantanen wrote:
> Hello,
>
> Fabian, you are right, using sfNoCache will still make calls to
> serialize() and unserialize(), and this is unnecessary overhead. But
> since the cache adapter won't actually *store* anything, the amount of
> data being un-/serialized won't get to grow to proportions in which it'd
> start eating resources like crazy. This is why it solved the problem.
>
> arrigby, the routing config cache is separate from the routing data
> cache. Our issue was exclusively with the latter, and our routing
> config cache is still active.
>
> Initially we were thinking we'd have to implement some other caching
> strategy ourselves, but since the performance gain won't be stellar we
> are considering simply leaving the routing data cache off (with the
> cache: null Fabian pointed out).
>
> I'm assuming that due to the way the cache and routing systems work it
> wouldn't be possible to use a var_export() and include() -combination
> for storing the routing data cache..? It would be way more efficient
> resource-wise, but would obviously only work with local files (ie. no
> APC/memcached/etc), and could not store objects (except via some
> __set_state() magic method).
>
> - Jarno
>
> On Wed, 2009-09-16 at 06:04 -0700, arri...@gmail.com wrote:
> > Hi,
>
> > Turning off the cache isn't really an option for us due to our
> > (relatively) large number of routes and the number of calls to them.
> > Our config_routing.yml.php contains 615 routes. For 56 links, we'd be
> > back to 1.3 secs just for the routing to work out the links.
>
> > re: lookup_cache_dedicated_keys in #5811 - this is an option, however
> > I think it suffers from the same problem i.e. a cache per instance of
> > url. Please correct me if i'm wrong. With APC cache i think we will
> > start getting short of ram pretty quick.
>
> > On Sep 16, 1:47 pm, Fabian Lange
> > wrote:
> > > Hi,
> > > not an complete answer, but try "cache: null" instead of the sfNoCache,
> > > because null will prevent any serialisation calls like here:
>
> > > if (!is_null($this->cache))
> > > {
> > > $this->cache->set('symfony.routing.configuration',
> > > serialize($this->routes));
> > > }
>
> > > sfNoCache will not prevent these lines to run. cache==null will
>
> > > Fabian
>
> > > On Wed, Sep 16, 2009 at 2:10 PM, Jarno Rantanen
> > > wrote:
>
> > > > Hi,
>
> > > > We recently ran to a similar issue after upgrading from 1.2.4 to 1.2.8
> > > > on a
> > > > site with busy forums and hence quite a lot of different URLs; the size
> > > > of
> > > > the routing data cache became huge (the file was around 30 MB).
> > > > Needless to
> > > > say, unserialize()ing a string of 30 MB or so is a bit inefficient.
> > > > Combined with some obscure bug in PHP (5.2.8) which allowed this
> > > > operation
> > > > to bypass the memory_limit-directive, our server quickly ate up its 16
> > > > GB or
> > > > RAM and started swapping. Down we went.
>
> > > > It was particularly troublesome to identify what caused the huge memory
> > > > consumption, since because of the bug we didn't get any "memory
> > > > exhausted"
> > > > PHP fatal errors in our logs. When we finally did, the situation was
> > > > immediately resolved by turning off the routing data cache (substituting
> > > > sfFileCache with sfNoCache in factories.yml). The performance penalty
> > > > of
> > > > not having this cache on seems
[symfony-devs] min/max options for validators re: #7171
Hi, Just seen that #7171 has been closed after changes to sfValidatorChoice in r22140. Unfortunately I don't think the changes will work as sfValidatorPropelChoiceMany doesn't extend sfValidatorChoice, but instead extends sfValidatorBase. Not sure about doctrine implementation, I only know the propel side of things. Thanks, Andy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~--~~~~--~~--~--~---
[symfony-devs] propel behaviors - question about 'symfony' behavior
Hi,
Just updated my code and looks like symfony is now using the propel
native behavior system. This is good news, but I'm struggling to get
it working.
>From what I can work out, the behaviors all sit under a 'symfony'
behavior. I am struggling to enable this. In my propel.ini I have:
; builder settings
propel.builder.object.class=
lib.override.plugins.sfPropelPlugin.lib.builder.CtObjectBuilder
propel.behavior.symfony.class =
plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorSymfony
propel.behavior.symfony_i18n.class =
plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorI18n
propel.behavior.symfony_i18n_translation.class =
plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorI18nTranslation
propel.behavior.symfony_behaviors.class=
plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorSymfonyBehaviors
propel.behavior.symfony_timestampable.class=
plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorTimestampable
propel.builder.addComments = true
propel.builder.addBehaviors = true
But the code for sfMixer, etc is not in the generated Base peer
classes.
I have tried:
propel:
_attributes: { package:
lib.model.retailer, propel_behaviors: symfony }
in my schema.yml without success.
I have looked at the upgrade wiki but it doesn't seem to mention
behaviors.
I have had some success with adding
_propel_behaviors:
symfony: ~
to a table, but surely that is incorrect - I would have to add it to
every table?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: propel behaviors - question about 'symfony' behavior
Ok, I think I have resolved it by adding
propel.behavior.default = symfony
to my propel.ini - certainly the sfMixer code is there. Is this the
'official' way of doing it or is there another way?
After this update, the sfMixer code now appears but the hook names are
different to 1.2 e.g. in BaseCustomerPeer::doUpdate() the hook was
foreach (sfMixer::getCallables('BaseCustomerPeer:doUpdate:post') as
$callable)
{
call_user_func($callable, 'BaseCustomerPeer', $values, $con, $ret);
}
now it is
foreach (sfMixer::getCallables('Customer:doUpdate:post') as $sf_hook)
{
call_user_func($sf_hook, 'Customer', $values, $con, $ret);
}
which does not trigger my hook, plus it passes in an incorrect first
parameter "Customer" and not "BaseCustomerPeer"
Is this a bug or a change - i.e. do I need to update my hook names
when registering?
Thanks,
Andy
On Oct 26, 11:36 am, "arri...@gmail.com" wrote:
> Hi,
>
> Just updated my code and looks like symfony is now using the propel
> native behavior system. This is good news, but I'm struggling to get
> it working.
>
> From what I can work out, the behaviors all sit under a 'symfony'
> behavior. I am struggling to enable this. In my propel.ini I have:
>
> ; builder settings
> propel.builder.object.class =
> lib.override.plugins.sfPropelPlugin.lib.builder.CtObjectBuilder
>
> propel.behavior.symfony.class =
> plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorSymfony
> propel.behavior.symfony_i18n.class =
> plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorI18n
> propel.behavior.symfony_i18n_translation.class =
> plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorI18nTranslation
> propel.behavior.symfony_behaviors.class =
> plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorSymfonyBehaviors
> propel.behavior.symfony_timestampable.class =
> plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorTimestampable
>
> propel.builder.addComments = true
> propel.builder.addBehaviors = true
>
> But the code for sfMixer, etc is not in the generated Base peer
> classes.
>
> I have tried:
>
> propel:
> _attributes: { package:
> lib.model.retailer, propel_behaviors: symfony }
>
> in my schema.yml without success.
>
> I have looked at the upgrade wiki but it doesn't seem to mention
> behaviors.
>
> I have had some success with adding
> _propel_behaviors:
> symfony: ~
>
> to a table, but surely that is incorrect - I would have to add it to
> every table?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: propel behaviors - question about 'symfony' behavior
Hi, I can see commit http://trac.symfony-project.org/changeset/23358
has now added 'Base' onto the hook name, but in the 'Peer' at the end
of the hook name is still missing. I think this will still break BC.
Thanks,
Andy.
On Oct 26, 12:41 pm, "arri...@gmail.com" wrote:
> Ok, I think I have resolved it by adding
>
> propel.behavior.default = symfony
>
> to my propel.ini - certainly the sfMixer code is there. Is this the
> 'official' way of doing it or is there another way?
>
> After this update, the sfMixer code now appears but the hook names are
> different to 1.2 e.g. in BaseCustomerPeer::doUpdate() the hook was
>
> foreach (sfMixer::getCallables('BaseCustomerPeer:doUpdate:post') as
> $callable)
> {
> call_user_func($callable, 'BaseCustomerPeer', $values, $con, $ret);
>
> }
>
> now it is
>
> foreach (sfMixer::getCallables('Customer:doUpdate:post') as $sf_hook)
> {
> call_user_func($sf_hook, 'Customer', $values, $con, $ret);
>
> }
>
> which does not trigger my hook, plus it passes in an incorrect first
> parameter "Customer" and not "BaseCustomerPeer"
>
> Is this a bug or a change - i.e. do I need to update my hook names
> when registering?
>
> Thanks,
> Andy
>
> On Oct 26, 11:36 am, "arri...@gmail.com" wrote:
>
> > Hi,
>
> > Just updated my code and looks like symfony is now using the propel
> > native behavior system. This is good news, but I'm struggling to get
> > it working.
>
> > From what I can work out, the behaviors all sit under a 'symfony'
> > behavior. I am struggling to enable this. In my propel.ini I have:
>
> > ; builder settings
> > propel.builder.object.class =
> > lib.override.plugins.sfPropelPlugin.lib.builder.CtObjectBuilder
>
> > propel.behavior.symfony.class =
> > plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorSymfony
> > propel.behavior.symfony_i18n.class =
> > plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorI18n
> > propel.behavior.symfony_i18n_translation.class =
> > plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorI18nTranslation
> > propel.behavior.symfony_behaviors.class =
> > plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorSymfonyBehaviors
> > propel.behavior.symfony_timestampable.class =
> > plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorTimestampable
>
> > propel.builder.addComments = true
> > propel.builder.addBehaviors = true
>
> > But the code for sfMixer, etc is not in the generated Base peer
> > classes.
>
> > I have tried:
>
> > propel:
> > _attributes: { package:
> > lib.model.retailer, propel_behaviors: symfony }
>
> > in my schema.yml without success.
>
> > I have looked at the upgrade wiki but it doesn't seem to mention
> > behaviors.
>
> > I have had some success with adding
> > _propel_behaviors:
> > symfony: ~
>
> > to a table, but surely that is incorrect - I would have to add it to
> > every table?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~--~~~~--~~--~--~---
[symfony-devs] Re: Routing with sf1.3
Hi, Here is output from my run of the tests - I cannot run david's benchmark as splFixedArray is not available in my php build, though SPL is shown as available in php_info(). I'm running php 5.2.11. Re: config/cache - in 1.3 our config_routing.yml.php is 2,054,492 bytes and consists of 628 routes. These are mostly propel routes. However, with APC opcode caching we find this loads very quickly (last time I benchmarked it was something like 0.06 seconds) Our problem is matching routes - if we have a page with 50 or so links, the majority of the time is spent matching the route (something like 1 second out of total request time of 1.2 seconds) If we enable the APC variable cache and lookup_dedicated_cache_keys once the route is matched, the performance is ok, however we have a lot of route variations and I can see this using a large amount of RAM. We cannot run without this cache as performance is just too slow. Been a while since I looked at this, but can put together some stats if it's useful? [an...@cysrln03-dev-andyr-vm]~/projects/trunk-local-fs/lib/vendor/ symfony/test/routing_performance% php routing_performance.php 1.2|grep "^#" # testing patch 1.2 # This is equivalent to the latest version from the 1.2 branch. # Creating routing yml with 1500+ routes # 1.2 Routing - Creating Config # time: 1.713294, memory: 2304.00kb # 1.2 Routing - Loading Config # time: 0.193375, memory: 10240.00kb # 1.2 Routing - Searching Routes 10 times # 1.2 Routing - Generating Routes 20 times # time: 1.633093, memory: 3328.00kb # 1.2 Routing - Real World Test - Accumulated data # time: 1.826847, memory: 13568.00kb # file: 211.00kb [an...@cysrln03-dev-andyr-vm]~/projects/trunk-local-fs/lib/vendor/ symfony/test/routing_performance% php routing_performance.php david| grep "^#" # testing patch david # Creating routing yml with 1500+ routes # david Routing - Creating Config PHP Fatal error: Class 'splFixedArray' not found in /home/andyr/ projects/trunk-local-fs/lib/vendor/symfony/test/routing_performance/ david/sfRoutingConfigHandlerNew.class.php on line 84 [an...@cysrln03-dev-andyr-vm]~/projects/trunk-local-fs/lib/vendor/ symfony/test/routing_performance% php routing_performance.php fabian| grep "^#" # testing patch fabian # Creating routing yml with 1500+ routes # fabian Routing - Creating Config # time: 2.712385, memory: 9472.00kb # fabian Routing - Loading Config # time: 0.421317, memory: 9216.00kb # fabian Routing - Searching Routes 10 times # fabian Routing - Generating Routes 20 times # time: 0.814632, memory: 0.00kb # fabian Routing - Real World Test - Accumulated data # time: 1.236377, memory: 9216.00kb # file: 1899.08kb Thanks, Andy. On Oct 29, 5:14 pm, Fabian Lange wrote: > Hi David, > feel free to send me patches for our performance test suite. > I will incorporate them until i find a way to give access to everybody. > > So if you have something new i will include it. > > Ideally we have then some kind of incubation of a new way for routing > to be configured. And we can benchmark them. > > So that before release 1.3 we can find a good performing solution. > To be included in 1.3 i would like to accept only "small" backwards > compatible changes that have a big net effect. > > Fabian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~--~~~~--~~--~--~---
[symfony-devs] Re: Routing with sf1.3
Hi, We use APC as the opcode cache, so all *.php files are cached by default - we had to increase the default apc.max_file_size to alow it to cache the routing cache file (config_routing.yml.php) We also use the variable cache of APC to speed up routing matches. We have this entry in factories.yml under routing: lookup_cache_dedicated_keys: true cache: class: sfAPCCache param: automatic_cleaning_factor: 0 lifetime: 1800 As I said, the opcode cache pretty much solves the route loading speed for us, our issue is the route matching speed without the above cache setting. here is our apc.ini extension=apc.so apc.shm_size=256 apc.ttl=600 apc.gc_ttl=300 apc.user_ttl=600 apc.max_file_size=5M apc.num_files_hint=6000 On Oct 30, 12:49 pm, David Ashwood wrote: > I ran some tests last night on the old performance framework before > downloading the latest version and starting to migrate my changes into > the code - this is only the compression based changes - nothing > intelligent happening yet: > > # Creating routing yml with 1000 routes > # creating 1.2 config > # time: 0.286042, memory: 1792.00kb > # creating 1.3 config > # time: 0.586565, memory: 7680.00kb > # creating 1.3a config > # time: 0.639807, memory: 3328.00kb > # loading 1.2 config > # time: 0.113459, memory: 4096.00kb > # loading 1.3 config > # time: 0.648253, memory: 23808.00kb > # loading 1.3a config > # time: 0.409712, memory: 6912.00kb > # searching 1.2 route > # time: 0.205716, memory: 0.00kb > ok 1 > # searching 1.3 route > # time: 0.004365, memory: 0.00kb > ok 2 > # searching 1.3a route > # time: 0.004388, memory: 0.00kb > ok 3 > FileSize with 1.3 Default: 2126812 routing.php > FileSize with 1.3a : 1099505 routing.php > > This is only from targeting compression - I've not looked at any kind > of intelligent mapping/loading yet. The splArray out of habit (I've > been working on a project recently where the splDatastructures are > used). I'll ensure the next version is compatible. > > How are you using/how have you configured the APC with sf? > I ask as I've been playing with some autodetection code - the intention > being to use it if it's available - otherwise to fall back to more > conventional approaches. > > On Fri, 2009-10-30 at 05:37 -0700, arri...@gmail.com wrote: > > Hi, > > > Here is output from my run of the tests - I cannot run david's > > benchmark as splFixedArray is not available in my php build, though > > SPL is shown as available in php_info(). I'm running php 5.2.11. > > > Re: config/cache - in 1.3 our config_routing.yml.php is 2,054,492 > > bytes and consists of 628 routes. These are mostly propel routes. > > However, with APC opcode caching we find this loads very quickly (last > > time I benchmarked it was something like 0.06 seconds) Our problem is > > matching routes - if we have a page with 50 or so links, the majority > > of the time is spent matching the route (something like 1 second out > > of total request time of 1.2 seconds) If we enable the APC variable > > cache and lookup_dedicated_cache_keys once the route is matched, the > > performance is ok, however we have a lot of route variations and I can > > see this using a large amount of RAM. We cannot run without this cache > > as performance is just too slow. Been a while since I looked at this, > > but can put together some stats if it's useful? > > > [an...@cysrln03-dev-andyr-vm]~/projects/trunk-local-fs/lib/vendor/ > > symfony/test/routing_performance% php routing_performance.php 1.2|grep > > "^#" > > # testing patch 1.2 > > # This is equivalent to the latest version from the 1.2 branch. > > # Creating routing yml with 1500+ routes > > # 1.2 Routing - Creating Config > > # time: 1.713294, memory: 2304.00kb > > # 1.2 Routing - Loading Config > > # time: 0.193375, memory: 10240.00kb > > # 1.2 Routing - Searching Routes 10 times > > # 1.2 Routing - Generating Routes 20 times > > # time: 1.633093, memory: 3328.00kb > > # 1.2 Routing - Real World Test - Accumulated data > > # time: 1.826847, memory: 13568.00kb > > # file: 211.00kb > > [an...@cysrln03-dev-andyr-vm]~/projects/trunk-local-fs/lib/vendor/ > > symfony/test/routing_performance% php routing_performance.php david| > > grep "^#" > > # testing patch david > > # Creating routing yml with 1500+ routes > > # david Routing - Creating Config > > PHP Fatal error: Class 'splFixedArray' not found in /home/andyr/ > > projects/trunk-local-fs/lib/vendor/symfony/test/routing_performance/ > > david/sfRouti
[symfony-devs] Re: Routing with sf1.3
Hi, I've just disabled the apc cache under the routing: section in factories.yml and here are some stats: Total Incl. Wall Time (microsec): 3,082,027 microsecs Then, ordered by number of calls sfRoute::mergeArrays56,978 17.2% 394,924 12.8% 394,924 12.8% is_array47,957 14.4% 54,068 1.8%54,068 1.8% array_diff_key 28,556 8.6%78,547 2.5%78,547 2.5% sfRoute::getDefaultParameters 28,489 8.6%63,969 2.1%63,969 2.1% sfRoute::setDefaultParameters 28,425 8.6%85,397 2.8%85,397 2.8% sfRoute::matchesParameters 28,422 8.6%1,684,034 54.6% 1,028,030 33.4% sfRequestRoute::matchesParameters 27,333 8.2%1,889,048 61.3% 259,590 8.4% sfObjectRoute::matchesParameters27,333 8.2%2,424,934 78.7% 379,442 12.3% sfObjectRoute::convertObjectToArray 19,363 5.8%156,451 5.1% 136,329 4.4% preg_match 16,348 4.9%59,968 1.9%59,968 1.9% array_keys 14,230 4.3%26,658 0.9%26,658 0.9% So, sfObjectRoute::matchesParameters is called 27,333 times taking 2,424,934 microseconds which it ~78% of the total time for the request There are only 66 calls to url_for(): sfPatternRouting::generate 67 0.0%2,934,777 95.2% 2,917 0.1% sfWebController::genUrl 67 0.0%2,942,070 95.5% 3,345 0.1% url_for 66 0.0%2,882,401 93.5% 1,436 0.0% url_for166 0.0%2,879,410 93.4% 1,336 0.0% all the calls to url_for() collectively take 2,882,401 microseconds ~93% of total request time. On Oct 30, 2:40 pm, "arri...@gmail.com" wrote: > Hi, > > We use APC as the opcode cache, so all *.php files are cached by > default - we had to increase the default apc.max_file_size to alow it > to cache the routing cache file (config_routing.yml.php) > > We also use the variable cache of APC to speed up routing matches. We > have this entry in factories.yml under routing: > > lookup_cache_dedicated_keys: true > cache: > class: sfAPCCache > param: > automatic_cleaning_factor: 0 > lifetime: 1800 > > As I said, the opcode cache pretty much solves the route loading speed > for us, our issue is the route matching speed without the above cache > setting. > > here is our apc.ini > > extension=apc.so > apc.shm_size=256 > apc.ttl=600 > apc.gc_ttl=300 > apc.user_ttl=600 > apc.max_file_size=5M > apc.num_files_hint=6000 > > On Oct 30, 12:49 pm, David Ashwood > wrote: > > > I ran some tests last night on the old performance framework before > > downloading the latest version and starting to migrate my changes into > > the code - this is only the compression based changes - nothing > > intelligent happening yet: > > > # Creating routing yml with 1000 routes > > # creating 1.2 config > > # time: 0.286042, memory: 1792.00kb > > # creating 1.3 config > > # time: 0.586565, memory: 7680.00kb > > # creating 1.3a config > > # time: 0.639807, memory: 3328.00kb > > # loading 1.2 config > > # time: 0.113459, memory: 4096.00kb > > # loading 1.3 config > > # time: 0.648253, memory: 23808.00kb > > # loading 1.3a config > > # time: 0.409712, memory: 6912.00kb > > # searching 1.2 route > > # time: 0.205716, memory: 0.00kb > > ok 1 > > # searching 1.3 route > > # time: 0.004365, memory: 0.00kb > > ok 2 > > # searching 1.3a route > > # time: 0.004388, memory: 0.00kb > > ok 3 > > FileSize with 1.3 Default: 2126812 routing.php > > FileSize with 1.3a : 1099505 routing.php > > > This is only from targeting compression - I've not looked at any kind > > of intelligent mapping/loading yet. The splArray out of habit (I've > > been working on a project recently where the splDatastructures are > > used). I'll ensure the next version is compatible. > > > How are you using/how have you configured the APC with sf? > > I ask as I've been playing with some autodetection code - the intention > > being to use it if it's available - otherwise to fall back to more > > conventional approaches. > > > On Fri, 2009-10-30 at 05:37 -0700, arri...@gmail.com wrote: > > > Hi, > > > > Here is output from my run of the tests - I cannot run david's > > > benchmark as splFixedArray is not available in my php build, though > > > SPL is shown as available in php_info(). I'm running php 5.2.11. > > > > Re: config/cache - in 1.3 our config_routing.yml.php is 2,054,492 > > > bytes and consists of 628 routes. These are mostly propel r
[symfony-devs] Re: Routing with sf1.3
Hi, No we are not using named routes. I'm not sure why this is considered bad practice - as far as I aware this is a feature of the framework. The documentation IMO doesn't discourage this. Changing to named routes would be quite an undertaking. Thanks, Andy On Oct 30, 3:18 pm, Thomas Rabaix wrote: > So you are not using named routes in your templates ? > > matchesParameters is only call if you use 'module/action'. Which is a > bad practise. > > On 30 oct. 2009, at 16:01, arri...@gmail.com wrote: > > > > > Hi, > > > I've just disabled the apc cache under the routing: section in > > factories.yml and here are some stats: > > > Total Incl. Wall Time (microsec): 3,082,027 microsecs > > > Then, ordered by number of calls > > > sfRoute::mergeArrays 56,978 17.2% 394,924 12.8% 394,924 > > 12.8% > > is_array 47,957 14.4% 54,068 1.8% 54,068 1.8% > > array_diff_key 28,556 8.6% 78,547 2.5% 78,547 2.5% > > sfRoute::getDefaultParameters 28,489 8.6% 63,969 2.1% 63,969 > > 2.1% > > sfRoute::setDefaultParameters 28,425 8.6% 85,397 2.8% 85,397 > > 2.8% > > sfRoute::matchesParameters 28,422 8.6% 1,684,034 54.6% > > 1,028,030 > > 33.4% > > sfRequestRoute::matchesParameters 27,333 8.2% 1,889,048 61.3% > > 259,590 8.4% > > sfObjectRoute::matchesParameters 27,333 8.2% 2,424,934 78.7% > > 379,442 12.3% > > sfObjectRoute::convertObjectToArray 19,363 5.8% 156,451 > > 5.1% > > 136,329 4.4% > > preg_match 16,348 4.9% 59,968 1.9% 59,968 1.9% > > array_keys 14,230 4.3% 26,658 0.9% 26,658 0.9% > > > So, sfObjectRoute::matchesParameters is called 27,333 times taking > > 2,424,934 microseconds which it ~78% of the total time for the request > > > There are only 66 calls to url_for(): > > > sfPatternRouting::generate 67 0.0% 2,934,777 95.2% > > 2,917 0.1% > > sfWebController::genUrl 67 0.0% 2,942,070 95.5% 3,345 > > 0.1% > > url_for 66 0.0% 2,882,401 93.5% 1,436 0.0% > > url_for1 66 0.0% 2,879,410 93.4% 1,336 0.0% > > > all the calls to url_for() collectively take 2,882,401 microseconds > > ~93% of total request time. > > > On Oct 30, 2:40 pm, "arri...@gmail.com" wrote: > >> Hi, > > >> We use APC as the opcode cache, so all *.php files are cached by > >> default - we had to increase the default apc.max_file_size to alow it > >> to cache the routing cache file (config_routing.yml.php) > > >> We also use the variable cache of APC to speed up routing matches. We > >> have this entry in factories.yml under routing: > > >> lookup_cache_dedicated_keys: true > >> cache: > >> class: sfAPCCache > >> param: > >> automatic_cleaning_factor: 0 > >> lifetime: 1800 > > >> As I said, the opcode cache pretty much solves the route loading > >> speed > >> for us, our issue is the route matching speed without the above cache > >> setting. > > >> here is our apc.ini > > >> extension=apc.so > >> apc.shm_size=256 > >> apc.ttl=600 > >> apc.gc_ttl=300 > >> apc.user_ttl=600 > >> apc.max_file_size=5M > >> apc.num_files_hint=6000 > > >> On Oct 30, 12:49 pm, David Ashwood > >> wrote: > > >>> I ran some tests last night on the old performance framework before > >>> downloading the latest version and starting to migrate my changes > >>> into > >>> the code - this is only the compression based changes - nothing > >>> intelligent happening yet: > > >>> # Creating routing yml with 1000 routes > >>> # creating 1.2 config > >>> # time: 0.286042, memory: 1792.00kb > >>> # creating 1.3 config > >>> # time: 0.586565, memory: 7680.00kb > >>> # creating 1.3a config > >>> # time: 0.639807, memory: 3328.00kb > >>> # loading 1.2 config > >>> # time: 0.113459, memory: 4096.00kb > >>> # loading 1.3 config > >>> # time: 0.648253, memory: 23808.00kb > >>> # loading 1.3a config > >>> # time: 0.409712, memory: 6912.00kb > >>> # searching 1.2 route > >>> # time: 0.205716, memory: 0.00kb > >>> ok 1 > >>> # searching
[symfony-devs] Re: - sf 1.3 and include_stylesheets() and include_javascripts()
Hi, We get round this problem by wrapping the include_component() call in a slot before include_javascripts() is called, then include_slot() in the position we want i.e. layout.php It's not pretty, but it works for us On Nov 16, 11:19 am, Pierrot Evrard wrote: > With more investigations, I have found that components that comes from > action are included before the layout and component from layout after the > layout, that makes sense. > > So, I'm damned. There is no workaround and I need to find something else for > my javascripts that comes with components from the layout. :-( > > Thanks for reading. > > Loops > > 2009/11/16 Pierrot Evrard > > > Hi, > > > View prologue at:http://trac.symfony-project.org/ticket/7579 > > > I have understand the reason why this ticket wont be fix but, I found a > > strange behavior about that... > > > When I call use_stylesheets_for_form() from a component, CSS files from the > > form are included but when I call use_stylesheet() from a component, the CSS > > file is not included. > > > The process is simple: > > > - initialization of the form in the action; > > > - submit form as argument to the component in the action view; > > > - use_stylesheets_for_form() in the component view (if I remove this > > function, CSS files are not included); > > > - display the form in the component. > > > I just wonder how it is possible, I can't follow the entire process behind > > but this strange behavior has not any sense for me. > > > I don't wanna miss respect to anybody, but it makes me so crazy that I have > > to say: what is that hell? > > > My purpose is to find a workaround without re-enabled the sf 1.2 filter and > > without having change all view.yml files. > > > Loops --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~--~~~~--~~--~--~---
