date:20081021


You tried to calculate days manually but you did not thought of DST.
Simply use the difference as input for a new date

$days = $date2-subDate($date1)-get(Zend_Date::DAY_OF_YEAR) - 1;

Simple maths :-)
PS: Does not work for dates which differ more than a year.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

- Original Message - 
From: David Mintz [EMAIL PROTECTED]

To: fw-general@lists.zend.com
Sent: Monday, October 20, 2008 11:27 PM
Subject: [fw-general] Zend_Date arithmetic: difference in days (not seconds) 
between two dates



I would like to compute the difference in days between two dates. I have 
the

fix_dst option set to true and the timezone is America/New York. A DST
change happened in my timezone on March 9, 2008. So,

$date1 = new Zend_Date(array(
'year'= 2008,
   'month'=3,
   'day'=7,
   'hour'=12,
));

$date2 = new Zend_Date(array(
   'year'= 2008,
'month'=3,
   'day'=10,
   'hour'=12,
));

$diff = $date2-sub($date1);
print  difference in days is .$diff/86400;

And the output is not what I want to hear, i.e., not 3 but 2.95833

I think I understand, Zend_Date is telling me how many seconds actually
elapsed between the two dates. But I want to figure out the days, 
accounting
for the fact that one of the intervening days had only 23 hours. What's 
the

correct approach?

Thanks.

--
David Mintz
http://davidmintz.org/

The subtle source is clear and bright
The tributary streams flow through the darkness

[fw-general] Zend_ModelForm proposal

2008-10-21 Thread Jani Hartikainen


Hey all

Some of you may have heard about my ModelForm class for Doctrine. I have  
now
been working on modifying it to use Zend_Db_Table, so those of you who  
aren't

using Doctrine can use it too.

I've created a proposal for a new Zend_ModelForm component here:
http://framework.zend.com/wiki/display/ZFPROP/Zend_Form+generation+from+models+-+Jani+Hartikainen


I would appreciate any feedback or ideas. Particularily, I'd like to know
your opinion on how to best allow you to define the relation information  
for
generating forms with relation support in Zend_Db_Table (this is already  
supported
with Doctrine). Feedback regarding the adapter interface would also be  
welcome.


If you want to know more, I suggest you hit the blogposts link in the  
references section
of the proposal. There's much more info on the class to be found in my  
blog.



Thanks

--
Jani Hartikainen
http://codeutopia.net/

[fw-general] Zend_Search_Lucene - how to find performance problem source?


Hi!

I'm using Zend Framework 1.6.2 and Zend_Search_Lucene for search. And I have
problem with search performance. About index:
* search index is ~25MB in size
* search index contains ~7350 documents
* index is in UTF8
* index is optimized (with optimize())

At first - index creation takes very long time. To rebuild full index it
takes more than hour. But that is only half of pain, because - how often do
we need to make full rebuild of index? :)

The main problem is search performance. Very simple search takes about 8
seconds on my hosting server. 
Example of simple search:
$term = 'Riga';
Zend_Search_Lucene::setResultSetLimit(150);
$index = My_Search_Lucene::open(self::$config-lucene-dir);
$query = Zend_Search_Lucene_Search_QueryParser::parse($term, 'utf-8');
$results = $index-find($query);

The question is - how I can locate where is the problem of index?

Thanks in advance.
-- 
View this message in context: 
http://www.nabble.com/Zend_Search_Lucene---how-to-find-performance-problem-source--tp20085562p20085562.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Zend_Form decorators for table layout within an ini file

2008-10-21 Thread monk.e.boy




Ralf Eggert wrote:
 
 Hi Mon,
 
 Thanks this does work now:
 
 

Thanks, mon.

Do you have a solution for zebra striping the rows?

thanks

monk.e.boy
-- 
View this message in context: 
http://www.nabble.com/Zend_Form-decorators-for-table-layout-within-an-ini-file-tp20055298p20085614.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Zend_Locale compatibility mode

2008-10-21 Thread Bart McLeod


Hi Thomas,

I also get the error and I noticed that the reference guide does not 
know about compatibilityMode.


Where is the migration chapter?

I think I use Zend_Locale implicitly, because the problems appear in the 
translator, but I still get about sixty warnings scattered around my forms.


Not happy about it, as you can imagine.

On which component should we /simply /set compatibilityMode to false, 
and is this a static call, or should we be looking for a translator 
object or the like to set it on?


Regards,

Bart McLeod

Thomas Weidner schreef:
With r12003 there was also a new migration chapter added which would 
have answered your questions.


According to the manual you can simply set compatibilityMode to false 
which supresses the warning but will activate the new API behaviour.


When you use Zend_Locale only implicit there will be no problems.
Otherwise you will have to migrate your scripts according to the 
migration chapter in the manual.


Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

- Original Message - From: Pieter Kokx [EMAIL PROTECTED]
To: 'Zend Framework General' fw-general@lists.zend.com
Sent: Saturday, October 18, 2008 12:21 PM
Subject: [fw-general] Zend_Locale compatibility mode



Hi,

Since r12003 there is an compatibility mode added to Zend_Locale, which
gives a warning. But I am not using Zend_Locale directly, only by
Zend_Date and Zend_Translate. So, I don't know how to fix this problems
with Zend_Date and Zend_Translate. Should these classes be updated so
Zend_Locale will work again without the warning? Or is it something that
I should fix myself?

--
Regards,

Pieter Kokx
MaakSite.net
PHP Developer

Re: [fw-general] Zend_Locale compatibility mode

2008-10-21 Thread Christopher Östlund

It's in the trunk docs. It used to contain an error, but is corrected now.

Zend_Locale::$compatibilityMode = false;

/C


On Tue, Oct 21, 2008 at 1:12 PM, Bart McLeod [EMAIL PROTECTED] wrote:

  Hi Thomas,

 I also get the error and I noticed that the reference guide does not know
 about compatibilityMode.

 Where is the migration chapter?

 I think I use Zend_Locale implicitly, because the problems appear in the
 translator, but I still get about sixty warnings scattered around my forms.

 Not happy about it, as you can imagine.

 On which component should we *simply *set compatibilityMode to false, and
 is this a static call, or should we be looking for a translator object or
 the like to set it on?

 Regards,

 Bart McLeod

 Thomas Weidner schreef:

 With r12003 there was also a new migration chapter added which would have
 answered your questions.

 According to the manual you can simply set compatibilityMode to false which
 supresses the warning but will activate the new API behaviour.

 When you use Zend_Locale only implicit there will be no problems.
 Otherwise you will have to migrate your scripts according to the migration
 chapter in the manual.

 Greetings
 Thomas Weidner, I18N Team Leader, Zend Framework
 http://www.thomasweidner.com

 - Original Message - From: Pieter Kokx [EMAIL PROTECTED][EMAIL 
 PROTECTED]
 To: 'Zend Framework General' 
 fw-general@lists.zend.comfw-general@lists.zend.com
 Sent: Saturday, October 18, 2008 12:21 PM
 Subject: [fw-general] Zend_Locale compatibility mode


 Hi,

 Since r12003 there is an compatibility mode added to Zend_Locale, which
 gives a warning. But I am not using Zend_Locale directly, only by
 Zend_Date and Zend_Translate. So, I don't know how to fix this problems
 with Zend_Date and Zend_Translate. Should these classes be updated so
 Zend_Locale will work again without the warning? Or is it something that
 I should fix myself?

 --
 Regards,

 Pieter Kokx
 MaakSite.net
 PHP Developer

Re: [fw-general] Zend_Form decorators for table layout within an ini file

2008-10-21 Thread Mon Zafra

I would make a method in my form object that goes like:

$pos = 0
// loop through each element
   if (++$pos % 2 == 0)
  $element-getDecorator('row')-setOption('class', 'even')
// end loop

that is called before rendering. It's probably possible to do with a custom
element decorator if you can somehow pass the position of the element to the
decorator class.

On Tue, Oct 21, 2008 at 4:24 PM, monk.e.boy [EMAIL PROTECTED]wrote:




 Ralf Eggert wrote:
 
  Hi Mon,
 
  Thanks this does work now:
 
 

 Thanks, mon.

 Do you have a solution for zebra striping the rows?

 thanks

 monk.e.boy
 --
 View this message in context:
 http://www.nabble.com/Zend_Form-decorators-for-table-layout-within-an-ini-file-tp20055298p20085614.html
 Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Zend_Locale compatibility mode

2008-10-21 Thread Bart McLeod


The result is:
*Fatal error*: Access to undeclared static property: 
Zend_Locale::$compatibilityMode 
in *D:\ZendFramework\library\SpaceCMS\Cms_Plugin_Init.php* on line *8

*
Not that I thought putting *
*Zend_Locale::$compatibilityMode = false;
in would help, but then again, if you don't try...

What I would like to know is:
-url of the chapter that describes compatibilitymode
-a way to set it to false that works. :-)

Regards,

Bart McLeod

Christopher Östlund schreef:

It's in the trunk docs. It used to contain an error, but is corrected now.

Zend_Locale::$compatibilityMode = false;

/C


On Tue, Oct 21, 2008 at 1:12 PM, Bart McLeod [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Hi Thomas,

I also get the error and I noticed that the reference guide does
not know about compatibilityMode.

Where is the migration chapter?

I think I use Zend_Locale implicitly, because the problems appear
in the translator, but I still get about sixty warnings scattered
around my forms.

Not happy about it, as you can imagine.

On which component should we /simply /set compatibilityMode to
false, and is this a static call, or should we be looking for a
translator object or the like to set it on?

Regards,

Bart McLeod

Thomas Weidner schreef:

With r12003 there was also a new migration chapter added which
would have answered your questions.

According to the manual you can simply set compatibilityMode to
false which supresses the warning but will activate the new API
behaviour.

When you use Zend_Locale only implicit there will be no problems.
Otherwise you will have to migrate your scripts according to the
migration chapter in the manual.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

- Original Message - From: Pieter Kokx [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
To: 'Zend Framework General' fw-general@lists.zend.com
mailto:fw-general@lists.zend.com
Sent: Saturday, October 18, 2008 12:21 PM
Subject: [fw-general] Zend_Locale compatibility mode



Hi,

Since r12003 there is an compatibility mode added to
Zend_Locale, which
gives a warning. But I am not using Zend_Locale directly, only by
Zend_Date and Zend_Translate. So, I don't know how to fix this
problems
with Zend_Date and Zend_Translate. Should these classes be
updated so
Zend_Locale will work again without the warning? Or is it
something that
I should fix myself?

-- 
Regards,


Pieter Kokx
MaakSite.net
PHP Developer

Re: [fw-general] Zend_Locale compatibility mode

2008-10-21 Thread Christopher Östlund

Are  you sure you're running the right revision?

Line 130 in Locale.php:

public static $compatibilityMode = true;

/C


On Tue, Oct 21, 2008 at 1:39 PM, Bart McLeod [EMAIL PROTECTED] wrote:

  The result is:
 *Fatal error*: Access to undeclared static property:
 Zend_Locale::$compatibilityMode in *
 D:\ZendFramework\library\SpaceCMS\Cms_Plugin_Init.php* on line *8
 *
 Not that I thought putting *
 *Zend_Locale::$compatibilityMode = false;
 in would help, but then again, if you don't try...

 What I would like to know is:
 -url of the chapter that describes compatibilitymode
 -a way to set it to false that works. :-)

 Regards,

 Bart McLeod

 Christopher Östlund schreef:

 It's in the trunk docs. It used to contain an error, but is corrected now.

 Zend_Locale::$compatibilityMode = false;

 /C


 On Tue, Oct 21, 2008 at 1:12 PM, Bart McLeod [EMAIL PROTECTED] wrote:

  Hi Thomas,

 I also get the error and I noticed that the reference guide does not know
 about compatibilityMode.

 Where is the migration chapter?

 I think I use Zend_Locale implicitly, because the problems appear in the
 translator, but I still get about sixty warnings scattered around my forms.

 Not happy about it, as you can imagine.

 On which component should we *simply *set compatibilityMode to false, and
 is this a static call, or should we be looking for a translator object or
 the like to set it on?

 Regards,

 Bart McLeod

 Thomas Weidner schreef:

 With r12003 there was also a new migration chapter added which would have
 answered your questions.

 According to the manual you can simply set compatibilityMode to false
 which supresses the warning but will activate the new API behaviour.

 When you use Zend_Locale only implicit there will be no problems.
 Otherwise you will have to migrate your scripts according to the migration
 chapter in the manual.

 Greetings
 Thomas Weidner, I18N Team Leader, Zend Framework
 http://www.thomasweidner.com

 - Original Message - From: Pieter Kokx [EMAIL PROTECTED][EMAIL 
 PROTECTED]
 To: 'Zend Framework General' 
 fw-general@lists.zend.comfw-general@lists.zend.com
 Sent: Saturday, October 18, 2008 12:21 PM
 Subject: [fw-general] Zend_Locale compatibility mode


 Hi,

 Since r12003 there is an compatibility mode added to Zend_Locale, which
 gives a warning. But I am not using Zend_Locale directly, only by
 Zend_Date and Zend_Translate. So, I don't know how to fix this problems
 with Zend_Date and Zend_Translate. Should these classes be updated so
 Zend_Locale will work again without the warning? Or is it something that
 I should fix myself?

 --
 Regards,

 Pieter Kokx
 MaakSite.net
 PHP Developer

Re: [fw-general] Zend_Locale compatibility mode

2008-10-21 Thread Nick Thornley

As far as I can tell this addition only exists in the trunk, and not  
in 1.7.0PR


Nick

On 21 Oct 2008, at 12:53, Christopher Östlund wrote:


Are  you sure you're running the right revision?

Line 130 in Locale.php:

public static $compatibilityMode = true;

/C


On Tue, Oct 21, 2008 at 1:39 PM, Bart McLeod [EMAIL PROTECTED]  
wrote:

The result is:
Fatal error: Access to undeclared static property: Zend_Locale:: 
$compatibilityMode in D:\ZendFramework\library\SpaceCMS 
\Cms_Plugin_Init.php on line 8


Not that I thought putting
Zend_Locale::$compatibilityMode = false;
in would help, but then again, if you don't try...

What I would like to know is:
-url of the chapter that describes compatibilitymode
-a way to set it to false that works. :-)

Regards,

Bart McLeod

Christopher Östlund schreef:
It's in the trunk docs. It used to contain an error, but is  
corrected now.


Zend_Locale::$compatibilityMode = false;

/C


On Tue, Oct 21, 2008 at 1:12 PM, Bart McLeod [EMAIL PROTECTED]  
wrote:

Hi Thomas,

I also get the error and I noticed that the reference guide does  
not know about compatibilityMode.


Where is the migration chapter?

I think I use Zend_Locale implicitly, because the problems appear  
in the translator, but I still get about sixty warnings scattered  
around my forms.


Not happy about it, as you can imagine.

On which component should we simply set compatibilityMode to false,  
and is this a static call, or should we be looking for a translator  
object or the like to set it on?


Regards,

Bart McLeod

Thomas Weidner schreef:
With r12003 there was also a new migration chapter added which  
would have answered your questions.


According to the manual you can simply set compatibilityMode to  
false which supresses the warning but will activate the new API  
behaviour.


When you use Zend_Locale only implicit there will be no problems.
Otherwise you will have to migrate your scripts according to the  
migration chapter in the manual.


Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

- Original Message - From: Pieter Kokx [EMAIL PROTECTED]
To: 'Zend Framework General' fw-general@lists.zend.com
Sent: Saturday, October 18, 2008 12:21 PM
Subject: [fw-general] Zend_Locale compatibility mode



Hi,

Since r12003 there is an compatibility mode added to Zend_Locale,  
which

gives a warning. But I am not using Zend_Locale directly, only by
Zend_Date and Zend_Translate. So, I don't know how to fix this  
problems
with Zend_Date and Zend_Translate. Should these classes be  
updated so
Zend_Locale will work again without the warning? Or is it  
something that

I should fix myself?

--
Regards,

Pieter Kokx
MaakSite.net
PHP Developer

Re: [fw-general] Zend_Locale compatibility mode

2008-10-21 Thread Bart McLeod

I stand corrected: I reverted to revision 11775 to get rid of the error. 
Used your code snippet with the latest Zend_Locale.php and it works.


Thanks a lot, you just saved me about sixty warning messages :-)

Bart

Christopher Östlund schreef:

Are  you sure you're running the right revision?

Line 130 in Locale.php:

public static $compatibilityMode = true;

/C


On Tue, Oct 21, 2008 at 1:39 PM, Bart McLeod [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


The result is:
*Fatal error*: Access to undeclared static property:
Zend_Locale::$compatibilityMode
in *D:\ZendFramework\library\SpaceCMS\Cms_Plugin_Init.php* on line *8
*
Not that I thought putting *
*Zend_Locale::$compatibilityMode = false;
in would help, but then again, if you don't try...

What I would like to know is:
-url of the chapter that describes compatibilitymode
-a way to set it to false that works. :-)

Regards,

Bart McLeod

Christopher Östlund schreef:

It's in the trunk docs. It used to contain an error, but is
corrected now.

Zend_Locale::$compatibilityMode = false;

/C


On Tue, Oct 21, 2008 at 1:12 PM, Bart McLeod [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:

Hi Thomas,

I also get the error and I noticed that the reference guide
does not know about compatibilityMode.

Where is the migration chapter?

I think I use Zend_Locale implicitly, because the problems
appear in the translator, but I still get about sixty
warnings scattered around my forms.

Not happy about it, as you can imagine.

On which component should we /simply /set compatibilityMode
to false, and is this a static call, or should we be looking
for a translator object or the like to set it on?

Regards,

Bart McLeod

Thomas Weidner schreef:

With r12003 there was also a new migration chapter added
which would have answered your questions.

According to the manual you can simply set compatibilityMode
to false which supresses the warning but will activate the
new API behaviour.

When you use Zend_Locale only implicit there will be no
problems.
Otherwise you will have to migrate your scripts according to
the migration chapter in the manual.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

- Original Message - From: Pieter Kokx
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
To: 'Zend Framework General' fw-general@lists.zend.com
mailto:fw-general@lists.zend.com
Sent: Saturday, October 18, 2008 12:21 PM
Subject: [fw-general] Zend_Locale compatibility mode



Hi,

Since r12003 there is an compatibility mode added to
Zend_Locale, which
gives a warning. But I am not using Zend_Locale directly,
only by
Zend_Date and Zend_Translate. So, I don't know how to fix
this problems
with Zend_Date and Zend_Translate. Should these classes be
updated so
Zend_Locale will work again without the warning? Or is it
something that
I should fix myself?

-- 
Regards,


Pieter Kokx
MaakSite.net
PHP Developer

Re: [fw-general] ZF performances / profiling the culprit

-- Bruno Friedmann [EMAIL PROTECTED] wrote
(on Tuesday, 21 October 2008, 06:56 AM +0200):
 Matthew Weier O'Phinney wrote:
  -- Bruno Friedmann [EMAIL PROTECTED] wrote
  (on Monday, 20 October 2008, 07:00 AM +0200):
   Matthew Weier O'Phinney wrote:
-- Bruno Friedmann [EMAIL PROTECTED] wrote
(on Sunday, 19 October 2008, 07:30 PM +0200):
 With the help of ZendStudio, I'm trying to understand why on one
 application I've got 25/30 req/s and on the second one I've only a
 5/5.50 req (1.6.2) or a 7/8.2rqs ( 1.7.0 notice the little change )
 ( a simple html file is giving a 385rqs and a 404 error page give 
 around a 280/320rqs )

 The profile result give me a 59% time consume by Layout ( which I
 doesn't have on the speed app ) and another 12.5% to Translate
 ( ok I'm using tmx which is not the most speedy thing )
You can save me a little time and effort here by attaching the layout
script you use, as well as a count of the number of times calls are made
to translate items. With that information, I can add some information to
our performance and profiling test suite.
   
   Quickly I'm calling the index controlleur / index view with layout.
   html/index.php
   - ZFApplication ( which is the real bootstrap )
   - app/Module/Default
   - /Controller/indexController
 - Action indexAction
   - Scripts/index/index.phtml
 
   Layout contain
   |-- common
   |   |-- footer.phtml
   |   |-- header.phtml
   |   |-- help.phtml
   |   `-- menu.phtml
   `-- main.phtml
  
   For the index view there's a test
   if ( !Zend_Auth::getInstance()- hasIdentity() ):
   // Render login form or logged
   echo $this- action(null, 'login');
  // If we are anonymous
  
   --
   For translation I've a global function __($str) which translate strings.
  
   For the whole projet there's a 945 call to it.
  
   For the index call profiled it's about 24 calls.
  
  The above may very well be the culprit, but I'll write a test just to
  see.
  
  Can you give the contents of your layout files? I'm curious to see how
  you're pulling in content -- if you're using partial(), action(), or
  simply render(). I've already identified a bottleneck in partial() that
  I'll be working on. Additionally, I typically recommend against action()
  because I know already that internally it's expensive; it's cheaper to
  create a helper that pulls from the model directly.
  
 
 If what you say is correct, I'm in trouble :-)
 
 You will see why in the source attached ...
 
 So I'm waiting your confirmation, and eventually other recommandations.
 There's some refactoring/rewritting in the air tonight :-)

The only reason to use partial() instead of render() is when you
absolutely need a clean variable scope for the rendered view script. In
your case, I'd recommend simply substituting render() for each time you
use partial(); this will definitely improve speed.

I see you're using action() to pull in a login form. Since you won't be
worried about pre-populated values or validation, it may make more sense
here to either instantiate the form object directly and display it, or
create a view helper that does this. 

See if the above changes help your performance. If not, the next thing
I'd suggest trying to move to gettext for your translations to see if
that speeds things up. If so, you may be able to develop using TMX, and
write a build script that converts to gettext later.

-- 
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/

Re: [fw-general] Zend_Search_Lucene - how to find performance problem source?

2008-10-21 Thread Jurriën Stutterheim


Hi,


You should probably optimize your index before searching (and make  
sure it stays optimized, using a Cron-job).
See http://framework.zend.com/manual/en/zend.search.lucene.index-creation.html#zend.search.lucene.index-creation.optimization 
 for more details on how to do this =)



- Jurriën

On Oct 21, 2008, at 10:20 , Endijs Lisovskis wrote:



Hi!

I'm using Zend Framework 1.6.2 and Zend_Search_Lucene for search.  
And I have

problem with search performance. About index:
* search index is ~25MB in size
* search index contains ~7350 documents
* index is in UTF8
* index is optimized (with optimize())

At first - index creation takes very long time. To rebuild full  
index it
takes more than hour. But that is only half of pain, because - how  
often do

we need to make full rebuild of index? :)

The main problem is search performance. Very simple search takes  
about 8

seconds on my hosting server.
Example of simple search:
$term = 'Riga';
Zend_Search_Lucene::setResultSetLimit(150);
$index = My_Search_Lucene::open(self::$config-lucene-dir);
$query = Zend_Search_Lucene_Search_QueryParser::parse($term, 'utf-8');
$results = $index-find($query);

The question is - how I can locate where is the problem of index?

Thanks in advance.
--
View this message in context: 
http://www.nabble.com/Zend_Search_Lucene---how-to-find-performance-problem-source--tp20085562p20085562.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Zend_Search_Lucene - how to find performance problem source?


Thanks for your response. At least someone :)
But your suggestion will not make any difference in performance, because, as
I said in first email index IS optimized.
Maybe there are some potential problems with index if data is in UTF8 ? 

How to trace - where to look for problem?

Index was made in this manner: select first 1000 articles - add to index -
optimize, select next 1000 articles - add to index - optimize. Of course:
1 article = 1 document. At the end index is optimized and consists from
~7350 documents. 

I hope someone can help.

Endijs Lisovskis 


Jurriën Stutterheim wrote:
 
 Hi,
 
 
 You should probably optimize your index before searching (and make  
 sure it stays optimized, using a Cron-job).
 See
 http://framework.zend.com/manual/en/zend.search.lucene.index-creation.html#zend.search.lucene.index-creation.optimization
  
   for more details on how to do this =)
 
 
 - Jurriën
 
 

-- 
View this message in context: 
http://www.nabble.com/Zend_Search_Lucene---how-to-find-performance-problem-source--tp20085562p20090740.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Zend_Search_Lucene - how to find performance problem source?

2008-10-21 Thread Jurriën Stutterheim

Sorry, I completely overlooked that bit of your email. I'm not sure  
about the bottleneck in that case... it might be your hosting provider  
with a (very, very) slow server? An index as small as ~7350 docs and a  
limit of 150 results should be lightning fast...
You can speed up your indexing process by the way. Just let it index  
all documents and do one optimze() afterwards.



On Oct 21, 2008, at 15:51 , Endijs Lisovskis wrote:



Thanks for your response. At least someone :)
But your suggestion will not make any difference in performance,  
because, as

I said in first email index IS optimized.
Maybe there are some potential problems with index if data is in  
UTF8 ?


How to trace - where to look for problem?

Index was made in this manner: select first 1000 articles - add to  
index -
optimize, select next 1000 articles - add to index - optimize. Of  
course:
1 article = 1 document. At the end index is optimized and consists  
from

~7350 documents.

I hope someone can help.

Endijs Lisovskis


Jurriën Stutterheim wrote:


Hi,


You should probably optimize your index before searching (and make
sure it stays optimized, using a Cron-job).
See
http://framework.zend.com/manual/en/zend.search.lucene.index-creation.html#zend.search.lucene.index-creation.optimization
 for more details on how to do this =)


- Jurriën




--
View this message in context: 
http://www.nabble.com/Zend_Search_Lucene---how-to-find-performance-problem-source--tp20085562p20090740.html
Sent from the Zend Framework mailing list archive at Nabble.com.

AW: [fw-general] Zend_Search_Lucene - how to find performance problem source?

2008-10-21 Thread Stefan Oestreicher

Are you storing document contents in the index? This will degrade performance
badly in my experience (the bigger the docs, the worse the performance).
If that's not the case, I'd suggest to profile your application with xdebug.
This should reveal the culprit in no time.

best regards,

Stefan

-Ursprüngliche Nachricht-
Von: Endijs Lisovskis [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 21. Oktober 2008 15:52
An: fw-general@lists.zend.com
Betreff: Re: [fw-general] Zend_Search_Lucene - how to find performance problem
source?

Thanks for your response. At least someone :)
But your suggestion will not make any difference in performance, because, as
I said in first email index IS optimized.
Maybe there are some potential problems with index if data is in UTF8 ?

How to trace - where to look for problem?

Index was made in this manner: select first 1000 articles - add to index -
optimize, select next 1000 articles - add to index - optimize. Of course:
1 article = 1 document. At the end index is optimized and consists from
~7350 documents.

I hope someone can help.

Endijs Lisovskis

Jurriën Stutterheim wrote:

Hi,

You should probably optimize your index before searching (and make
sure it stays optimized, using a Cron-job).
See
http://framework.zend.com/manual/en/zend.search.lucene.index-creation.html#zend.search.lucene.index-creation.optimization

for more details on how to do this =)

- Jurriën

--
View this message in context:
http://www.nabble.com/Zend_Search_Lucene---how-to-find-performance-problem-source--tp20085562p20090740.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Zend_Search_Lucene - how to find performance problem source?


I doubt that this is hosting provider problem, because in one other project I
use Zend_Search_Lucene and there are no problems with speed. 
I used optimize() after each 1000 documents, because before adding each
document i'm performing search - to verify that index already does not
contain the same document. 

One more question - is that OK that index of ~7350 documents is about 25MB
in size? Each document = an article. In average article = 250words.

Endijs Lisovskis


Jurriën Stutterheim wrote:
 
 Sorry, I completely overlooked that bit of your email. I'm not sure  
 about the bottleneck in that case... it might be your hosting provider  
 with a (very, very) slow server? An index as small as ~7350 docs and a  
 limit of 150 results should be lightning fast...
 You can speed up your indexing process by the way. Just let it index  
 all documents and do one optimze() afterwards.
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Zend_Search_Lucene---how-to-find-performance-problem-source--tp20085562p20091058.html
Sent from the Zend Framework mailing list archive at Nabble.com.

RE: [fw-general] XML-RPC client and umlauts etc. question

2008-10-21 Thread Robert Castley

Would you like me to raise a JIRA report for this?
 
Regards,
 
- Robert

  _  

From: Robert Castley 
Sent: 20 October 2008 13:56
To: Matthew Weier O'Phinney; fw-general@lists.zend.com
Subject: RE: [fw-general] XML-RPC client and umlauts etc. question



Hi Matthew, 


Thanks for responding. 
  
- 

Two questions for you: 

  * Is the XML-RPC server Zend_XmlRpc_Server, or another implementation? 

 The server is another implementation 

  * Are you using Zend_XmlRpc_Client? 

 Yes I am 

 The thing to note here is that I am tracing out the XML that 
 Zend_XmlRpc_Client is building up so this is before we even 
 hit the server and this is where I see the values stripped. 



In Zend_XmlRpc_Client, we actually cast all values to UTF-8 by default
(probably should be configurable). The only thing I can think of off the top
of my head is one of the following scenarios:

  * Server implementation is not capable of receiving UTF-8 characters 
  * iconv not accurately detecting request character encoding, so the 
re-encoding is faulty 


 

Here is a complete dump for you taken using FireBug in FF 3. 

This array contains original form value with no modification. 

Array 

( 

[name] = 
[location] = UK:ABR:ABRWEST 
[description] = D sseldorf 
[category] = Geography 
[Image] = UK_ABR_ABRWEST.gif 
[savelevel] = savelevel 

) 

This array is post htmlentities convert. 
Array 

( 
[name] = 
[location] = UK:ABR:ABRWEST 
[description] = Duuml;sseldorf 
[category] = Geography 
[Image] = UK_ABR_ABRWEST.gif 
[savelevel] = savelevel 
) 

This is the Zend_XmlRpc_Client dump and the description field is blank. 

?xml version=1.0 encoding=UTF-8? 
methodCallmethodNameForms.Process/methodNameparamsparamvaluestr
ingZoneDetails/string 
/value/paramparamvaluestructmembernamename/namevaluestrin
g//value/membermember 
namelocation/namevaluestringUK:ABR:ABRWEST/string/value/member
membernamedescription 
/namevaluestring//value/membermembernamecategory/namevalue
stringGeography/string 
/value/membermembernameImage/namevaluestringUK_ABR_ABRWEST.gi
f/string/value/member 
membernamesavelevel/namevaluestringsavelevel/string/value/me
mber/struct/value/param 
/params/methodCall 


This is another dump using a description with no unusual characters and
description value is filled. 

Array 

( 
[name] = 
[location] = UK:ABR:ABRWEST 
[description] = Dusseldorf 
[category] = Geography 
[Image] = UK_ABR_ABRWEST.gif 
[savelevel] = savelevel 

) 

Array 

( 
[name] = 
[location] = UK:ABR:ABRWEST 
[description] = Dusseldorf 
[category] = Geography 
[Image] = UK_ABR_ABRWEST.gif 
[savelevel] = savelevel 
) 

?xml version=1.0 encoding=UTF-8? 
methodCallmethodNameForms.Process/methodNameparamsparamvaluestr
ingZoneDetails/string 
/value/paramparamvaluestructmembernamename/namevaluestrin
g//value/membermember 
namelocation/namevaluestringUK:ABR:ABRWEST/string/value/member
membernamedescription 
/namevaluestringDusseldorf/string/value/membermembernamecate
gory/namevaluestring 
Geography/string/value/membermembernameImage/namevaluestring
UK_ABR_ABRWEST.gif/string 
/value/membermembernamesavelevel/namevaluestringsavelevel/st
ring/value/member/struct 
/value/param/params/methodCall 



This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 plc internal virus protection system.



This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 plc internal virus protection system.





This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.

Re: [fw-general] Zend_Search_Lucene - how to find performance problem source?

2008-10-21 Thread Nick Thornley

Don't mean to hijack the thread, but on this same subject, I noticed  
myself that running a wildcard search '*' on even a very small index  
(handful of docs, approx 50kb) seems to take an awfully long time and  
I wondered whether that was usual?


Thanks

Nick


On 21 Oct 2008, at 14:51, Endijs Lisovskis wrote:



Thanks for your response. At least someone :)
But your suggestion will not make any difference in performance,  
because, as

I said in first email index IS optimized.
Maybe there are some potential problems with index if data is in  
UTF8 ?


How to trace - where to look for problem?

Index was made in this manner: select first 1000 articles - add to  
index -
optimize, select next 1000 articles - add to index - optimize. Of  
course:
1 article = 1 document. At the end index is optimized and consists  
from

~7350 documents.

I hope someone can help.

Endijs Lisovskis


Jurriën Stutterheim wrote:


Hi,


You should probably optimize your index before searching (and make
sure it stays optimized, using a Cron-job).
See
http://framework.zend.com/manual/en/zend.search.lucene.index-creation.html#zend.search.lucene.index-creation.optimization
 for more details on how to do this =)


- Jurriën




--
View this message in context: 
http://www.nabble.com/Zend_Search_Lucene---how-to-find-performance-problem-source--tp20085562p20090740.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: AW: [fw-general] Zend_Search_Lucene - how to find performance problem source?


No - i'm not storing main content of article in index. Only title and intro.
And intro is about couple sentences long usually.
Part from code:
$this-addField(Zend_Search_Lucene_Field::Keyword('docRef',
article:$key:lv,'utf-8'));
$this-addField(Zend_Search_Lucene_Field::UnIndexed('key',
$key,'utf-8'));
$this-addField(Zend_Search_Lucene_Field::UnIndexed('slug',
$slug,'utf-8'));
$this-addField(Zend_Search_Lucene_Field::Text('title',
$title,'utf-8'));
$this-addField(Zend_Search_Lucene_Field::UnStored('text',
$text,'utf-8'));
$this-addField(Zend_Search_Lucene_Field::UnStored('contacts',
$contacts,'utf-8'));
$this-addField(Zend_Search_Lucene_Field::Text('intro',
$intro,'utf-8'));
$this-addField(Zend_Search_Lucene_Field::Keyword('dateCreated',
$dateCreated,'utf-8'));

Will try to find out something with xdebug. I'm not expert in xdebug usage,
but it looks like time has come to upgrade skills :)

Endijs Lisovskis

Stefan Oestreicher-3 wrote:
 
 Are you storing document contents in the index? This will degrade
 performance badly in my experience (the bigger the docs, the worse the
 performance).
 If that's not the case, I'd suggest to profile your application with
 xdebug. This should reveal the culprit in no time.
 
 best regards,
 
 Stefan
 
 -Ursprüngliche Nachricht-
 Von: Endijs Lisovskis [mailto:[EMAIL PROTECTED] 
 Gesendet: Dienstag, 21. Oktober 2008 15:52
 An: fw-general@lists.zend.com
 Betreff: Re: [fw-general] Zend_Search_Lucene - how to find performance
 problem source?
 
 
 Thanks for your response. At least someone :)
 But your suggestion will not make any difference in performance, because,
 as
 I said in first email index IS optimized.
 Maybe there are some potential problems with index if data is in UTF8 ? 
 
 How to trace - where to look for problem?
 
 Index was made in this manner: select first 1000 articles - add to index
 -
 optimize, select next 1000 articles - add to index - optimize. Of
 course:
 1 article = 1 document. At the end index is optimized and consists from
 ~7350 documents. 
 
 I hope someone can help.
 
 Endijs Lisovskis 
 
 
 Jurriën Stutterheim wrote:
 
 Hi,
 
 
 You should probably optimize your index before searching (and make  
 sure it stays optimized, using a Cron-job).
 See
 http://framework.zend.com/manual/en/zend.search.lucene.index-creation.html#zend.search.lucene.index-creation.optimization
  
   for more details on how to do this =)
 
 
 - Jurriën
 
 
 
 -- 
 View this message in context:
 http://www.nabble.com/Zend_Search_Lucene---how-to-find-performance-problem-source--tp20085562p20090740.html
 Sent from the Zend Framework mailing list archive at Nabble.com.
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Zend_Search_Lucene---how-to-find-performance-problem-source--tp20085562p20091430.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] ZF performances / profiling the culprit

- Original Message - 
From: Matthew Weier O'Phinney [EMAIL PROTECTED]

To: fw-general@lists.zend.com
Sent: Tuesday, October 21, 2008 3:00 PM
Subject: Re: [fw-general] ZF performances / profiling the culprit

See if the above changes help your performance. If not, the next thing
I'd suggest trying to move to gettext for your translations to see if
that speeds things up. If so, you may be able to develop using TMX, and
write a build script that converts to gettext later.

There is one eminent thing to remember...
Performance problems will only occur when no caching is used.

After the first load into cache, ALL adapters have the same performance !!!
The only difference is the first loading time.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

Re: [fw-general] XML-RPC client and umlauts etc. question

-- Robert Castley [EMAIL PROTECTED] wrote
(on Tuesday, 21 October 2008, 03:17 PM +0100):
 Would you like me to raise a JIRA report for this?

yes, please. :)


 ━━━
 From: Robert Castley
 Sent: 20 October 2008 13:56
 To: Matthew Weier O'Phinney; fw-general@lists.zend.com
 Subject: RE: [fw-general] XML-RPC client and umlauts etc. question
 
 
 Hi Matthew,
 
 
 Thanks for responding.
  
 -
 
 Two questions for you:
 
   * Is the XML-RPC server Zend_XmlRpc_Server, or another implementation?
 
  The server is another implementation
 
   * Are you using Zend_XmlRpc_Client?
 
  Yes I am
 
  The thing to note here is that I am tracing out the XML that
  Zend_XmlRpc_Client is building up so this is before we even
  hit the server and this is where I see the values stripped.
 
 
 
 In Zend_XmlRpc_Client, we actually cast all values to UTF-8 by default
 (probably should be configurable). The only thing I can think of off the top 
 of
 my head is one of the following scenarios:
 
   * Server implementation is not capable of receiving UTF-8 characters
   * iconv not accurately detecting request character encoding, so the
 re-encoding is faulty
 
 
 
 
 Here is a complete dump for you taken using FireBug in FF 3.
 
 This array contains original form value with no modification.
 
 Array
 
 (
 
 [name] =
 [location] = UK:ABR:ABRWEST
 [description] = D sseldorf
 [category] = Geography
 [Image] = UK_ABR_ABRWEST.gif
 [savelevel] = savelevel
 
 )
 
 This array is post htmlentities convert.
 Array
 
 (
 [name] =
 [location] = UK:ABR:ABRWEST
 [description] = Duuml;sseldorf
 [category] = Geography
 [Image] = UK_ABR_ABRWEST.gif
 [savelevel] = savelevel
 )
 
 This is the Zend_XmlRpc_Client dump and the description field is blank.
 
 ?xml version=1.0 encoding=UTF-8?
 methodCallmethodNameForms.Process/methodNameparamsparamvalue
 stringZoneDetails/string
 /value/paramparamvaluestructmembernamename/namevaluestring/
 /value/membermember
 namelocation/namevaluestringUK:ABR:ABRWEST/string/value/member
 membernamedescription
 /namevaluestring//value/membermembernamecategory/namevalue
 stringGeography/string
 /value/membermembernameImage/namevaluestringUK_ABR_ABRWEST.gif/
 string/value/member
 membernamesavelevel/namevaluestringsavelevel/string/value/
 member/struct/value/param
 /params/methodCall
 
 
 This is another dump using a description with no unusual characters and
 description value is filled.
 
 Array
 
 (
 [name] =
 [location] = UK:ABR:ABRWEST
 [description] = Dusseldorf
 [category] = Geography
 [Image] = UK_ABR_ABRWEST.gif
 [savelevel] = savelevel
 
 )
 
 Array
 
 (
 [name] =
 [location] = UK:ABR:ABRWEST
 [description] = Dusseldorf
 [category] = Geography
 [Image] = UK_ABR_ABRWEST.gif
 [savelevel] = savelevel
 )
 
 ?xml version=1.0 encoding=UTF-8?
 methodCallmethodNameForms.Process/methodNameparamsparamvalue
 stringZoneDetails/string
 /value/paramparamvaluestructmembernamename/namevaluestring/
 /value/membermember
 namelocation/namevaluestringUK:ABR:ABRWEST/string/value/member
 membernamedescription
 /namevaluestringDusseldorf/string/value/membermembername
 category/namevaluestring
 Geography/string/value/membermembernameImage/namevaluestring
 UK_ABR_ABRWEST.gif/string
 /value/membermembernamesavelevel/namevaluestringsavelevel/
 string/value/member/struct
 /value/param/params/methodCall
 
 
 
 This email has been scanned for all known viruses by the MessageLabs Email
 Security Service and the Macro 4 plc internal virus protection system.
 
 
 
 This email has been scanned for all known viruses by the MessageLabs Email
 Security Service and the Macro 4 plc internal virus protection system.
 
 
 
 This email has been scanned for all known viruses by the MessageLabs Email
 Security Service and the Macro 4 plc internal virus protection system.
 

-- 
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/

Re: [fw-general] ZF performances / profiling the culprit

2008-10-21 Thread Bruno Friedmann

Thomas Weidner wrote:

 - Original Message - From: Matthew Weier O'Phinney
 [EMAIL PROTECTED]
 To: fw-general@lists.zend.com
 Sent: Tuesday, October 21, 2008 3:00 PM
 Subject: Re: [fw-general] ZF performances / profiling the culprit

 See if the above changes help your performance. If not, the next thing
 I'd suggest trying to move to gettext for your translations to see if
 that speeds things up. If so, you may be able to develop using TMX, and
 write a build script that converts to gettext later.
Sure but tmx have some nice feature ( human and xml )
and doesn't need compilation. and extraction.

 There is one eminent thing to remember...
 Performance problems will only occur when no caching is used.

 After the first load into cache, ALL adapters have the same performance !!!
 The only difference is the first loading time.

Thanks about That Thomas, tmx work correctly only from 1.7 with cache ( locale 
and translate )
before 1.7 inside cache only the first call to translate are in ( If first user 
call is en then there's only en string retrieved
, if fr is first call, all user get the french )
Now with the 1.7 all is working as expected.

-- 

 Bruno Friedmann

Ioda-Net Sàrl
  2830 Vellerat - Switzerland

  Tél : ++41 32 435 7171
  Fax : ++41 32 435 7172
  gsm : ++41 78 802 6760
  www.ioda-net.ch

 Centre de Formation et de Coaching En Ligne
 www.cfcel.com

Re: AW: [fw-general] Zend_Search_Lucene - how to find performance problem source?


I tried to profile script and got some very strange results.
For test i made index from 2000 documents. Index was 6MB in size and
optimized.

Xdebug made ~500MB large cachegrind file! Is that normal? When I opened that
file with KCacheGrind result was: http://prcentrs.lv/kca.png

Tests were executed on my notebook - so on server they would run faster. But
even on notebook (dualcore cpu, 2gb ram) it shouldnt take more than minute
to finish.

Can anyone understand something from that cachegrind report and tell me -
what is wrong with my script and/or index.

If that helps - i'm using:
Zend_Search_Lucene_Analysis_Analyzer::setDefault( new
Zend_Search_Lucene_Analysis_Analyzer_Common_Utf8_CaseInsensitive());

Endijs


Stefan Oestreicher-3 wrote:
 
 Are you storing document contents in the index? This will degrade
 performance badly in my experience (the bigger the docs, the worse the
 performance).
 If that's not the case, I'd suggest to profile your application with
 xdebug. This should reveal the culprit in no time.
 
 best regards,
 
 Stefan
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Zend_Search_Lucene---how-to-find-performance-problem-source--tp20085562p20092853.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] ZF performances / profiling the culprit


There is one eminent thing to remember...
Performance problems will only occur when no caching is used.

After the first load into cache, ALL adapters have the same performance 
!!!

The only difference is the first loading time.

Thanks about That Thomas, tmx work correctly only from 1.7 with cache ( 
locale and translate )
before 1.7 inside cache only the first call to translate are in ( If first 
user call is en then there's only en string retrieved

, if fr is first call, all user get the french )
Now with the 1.7 all is working as expected.


That was one of the reasons why I reworked I18N.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

Re: [fw-general] Multiple Controller Directories

2008-10-21 Thread zijin


I came across the same problem, I extend Zend_Controller_Dispatcher_Standard,
which appears to work. Instead of setting a single directory in
setControllerDirectory(), the directories set in setControllerDirectory()
are comma delimited.

First load the following class:

class Controller_Dispatcher_Custom extends
Zend_Controller_Dispatcher_Standard
{

public function loadClass($className)
{
$finalClass  = $className;
if (($this-_defaultModule != $this-_curModule) 
|| $this-getParam('prefixDefaultModule')) 
{
$finalClass = $this-formatClassName($this-_curModule,
$className);
}
if (class_exists($finalClass, false)) {
return $finalClass;
}

$dispatchDir = $this-getDispatchDirectory();

//there maybe more than one dispatch dir delimited by comma, load in
the reverse order
$dirs = split(',',$dispatchDir);
for ($i = (count($dirs) - 1); $i = 0 ; $i--) {
$loadFile= $dirs[$i] . DIRECTORY_SEPARATOR .
$this-classToFilename($className);
$dir = dirname($loadFile);
$file= basename($loadFile);

if (Zend_Loader::isReadable($loadFile)) {
try {
Zend_Loader::loadFile($file, $dir, true);
break;
} catch (Zend_Exception $e) {
require_once 
'Zend/Controller/Dispatcher/Exception.php';
throw new 
Zend_Controller_Dispatcher_Exception('Cannot load
controller class ' . $className . ' from file ' . $file . ' in directory
' . $dir . '');
}
}
}
if (!class_exists($finalClass, false)) {
require_once 'Zend/Controller/Dispatcher/Exception.php';
throw new Zend_Controller_Dispatcher_Exception('Invalid
controller class (' . $finalClass . ')');
}

return $finalClass;
}

public function isDispatchable(Zend_Controller_Request_Abstract
$request)
{
$className = $this-getControllerClass($request);
if (!$className) {
return false;
}

if (class_exists($className, false)) {
return true;
}

$fileSpec= $this-classToFilename($className);
$dispatchDir = $this-getDispatchDirectory();

$dirs = split(',',$dispatchDir);

foreach ($dirs as $dir) {
$test   = $dir . DIRECTORY_SEPARATOR . $fileSpec;
if (Zend_Loader::isReadable($test)) return true;
}

return false;
}

}

Then in bootstrap, I do:

$frontController = Zend_Controller_Front::getInstance();
$frontController-setDispatcher(new Controller_Dispatcher_Custom());
$frontController-setControllerDirectory(array(
'default' = 'dir1,dir2'
));


Hope it helps, any comments or suggestions let me know.

thanks



maxarbos wrote:
 
 Hello,
 
 I want to know if it is possible to have multiple controller directories
 without having to use the module name in the url?
 
 What I am looking to do is have sub1.domain.com point to /application/sub1 
 and sub2.domain.com point to /application/sub2
 
 within the /application dir, there is one main dir (the default one,
 named: commonground)  that runs the ACL and custom conrollers.
 
 So the dir structire looks like this:
 
 /application
 --/commonground
 /controllers
 --/AclController.php
 --/sub1
 /controllers
 --/HelloController.php
 --/sub2
 /controllers
 --/SecretController.php
 
 I want to call one bootstrap with all subX.domains.com  and have the
 --/commonground dir process stuff like the ACL, but then when
 sub2.domain.com/secret is called, it checks in the /commonground first and
 then into the /sub2 dir.
 
 I tried addControllerDirectory  but without a module name, it overwrites
 the default controller dir.
 
 I dont want to use sub2.domain.com/sub2/secret but instead want the
 subdomain to control which dir it has access to. I am doing this by
 SEVER_NAME.
 
 Any advice would be great, thanks.
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Multiple-Controller-Directories-tp18879750p20095074.html
Sent from the Zend Framework mailing list archive at Nabble.com.

[fw-general] Appcelerator + Zend Framework

2008-10-21 Thread pstatus


I'm currently trying to implement accelerator to my existing project, but
can't figure out how to recieve json messages from controllers. In webinar
we saw the Service folder but it doesn't interract with models,
controllers or something, it just changed the string. Could anyone provide a
short example of implemention this thing into zf? I am confused, there is a
post in appcelerator forum similar to mine but I want to ask this question
more to zf developers.
http://www.appcelerator.org/group?id=2topic=589#post=3362 similar post 
P.S.
Sorry for my bad english
-- 
View this message in context: 
http://www.nabble.com/Appcelerator-%2B-Zend-Framework-tp20096356p20096356.html
Sent from the Zend Framework mailing list archive at Nabble.com.

RE: [fw-general] Zend_Search_Lucene - how to find performance problem source?

 -Original Message-
 From: Nick Thornley [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 21, 2008 6:19 PM
 To: fw-general@lists.zend.com
 Subject: Re: [fw-general] Zend_Search_Lucene - how to find performance
 problem source?

 Don't mean to hijack the thread, but on this same subject, I noticed
 myself that running a wildcard search '*' on even a very small index
 (handful of docs, approx 50kb) seems to take an awfully long time and
 I wondered whether that was usual?

Yes. It actually gets a list of all terms, searches for all terms and union 
results.
Scores are calculated while this operation. Calculation depends on current 
Similarity class and can't be omitted even whole set of documents are returned.

 Thanks

 Nick

 On 21 Oct 2008, at 14:51, Endijs Lisovskis wrote:

  Thanks for your response. At least someone :)
  But your suggestion will not make any difference in performance,
  because, as
  I said in first email index IS optimized.
  Maybe there are some potential problems with index if data is in
  UTF8 ?

  How to trace - where to look for problem?

  Index was made in this manner: select first 1000 articles - add to
  index -
  optimize, select next 1000 articles - add to index - optimize. Of
  course:
  1 article = 1 document. At the end index is optimized and consists
  from
  ~7350 documents.

  I hope someone can help.

  Endijs Lisovskis

  Jurriën Stutterheim wrote:

  Hi,

  You should probably optimize your index before searching (and make
  sure it stays optimized, using a Cron-job).
  See
  http://framework.zend.com/manual/en/zend.search.lucene.index-
 creation.html#zend.search.lucene.index-creation.optimization
   for more details on how to do this =)

  - Jurriën

  --
  View this message in context: http://www.nabble.com/Zend_Search_Lucene--
 -how-to-find-performance-problem-source--tp20085562p20090740.html
  Sent from the Zend Framework mailing list archive at Nabble.com.

 No virus found in this incoming message.
 Checked by AVG - http://www.avg.com
 Version: 8.0.173 / Virus Database: 270.8.1/1733 - Release Date: 20.10.2008
 14:52

RE: [fw-general] [Lucene] Narrowing down search

Hi Jurriën,

Zend_Search_Lucene doesn't give possibility of narrowing down search.

But it may be changed in the nearest future (that's a part of 
Zend_Search_Lucene performance improvement tasks I'm working on right now :))

So I'm extremely interested to tests result of these improvements with your 
application ;)


On the other hands, that may not give expected result if the original 
date-range query is slow enough.
You could try to use a set of indices - one index for month or quarter and 
perform several searches to cover whole time period. Only two subsearches will 
need date-range subquery.


With best regards,
   Alexander Veremyev.

 -Original Message-
 From: Jurriën Stutterheim [mailto:[EMAIL PROTECTED]
 Sent: Saturday, October 18, 2008 12:51 PM
 To: Zend Framework - General
 Subject: Re: [fw-general] [Lucene] Narrowing down search
 
 * bump *
 
 Anyone?
 
 
 On Oct 15, 2008, at 14:36 , Jurriën Stutterheim wrote:
 
  Hi all,
 
 
  In my search index with roughly 200k documents I need to be able to
  search on document dates. I've already got a nice ranged query
  working and it returns the right results. In addition to the date
  fields the search form of course also provides a text field so the
  user can search for some keywords.
 
  My main problem now is that the date-range query is incredibly slow
  when it's spread across more than a few years. One of the solutions
  I came up with was to search for the keywords first, and then narrow
  those results down by using a date-range query.
 
  Is this possible?
 
 
  - Jurriën

RE: [fw-general] Zend_Search_Lucene - how to find performance problem source?

Storing documents doesn't actually affect search performance, BUT... It affects 
document retrieving time, which is performed automatically at first access to 
any stored field of QueryHit object.

With best regards,
   Alexander Veremyev.

 -Original Message-
 From: Stefan Oestreicher [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 21, 2008 6:05 PM
 To: Zend Framework - General
 Subject: AW: [fw-general] Zend_Search_Lucene - how to find performance
 problem source?
 
 Are you storing document contents in the index? This will degrade
 performance badly in my experience (the bigger the docs, the worse the
 performance).
 If that's not the case, I'd suggest to profile your application with
 xdebug. This should reveal the culprit in no time.
 
 best regards,
 
 Stefan
 
 -Ursprüngliche Nachricht-
 Von: Endijs Lisovskis [mailto:[EMAIL PROTECTED]
 Gesendet: Dienstag, 21. Oktober 2008 15:52
 An: fw-general@lists.zend.com
 Betreff: Re: [fw-general] Zend_Search_Lucene - how to find performance
 problem source?
 
 
 Thanks for your response. At least someone :)
 But your suggestion will not make any difference in performance, because,
 as
 I said in first email index IS optimized.
 Maybe there are some potential problems with index if data is in UTF8 ?
 
 How to trace - where to look for problem?
 
 Index was made in this manner: select first 1000 articles - add to index
 -
 optimize, select next 1000 articles - add to index - optimize. Of course:
 1 article = 1 document. At the end index is optimized and consists from
 ~7350 documents.
 
 I hope someone can help.
 
 Endijs Lisovskis
 
 
 Jurriën Stutterheim wrote:
 
  Hi,
 
 
  You should probably optimize your index before searching (and make
  sure it stays optimized, using a Cron-job).
  See
  http://framework.zend.com/manual/en/zend.search.lucene.index-
 creation.html#zend.search.lucene.index-creation.optimization
for more details on how to do this =)
 
 
  - Jurriën
 
 
 
 --
 View this message in context: http://www.nabble.com/Zend_Search_Lucene---
 how-to-find-performance-problem-source--tp20085562p20090740.html
 Sent from the Zend Framework mailing list archive at Nabble.com.
 
 
 No virus found in this incoming message.
 Checked by AVG - http://www.avg.com
 Version: 8.0.173 / Virus Database: 270.8.1/1733 - Release Date: 20.10.2008
 14:52

RE: [fw-general] Zend_Search_Lucene - how to find performance problem source?


 I doubt that this is hosting provider problem, because in one other
 project I
 use Zend_Search_Lucene and there are no problems with speed.
 I used optimize() after each 1000 documents, because before adding each
 document i'm performing search - to verify that index already does not
 contain the same document.

BTW Use $index-TermDocs($term) to get lest of documents matching a specified 
term. It's faster since it doesn't need to calculate scores.


 
 One more question - is that OK that index of ~7350 documents is about 25MB
 in size? Each document = an article. In average article = 250words.
 
 Endijs Lisovskis
 
 
 Jurriën Stutterheim wrote:
 
  Sorry, I completely overlooked that bit of your email. I'm not sure
  about the bottleneck in that case... it might be your hosting provider
  with a (very, very) slow server? An index as small as ~7350 docs and a
  limit of 150 results should be lightning fast...
  You can speed up your indexing process by the way. Just let it index
  all documents and do one optimze() afterwards.
 
 
 
 
 --
 View this message in context: http://www.nabble.com/Zend_Search_Lucene---
 how-to-find-performance-problem-source--tp20085562p20091058.html
 Sent from the Zend Framework mailing list archive at Nabble.com.

RE: AW: [fw-general] Zend_Search_Lucene - how to find performance problem source?

 -Original Message-
 From: Endijs Lisovskis [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 21, 2008 7:29 PM
 To: fw-general@lists.zend.com
 Subject: Re: AW: [fw-general] Zend_Search_Lucene - how to find
performance
 problem source?

 I tried to profile script and got some very strange results.
 For test i made index from 2000 documents. Index was 6MB in size and
 optimized.

 Xdebug made ~500MB large cachegrind file! Is that normal? When I
opened
 that file with KCacheGrind result was: http://prcentrs.lv/kca.png

 Tests were executed on my notebook - so on server they would run
faster.
 But
 even on notebook (dualcore cpu, 2gb ram) it shouldnt take more than
minute
 to finish.

 Can anyone understand something from that cachegrind report and tell
me -
 what is wrong with my script and/or index.

XDebug is not actually best tool for search profiling.

Search time hardly depends on indexed data.

Luke tool (http://www.getopt.org/luke/) may be very informative.

Check also output of the following expressions (it gives actual query
execution order):
1.
echo
Zend_Search_Lucene_Search_QueryParser::parse($queryStr)-__toString();

2.
$query = Zend_Search_Lucene_Search_QueryParser::parse($queryStr);
echo $query-rewrite($index)-__toString();

3.
$query = Zend_Search_Lucene_Search_QueryParser::parse($queryStr);
echo $query-rewrite($index)-optimize($index)-__toString();

Latest step (or you could start with it :)), you can create JIRA issue
with performance problem description, query example and attached index
example (or send it directly to me :)).

 If that helps - i'm using:
 Zend_Search_Lucene_Analysis_Analyzer::setDefault( new
 Zend_Search_Lucene_Analysis_Analyzer_Common_Utf8_CaseInsensitive());

Analyzers are used to tokenize documents while indexing and perform some
transformations with lexemes while query parsing.
So it's important to use the same analyzers while indexing and
searching, but they don't actually affect searching process.

With best regards,
   Alexander Veremyev.

 Endijs

 Stefan Oestreicher-3 wrote:

  Are you storing document contents in the index? This will degrade
  performance badly in my experience (the bigger the docs, the worse
the
  performance).
  If that's not the case, I'd suggest to profile your application with
  xdebug. This should reveal the culprit in no time.

  best regards,

  Stefan

 --
 View this message in context:
http://www.nabble.com/Zend_Search_Lucene---
 how-to-find-performance-problem-source--tp20085562p20092853.html
 Sent from the Zend Framework mailing list archive at Nabble.com.

 No virus found in this incoming message.
 Checked by AVG - http://www.avg.com
 Version: 8.0.173 / Virus Database: 270.8.1/1733 - Release Date:
20.10.2008
 14:52

[fw-general] Major Issues with Zend Auth

2008-10-21 Thread Matthew Ishii

I am having major issues here, I had thought that separating the login
processing and the logout functions from the index page where the
actual login form is rendered would solve the issues im having but I
was mistaken.  The issue still remains, I select logout and the
browser hourglasses and times out.

Is there some internal MVC zend log that I can take a look at?  I have
taken a look at the apache logs but nothing happens.  Its as if the
request is stuck in the framework.  Im not sure it will help, but this
is my logout function and my index function inside the index
controller:

class IndexController extends Zend_Controller_Action
{


   public function indexAction()
   {
 $config = Zend_Registry::get('config');

 $this-view-title   = $config-english-login-title;
 $this-view-baseurl = $config-production-hosturl;
 $this-view-shead   = $config-english-login-subheader;
 $this-view-form= $this-getLoginForm();

 $this-_helper-layout-disableLayout();
   }


And logout function:


   public function logoutAction()
   {
 Zend_Auth::getInstance()-clearIdentity();
 return $this-_helper-redirector('index');
   }

Re: [fw-general] Invalid controller specified error - HELP!

2008-10-21 Thread thurting

Oops ... I was developing on Win and deploying to Unix and had a problem with
case sensitivity. ZF was looking for the file in
controllers/Admin/SomeAdminController.php and I had it named as
controllers/admin/SomeAdminController.php - Argh! In any case, I got it
working.

thurting wrote:

Hi all,

I am in the middle of developing a project and am encountering a strange
error. The structure of my project is like so:

/application
/modules
/default
/controllers
/admin
SomeAdminController.php
SomeController.php

On my local machine I can get SomeAdminController.php to open fine using
methods involving no-rewrite/rewrite/routing. The behavior acts as it
should and everything is fine. However, when I deploy to my staging
machine, I am getting 404s when I try to access controllers that live in
the admin directory. I've tried to access these controllers a bunch of
different ways and I keep getting an error. For example, when I try to
access the Admin_LoginController
(/application/modules/default/controllers/admin/LoginController.php), I
get:

exception 'Zend_Controller_Dispatcher_Exception' with message 'Invalid
controller specified (admin_login)'

The file is there and it is good (it's synced with my local box, which
again, is working). I'm thinking my naming conventions may be off, but it
works locally so I am confused. Any insight?

--
View this message in context:
http://www.nabble.com/Invalid-controller-specified-error---HELP%21-tp20096365p20097137.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Problems with Zend_Form_Element_File since ZF1.6.2

2008-10-21 Thread andersl


Hi

I got the trunk from yesterday and even though I add the rename filter I
still dont get any value from the getValue. The file gets uploaded but the
getValue just dont return anything. I use addElements to get the element on
the screen. Could this be the issue? My code looks something like this:
...
$this-setAttrib('enctype', 'multipart/form-data');
...
//picture
$picture = new Zend_Form_Element_File('picture');
$picture-setLabel('Picture')
-setRequired(true)
-setDestination('/var/www/images')
-addValidator('Count', false, 1) // ensure only 1 file
-addValidator('Size', false, 1MB) 
-addValidator('Extension', false, 'jpg,png,gif,jpeg')
-addFilter('Rename', array('/var/www/images', true))
; // only JPEG, PNG, and GIFs   
...
$submit = new Zend_Form_Element_Submit('submit');
$submit-setAttrib('id', 'submitbutton');
$this-addElements(array($id, $name, $picture, $submit))
 
and in my controller I have:

if (!$form-picture-receive()) 
{
print Error receiving the file;
}

//$row-picture = $form-picture-getValue();
//$row-picture = $form-getValue('picture'); 

both getValue gives me nothing :(

Im looking forward to your reply :)

Anders

thomasW wrote:
 
 As reply to an mail this has been sent on 15.Oct:
 -
 Yes, this issue was added 7 hours ago and have already been fixed in trunk
 and branch.
 To solve this shortly you can:
 
 * Do not use addElement on the file element... the reason is that
 getValue()
 will be called on the file elements but they have no value and behave
 false
 in such a condition
 or
 * Add a empty rename filter by setting source and target the same value
 --
 
 Greetings
 Thomas Weidner, I18N Team Leader, Zend Framework
 http://www.thomasweidner.com
 
 - Original Message - 
 From: drj201 [EMAIL PROTECTED]
 To: fw-general@lists.zend.com
 Sent: Monday, October 20, 2008 1:21 PM
 Subject: [fw-general] Problems with Zend_Form_Element_File since ZF1.6.2
 
 

 I am trying to add a Zend_Form_Element File to a form... I am extending
 Zend_Form with my own class for reuse purposes. The problem is that since
 upgrading to ZF 1.6.2 my code no longer works.

 Build element:

 $this-addElement('file', 'logo', array(
'label' = 'Logo',
 ...etc
));

 Add to form using group decorator:

 $this-addDisplayGroup(
array('logo'), 'logodata',
array(
'legend' = 'Dealer Logo'
)
);

 This results in the following error:

 Warning: Exception caught by form: Unknown file Stack Trace: #0
 demoapp/lib/Zend/Form/Element/File.php(357):
 Zend_File_Transfer_Adapter_Abstract-getFilters('logo') #1
 demoapp/lib/Zend/Form/Element.php(524): 
 Zend_Form_Element_File-getFilters()
 #2 demoapp/lib/Zend/Form/Element.php(541):
 Zend_Form_Element-_filterValue(NULL, NULL) #3
 demoapp/lib/Zend/Form/Decorator/ViewHelper.php(201):
 Zend_Form_Element-getValue() #4
 demoapp/lib/Zend/Form/Decorator/ViewHelper.php(231):
 Zend_Form_Decorator_ViewHelper-getValue(Object(Zend_Form_Element_File)) 
 #5
 demoapp/lib/Zend/Form/Element.php(1905):
 Zend_Form_Decorator_ViewHelper-render('') #6
 demoapp/lib/Zend/Form/Decorator/FormElements.php(100):
 Zend_Form_Element-render() #7 demoapp/lib/Zend/Form.php(2596):
 Zend_Form_Decorator_FormElements-render('') #8 /Applicat in
 demoapp/lib/Zend/Form.php on line 2616


 Using the following manual approach works fine:

 $element = new Zend_Form_Element_File('foo');
 $element-setLabel('Upload an image:')
 ...etc

 Any reason this has happened since upgrading to 1.6.2?

 Thanks,
 David
 -- 
 View this message in context: 
 http://www.nabble.com/Problems-with-Zend_Form_Element_File-since-ZF1.6.2-tp20067249p20067249.html
 Sent from the Zend Framework mailing list archive at Nabble.com. 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Problems-with-Zend_Form_Element_File-since-ZF1.6.2-tp20067249p20097147.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Major Issues with Zend Auth

-- Matthew Ishii [EMAIL PROTECTED] wrote
(on Tuesday, 21 October 2008, 11:58 AM -0700):
 I am having major issues here, I had thought that separating the login
 processing and the logout functions from the index page where the
 actual login form is rendered would solve the issues im having but I
 was mistaken.  The issue still remains, I select logout and the
 browser hourglasses and times out.
 
 Is there some internal MVC zend log that I can take a look at?  

No -- you'd have to set that up yourself.

Take a look at how authentication is done in the bugapp example app I
did for the Dutch PHP Conference:

http://github.com/weierophinney/bugapp

It does login and logout, and it's done very simply and
straight-forward.

 I have
 taken a look at the apache logs but nothing happens.  Its as if the
 request is stuck in the framework.  Im not sure it will help, but this
 is my logout function and my index function inside the index
 controller:
 
 class IndexController extends Zend_Controller_Action
 {
 
 
public function indexAction()
{
  $config = Zend_Registry::get('config');
 
  $this-view-title   = $config-english-login-title;
  $this-view-baseurl = $config-production-hosturl;
  $this-view-shead   = $config-english-login-subheader;
  $this-view-form= $this-getLoginForm();
 
  $this-_helper-layout-disableLayout();
}
 
 
 And logout function:
 
 
public function logoutAction()
{
  Zend_Auth::getInstance()-clearIdentity();
  return $this-_helper-redirector('index');
}
 

-- 
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/

Re: [fw-general] Problems with Zend_Form_Element_File since ZF1.6.2


In trunk you don't have to add a empty rename filter.
And file elements do not have a value until now due to security reasons.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

- Original Message - 
From: andersl [EMAIL PROTECTED]

To: fw-general@lists.zend.com
Sent: Tuesday, October 21, 2008 9:18 PM
Subject: Re: [fw-general] Problems with Zend_Form_Element_File since ZF1.6.2




Hi

I got the trunk from yesterday and even though I add the rename filter I
still dont get any value from the getValue. The file gets uploaded but the
getValue just dont return anything. I use addElements to get the element 
on

the screen. Could this be the issue? My code looks something like this:
...
$this-setAttrib('enctype', 'multipart/form-data');
...
   //picture
   $picture = new Zend_Form_Element_File('picture');
$picture-setLabel('Picture')
-setRequired(true)
   -setDestination('/var/www/images')
   -addValidator('Count', false, 1) // ensure only 1 file
   -addValidator('Size', false, 1MB)
   -addValidator('Extension', false, 'jpg,png,gif,jpeg')
   -addFilter('Rename', array('/var/www/images', true))
   ; // only JPEG, PNG, and GIFs
...
$submit = new Zend_Form_Element_Submit('submit');
$submit-setAttrib('id', 'submitbutton');
$this-addElements(array($id, $name, $picture, $submit))

and in my controller I have:

if (!$form-picture-receive())
{
print Error receiving the file;
}

//$row-picture = $form-picture-getValue();
//$row-picture = $form-getValue('picture');

both getValue gives me nothing :(

Im looking forward to your reply :)

Anders

thomasW wrote:


As reply to an mail this has been sent on 15.Oct:
-
Yes, this issue was added 7 hours ago and have already been fixed in 
trunk

and branch.
To solve this shortly you can:

* Do not use addElement on the file element... the reason is that
getValue()
will be called on the file elements but they have no value and behave
false
in such a condition
or
* Add a empty rename filter by setting source and target the same value
--

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

- Original Message - 
From: drj201 [EMAIL PROTECTED]

To: fw-general@lists.zend.com
Sent: Monday, October 20, 2008 1:21 PM
Subject: [fw-general] Problems with Zend_Form_Element_File since ZF1.6.2




I am trying to add a Zend_Form_Element File to a form... I am extending
Zend_Form with my own class for reuse purposes. The problem is that 
since

upgrading to ZF 1.6.2 my code no longer works.

Build element:

$this-addElement('file', 'logo', array(
   'label' = 'Logo',
...etc
   ));

Add to form using group decorator:

$this-addDisplayGroup(
   array('logo'), 'logodata',
   array(
   'legend' = 'Dealer Logo'
   )
   );

This results in the following error:

Warning: Exception caught by form: Unknown file Stack Trace: #0
demoapp/lib/Zend/Form/Element/File.php(357):
Zend_File_Transfer_Adapter_Abstract-getFilters('logo') #1
demoapp/lib/Zend/Form/Element.php(524):
Zend_Form_Element_File-getFilters()
#2 demoapp/lib/Zend/Form/Element.php(541):
Zend_Form_Element-_filterValue(NULL, NULL) #3
demoapp/lib/Zend/Form/Decorator/ViewHelper.php(201):
Zend_Form_Element-getValue() #4
demoapp/lib/Zend/Form/Decorator/ViewHelper.php(231):
Zend_Form_Decorator_ViewHelper-getValue(Object(Zend_Form_Element_File))
#5
demoapp/lib/Zend/Form/Element.php(1905):
Zend_Form_Decorator_ViewHelper-render('') #6
demoapp/lib/Zend/Form/Decorator/FormElements.php(100):
Zend_Form_Element-render() #7 demoapp/lib/Zend/Form.php(2596):
Zend_Form_Decorator_FormElements-render('') #8 /Applicat in
demoapp/lib/Zend/Form.php on line 2616


Using the following manual approach works fine:

$element = new Zend_Form_Element_File('foo');
$element-setLabel('Upload an image:')
...etc

Any reason this has happened since upgrading to 1.6.2?

Thanks,
David
--
View this message in context:
http://www.nabble.com/Problems-with-Zend_Form_Element_File-since-ZF1.6.2-tp20067249p20067249.html
Sent from the Zend Framework mailing list archive at Nabble.com.






--
View this message in context: 
http://www.nabble.com/Problems-with-Zend_Form_Element_File-since-ZF1.6.2-tp20067249p20097147.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] ZF performances / profiling the culprit

2008-10-21 Thread Bruno Friedmann

Matthew Weier O'Phinney wrote:
 -- Bruno Friedmann [EMAIL PROTECTED] wrote
 (on Tuesday, 21 October 2008, 06:56 AM +0200):
 Matthew Weier O'Phinney wrote:
 -- Bruno Friedmann [EMAIL PROTECTED] wrote
 (on Monday, 20 October 2008, 07:00 AM +0200):
 Matthew Weier O'Phinney wrote:
 -- Bruno Friedmann [EMAIL PROTECTED] wrote
 (on Sunday, 19 October 2008, 07:30 PM +0200):
 With the help of ZendStudio, I'm trying to understand why on one
 application I've got 25/30 req/s and on the second one I've only a
 5/5.50 req (1.6.2) or a 7/8.2rqs ( 1.7.0 notice the little change )
 ( a simple html file is giving a 385rqs and a 404 error page give around 
 a 280/320rqs )

 The profile result give me a 59% time consume by Layout ( which I
 doesn't have on the speed app ) and another 12.5% to Translate
 ( ok I'm using tmx which is not the most speedy thing )
 You can save me a little time and effort here by attaching the layout
 script you use, as well as a count of the number of times calls are made
 to translate items. With that information, I can add some information to
 our performance and profiling test suite.

 Quickly I'm calling the index controlleur / index view with layout.
 html/index.php
 - ZFApplication ( which is the real bootstrap )
 - app/Module/Default
 - /Controller/indexController 
- Action indexAction
 - Scripts/index/index.phtml

 Layout contain
 |-- common
 |   |-- footer.phtml
 |   |-- header.phtml
 |   |-- help.phtml
 |   `-- menu.phtml
 `-- main.phtml

 For the index view there's a test
 if ( !Zend_Auth::getInstance()- hasIdentity() ):
 // Render login form or logged
 echo $this- action(null, 'login');
// If we are anonymous

 --
 For translation I've a global function __($str) which translate strings.

 For the whole projet there's a 945 call to it.

 For the index call profiled it's about 24 calls.
 The above may very well be the culprit, but I'll write a test just to
 see.

 Can you give the contents of your layout files? I'm curious to see how
 you're pulling in content -- if you're using partial(), action(), or
 simply render(). I've already identified a bottleneck in partial() that
 I'll be working on. Additionally, I typically recommend against action()
 because I know already that internally it's expensive; it's cheaper to
 create a helper that pulls from the model directly.

 If what you say is correct, I'm in trouble :-)

 You will see why in the source attached ...

 So I'm waiting your confirmation, and eventually other recommandations.
 There's some refactoring/rewritting in the air tonight :-)
 
 The only reason to use partial() instead of render() is when you
 absolutely need a clean variable scope for the rendered view script. In
 your case, I'd recommend simply substituting render() for each time you
 use partial(); this will definitely improve speed.
 

Ok this remark make sense ... I think it should find it's place as remark in 
docs.

 I see you're using action() to pull in a login form. Since you won't be
 worried about pre-populated values or validation, it may make more sense
 here to either instantiate the form object directly and display it, or
 create a view helper that does this. 

To be honest, I'm actually in a process to limits the number of view helper to 
a quantic's number.
I feel I'm on the wrong way. Too strict perhaps in the logic approach
There a login controller in which the login form  logic reside so I'm calling 
it because layout permit this,
leaving all login to it's own controller/model/form/view system.


 
 See if the above changes help your performance. If not, the next thing
 I'd suggest trying to move to gettext for your translations to see if
 that speeds things up. If so, you may be able to develop using TMX, and
 write a build script that converts to gettext later.
 
I will give them a try on Thursday and Friday and keep you inform of the result.

In your Guru's opinion, shall I try the svn version of 1.7 or could I stay with 
the PR release ?

Thanks all for you great advise, help each of us making php/ZF better and 
better, also in developer mind and how to approach 
realize great things with.

-- 

 Bruno Friedmann

Ioda-Net Sàrl
  2830 Vellerat - Switzerland

Re: [fw-general] ZF performances / profiling the culprit

-- Bruno Friedmann [EMAIL PROTECTED] wrote
(on Tuesday, 21 October 2008, 09:45 PM +0200):
 Matthew Weier O'Phinney wrote:
  -- Bruno Friedmann [EMAIL PROTECTED] wrote
  (on Tuesday, 21 October 2008, 06:56 AM +0200):
   Matthew Weier O'Phinney wrote:
-- Bruno Friedmann [EMAIL PROTECTED] wrote
(on Monday, 20 October 2008, 07:00 AM +0200):
 Matthew Weier O'Phinney wrote:
  -- Bruno Friedmann [EMAIL PROTECTED] wrote
  (on Sunday, 19 October 2008, 07:30 PM +0200):
   With the help of ZendStudio, I'm trying to understand why on one
   application I've got 25/30 req/s and on the second one I've only a
   5/5.50 req (1.6.2) or a 7/8.2rqs ( 1.7.0 notice the little change 
   )
   ( a simple html file is giving a 385rqs and a 404 error page give 
   around a 280/320rqs )
  
   The profile result give me a 59% time consume by Layout ( which I
   doesn't have on the speed app ) and another 12.5% to Translate
   ( ok I'm using tmx which is not the most speedy thing )
  You can save me a little time and effort here by attaching the 
  layout
  script you use, as well as a count of the number of times calls are 
  made
  to translate items. With that information, I can add some 
  information to
  our performance and profiling test suite.
 
 Quickly I'm calling the index controlleur / index view with layout.
 html/index.php
 - ZFApplication ( which is the real bootstrap )
 - app/Module/Default
 - /Controller/indexController
   - Action indexAction
 - Scripts/index/index.phtml
   
 Layout contain
 |-- common
 |   |-- footer.phtml
 |   |-- header.phtml
 |   |-- help.phtml
 |   `-- menu.phtml
 `-- main.phtml

 For the index view there's a test
 if ( !Zend_Auth::getInstance()- hasIdentity() ):
 // Render login form or logged
 echo $this- action(null, 'login');
// If we are anonymous

 --
 For translation I've a global function __($str) which translate 
 strings.

 For the whole projet there's a 945 call to it.

 For the index call profiled it's about 24 calls.
The above may very well be the culprit, but I'll write a test just to
see.
   
Can you give the contents of your layout files? I'm curious to see how
you're pulling in content -- if you're using partial(), action(), or
simply render(). I've already identified a bottleneck in partial() that
I'll be working on. Additionally, I typically recommend against action()
because I know already that internally it's expensive; it's cheaper to
create a helper that pulls from the model directly.
   
   If what you say is correct, I'm in trouble :-)
  
   You will see why in the source attached ...
  
   So I'm waiting your confirmation, and eventually other recommandations.
   There's some refactoring/rewritting in the air tonight :-)
  
  The only reason to use partial() instead of render() is when you
  absolutely need a clean variable scope for the rendered view script. In
  your case, I'd recommend simply substituting render() for each time you
  use partial(); this will definitely improve speed.
  
 
 Ok this remark make sense ... I think it should find it's place as remark in 
 docs.
 
  I see you're using action() to pull in a login form. Since you won't be
  worried about pre-populated values or validation, it may make more sense
  here to either instantiate the form object directly and display it, or
  create a view helper that does this. 
 
 To be honest, I'm actually in a process to limits the number of view
 helper to a quantic's number.
 I feel I'm on the wrong way. Too strict perhaps in the logic approach
 There a login controller in which the login form  logic reside so I'm
 calling it because layout permit this,
 leaving all login to it's own controller/model/form/view system.

Makes sense. Just remember that this is an expensive operation. You may
want to consider a view helper that calls the action() helper, but
caches the results.

  See if the above changes help your performance. If not, the next
  thing I'd suggest trying to move to gettext for your translations to
  see if that speeds things up. If so, you may be able to develop
  using TMX, and write a build script that converts to gettext later.
  
 I will give them a try on Thursday and Friday and keep you inform of
 the result.
 
 In your Guru's opinion, shall I try the svn version of 1.7 or could I
 stay with the PR release ?

I'd go with trunk; there are changes going in daily improving the
release, and we'll be doing at least one bug hunting event before the
release. (1.7 will be branched from trunk prior to the first RC)

-- 
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/

Re: [fw-general] Problems with Zend_Form_Element_File since ZF1.6.2

2008-10-21 Thread andersl


So that means if I get the trunk right now and remove the rename filter
everything should be just fine?



thomasW wrote:
 
 In trunk you don't have to add a empty rename filter.
 And file elements do not have a value until now due to security reasons.
 
 Greetings
 Thomas Weidner, I18N Team Leader, Zend Framework
 http://www.thomasweidner.com
 
 - Original Message - 
 From: andersl [EMAIL PROTECTED]
 To: fw-general@lists.zend.com
 Sent: Tuesday, October 21, 2008 9:18 PM
 Subject: Re: [fw-general] Problems with Zend_Form_Element_File since
 ZF1.6.2
 
 

 Hi

 I got the trunk from yesterday and even though I add the rename filter I
 still dont get any value from the getValue. The file gets uploaded but
 the
 getValue just dont return anything. I use addElements to get the element 
 on
 the screen. Could this be the issue? My code looks something like this:
 ...
 $this-setAttrib('enctype', 'multipart/form-data');
 ...
//picture
$picture = new Zend_Form_Element_File('picture');
 $picture-setLabel('Picture')
 -setRequired(true)
-setDestination('/var/www/images')
-addValidator('Count', false, 1) // ensure only 1 file
-addValidator('Size', false, 1MB)
-addValidator('Extension', false, 'jpg,png,gif,jpeg')
-addFilter('Rename', array('/var/www/images', true))
; // only JPEG, PNG, and GIFs
 ...
 $submit = new Zend_Form_Element_Submit('submit');
 $submit-setAttrib('id', 'submitbutton');
 $this-addElements(array($id, $name, $picture, $submit))

 and in my controller I have:

 if (!$form-picture-receive())
 {
 print Error receiving the file;
 }

 //$row-picture = $form-picture-getValue();
 //$row-picture = $form-getValue('picture');

 both getValue gives me nothing :(

 Im looking forward to your reply :)

 Anders

 thomasW wrote:

 As reply to an mail this has been sent on 15.Oct:
 -
 Yes, this issue was added 7 hours ago and have already been fixed in 
 trunk
 and branch.
 To solve this shortly you can:

 * Do not use addElement on the file element... the reason is that
 getValue()
 will be called on the file elements but they have no value and behave
 false
 in such a condition
 or
 * Add a empty rename filter by setting source and target the same value
 --

 Greetings
 Thomas Weidner, I18N Team Leader, Zend Framework
 http://www.thomasweidner.com

 - Original Message - 
 From: drj201 [EMAIL PROTECTED]
 To: fw-general@lists.zend.com
 Sent: Monday, October 20, 2008 1:21 PM
 Subject: [fw-general] Problems with Zend_Form_Element_File since ZF1.6.2



 I am trying to add a Zend_Form_Element File to a form... I am extending
 Zend_Form with my own class for reuse purposes. The problem is that 
 since
 upgrading to ZF 1.6.2 my code no longer works.

 Build element:

 $this-addElement('file', 'logo', array(
'label' = 'Logo',
 ...etc
));

 Add to form using group decorator:

 $this-addDisplayGroup(
array('logo'), 'logodata',
array(
'legend' = 'Dealer Logo'
)
);

 This results in the following error:

 Warning: Exception caught by form: Unknown file Stack Trace: #0
 demoapp/lib/Zend/Form/Element/File.php(357):
 Zend_File_Transfer_Adapter_Abstract-getFilters('logo') #1
 demoapp/lib/Zend/Form/Element.php(524):
 Zend_Form_Element_File-getFilters()
 #2 demoapp/lib/Zend/Form/Element.php(541):
 Zend_Form_Element-_filterValue(NULL, NULL) #3
 demoapp/lib/Zend/Form/Decorator/ViewHelper.php(201):
 Zend_Form_Element-getValue() #4
 demoapp/lib/Zend/Form/Decorator/ViewHelper.php(231):
 Zend_Form_Decorator_ViewHelper-getValue(Object(Zend_Form_Element_File))
 #5
 demoapp/lib/Zend/Form/Element.php(1905):
 Zend_Form_Decorator_ViewHelper-render('') #6
 demoapp/lib/Zend/Form/Decorator/FormElements.php(100):
 Zend_Form_Element-render() #7 demoapp/lib/Zend/Form.php(2596):
 Zend_Form_Decorator_FormElements-render('') #8 /Applicat in
 demoapp/lib/Zend/Form.php on line 2616


 Using the following manual approach works fine:

 $element = new Zend_Form_Element_File('foo');
 $element-setLabel('Upload an image:')
 ...etc

 Any reason this has happened since upgrading to 1.6.2?

 Thanks,
 David
 -- 
 View this message in context:
 http://www.nabble.com/Problems-with-Zend_Form_Element_File-since-ZF1.6.2-tp20067249p20067249.html
 Sent from the Zend Framework mailing list archive at Nabble.com.




 -- 
 View this message in context: 
 http://www.nabble.com/Problems-with-Zend_Form_Element_File-since-ZF1.6.2-tp20067249p20097147.html
 Sent from the Zend Framework mailing list archive at Nabble.com. 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Problems-with-Zend_Form_Element_File-since-ZF1.6.2-tp20067249p20098330.html
Sent from the Zend Framework mailing list archive at Nabble.com.

[fw-general] Zend Form: Dynamic/Chained select boxes

2008-10-21 Thread gigantorTRON


I've searched through the forums here and was surprised that I couldn't find
much information about creating dynamic select boxes within zend form. 

What I need is a basic country-populate states setup, where a text field is
provided (or enabled) if any country other than US or Canada is selected.

What's the best approach to this?

Thanks.
-- 
View this message in context: 
http://www.nabble.com/Zend-Form%3A-Dynamic-Chained-select-boxes-tp20099459p20099459.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Zend_Search_Lucene - how to find performance problem source?