Re: [fw-general] Zend_Search_Lucene... and CLA too.
Hi,
For the first question:
Yes. You can use 'boost' document property as well as 'boost' field
property:
--
$doc = new Zend_Search_Lucene_Document();
$doc->boost = 0.7;
...
$field = Zend_Search_Lucene_Field::Text('contents', $text);
$field->boost = 0.6;
$doc->addField($field);
---
It gives 0.42 (0.7*0.6) resulting boost factor for 'contents' field.
Boost factors are not stored directly in the index. So they can't be
retrieved from $hit->getDocument() object. But they are used for score
calculation.
With best regards,
Alexander Veremyev.
codeangel wrote:
I have two questions.
Does Zend_Search_Lucene support document/field boosting? I'd like to see
support for that if it doesn't.
Probably more importantly, I signed a CLA a while ago, and I have moved,
changed jobs, changed email addresses since then, and I can't remember my
username pass to the developer stuff, anyway I can retrieve this info? I'd like
to get more involved with the framework, especially in documentation.
Chad
Re: [fw-general] Zend_Search_Lucene - Large amount of data
Hi Sam,
I am preparing Zend_Search_Lucene Best Practice documentation section
right now and it'll include recommendations for different indexing modes
(see below) :)
Hope it'll help.
To get quick result:
1. Don't limit batch indexing execution time.
2. Choose MaxBufferedDocs according to your memory limit (set it to 128
and decrease it twice each time you get 'out of memory' error).
3. Skip MergeFactor tuning
4. Set MaxMergedDocs to floor(NumberOfDocuments/64)
-- Indexing performance -
Indexing performance is a compromise between used resources, indexing
time and index quality.
Index quality is completely determined by number of index segments.
Each index segment is entirely independent portion of data. So index
containing more segments needs more memory and more time for searching.
Index optimization is a process of merging several segments into new
one. Fully optimized index contains only one segment.
Full index optimization may be performed with 'optimize()' method:
$index = Zend_Search_Lucene::open($indexPath);
$index->optimize();
Index optimization works with data streams and doesn't take a lot of
memory, but takes processor resources and time.
Lucene index segments are not updatable by their nature (update
operation needs segment file to be completely rewritten). So adding new
document(s) to the index always generates new segment. It decreases
index quality.
Index auto-optimization process is performed after each segment
generation and consists in partial segments merging.
There are three options to control behavior of auto-optimization:
1. MaxBufferedDocs is a number of documents buffered in memory before
new segment is generated and written to a hard drive.
2. MaxMergeDocs is a maximum number of documents merged by
auto-optimization process into new segment.
3. MergeFactor determines how often auto-optimization is performed.
* All these options are Zend_Search_Lucene object properties, but not
index properties. So they affect only current Zend_Search_Lucene object
behavior and may vary for different scripts.
MaxBufferedDocs doesn't matter if you index only one document per script
execution. To the contrary, it's very important for batch indexing.
Greater value increases indexing performance, but also needs more memory.
There are no way to calculate best value for MaxBufferedDocs parameter
because it depends on documents size, used analyzer and allowed memory.
Good way to get right value is to perform several tests with largest
document you expect to be added to the index ('memory_get_usage()' and
'memory_get_peak_usage()' may be used to control memory usage). That's
good idea not to use more than a half of allowed memory.
MaxMergeDocs limits segment size (in terms of documents). So it limits
auto-optimization time. That guarantees addDocument() method to be not
executed more than a certain time. It's important for interactive
application.
Decreasing MaxMergeDocs parameter also may improve batch indexing
performance. Index auto-optimization is iterative process and is
performed step by step. Small segments are merged into larger, at some
moment they are merged into even greater and so on. Full index
optimization is much more effective.
On the over hand, smaller segments decreases index quality and may
generate too many segments. It may be a cause of the 'Too many open
files' error determined by OS limitations (Zend_Search_Lucene keeps each
segment file opened to improve search performance).
So background index optimization should be performed for interactive
indexing mode and MaxMergeDocs shouldn't be too low for batch indexing.
MergeFactor affects auto-optimization frequency. Less values increases
quality of unoptimized index. Larger values increases indexing
performance, but also increases number of segments. It again may be a
cause of the 'Too many open files' error.
MergeFactor groups index segments by their size:
1. Not greater than MaxBufferedDocs.
2. Greater than MaxBufferedDocs, but not greater than
MaxBufferedDocs*MergeFactor.
3. Greater than MaxBufferedDocs*MergeFactor, but not greater than
MaxBufferedDocs*MergeFactor*MergeFactor.
...
Zend_Search_Lucene checks at each addDocument() call if merging of any
segments group may move newly created segment into next group. If yes,
then merging is performed.
So index with N groups may contain MaxBufferedDocs + (N-1)*MergeFactor
segments and contains at least MaxBufferedDocs*MergeFactor^(N-1) documents.
It gives good approximation for number of segments in the index:
NumberOfSegments <= MaxBufferedDocs +
MergeFactor*ln(NumberOfDocuments/MaxBufferedDocs)/ln(MergeFactor)
MaxBufferedDocs is determined by allowed memory. It gives the
possibility to choose appropriate merge factor to get reasonable number
of segments.
Tuning MergeFactor parameter is more effective for batch indexing
performance than MaxMergeDocs. But it's more r
[fw-general] Routing issues
We're seeing issues with RC3 (RC2 and RC1 work as expected): http://example.com/controller/action routes to indexController -> indexAction http://example.com/index.php/controller/action routes properly to controllerController -> actionAction What has changed in RC3 that could cause this? Tried stripping our bootstrap file to the bare minimum, still having issues. [ .htaccess ] RewriteEngine on RewriteRule !\.(js|ico|GIF|JPG|gif|jpg|png|css|swf)$ index.php I notice at least two others have posted similiar issues here. Anyone able to fix it?
[fw-general] Zend_Search_Lucene... and CLA too.
I have two questions. Does Zend_Search_Lucene support document/field boosting? I'd like to see support for that if it doesn't. Probably more importantly, I signed a CLA a while ago, and I have moved, changed jobs, changed email addresses since then, and I can't remember my username pass to the developer stuff, anyway I can retrieve this info? I'd like to get more involved with the framework, especially in documentation. Chad
Re: [fw-general] Re: Zend_Validate_Alnum and Zend_Validate_Alpha failing(ZF1.0RC3)
On Wednesday 27 June 2007 18:38:07 Darby Felton wrote: > Hi Josh, > > It's already filed as: > > http://framework.zend.com/issues/browse/ZF-1641 > > We can post further comments and results there for further investigation. > > Best regards, > Darby Hiya, I can't post to JIRA at the moment so this will have to do in the meantime. From testing on my platforms ( openSUSE/SUSE-OSS 10.0, 10.1, 10.2 ), I have the following results: Up to ( but not including ) apache2-mod_php5-5.2.0-10.rpm testing against the PCRE expression in current Zend_Filter_Alnum passes. From mod_php5 version that ships with openSUSE 10.2 ( 5.2.0-10 ) to the current available in the openSUSE build service, ( 5.2.3-29.1 ), testing against the pattern fails. On openSUSE mod_php5-5.2.0-10 and greater is built against the system PCRE library and not the PHP bundled one, on opensuse 10.2 this is pcre-6.7-21. While patterns with UTF-8 options match against this system library outside of PHP; they do not, for whatever reason match when used inside of PHP. Workaround, on openSUSE 10.2 an upgrade of the system PCRE to the latest available from the openSUSE build service ( pcre-7.1-16 ) will allow pattern matching inside of PHP to function as expected. Cheers Graham
[fw-general] Fisheye upgraded
Hi, I have upgraded the instance of Fisheye we run: http://framework.zend.com/fisheye/ I'm still working on upgrading Jira and Confluence. Regards, Bill Karwin
[fw-general] Router doesn't route
For some reason the router doesn't work on my webhost. On my test server it
works like a charm. I had this problem before with a different website on
the same webhost, and I solved it by loading Zend_Controller_Request_Http
myself, add the baseUrl, and put it in the front controller. But, with this
site the dynamic stuff was in directory dynamic:
$request->addBaseUrl('/dynamic');
This time, the site is in the base url:
$request->addBaseUrl('/');
This makes no sense to do as the slash is stripped. When I go to page
/assdasdsa in my webbrowser I still get /index/index, no exception is
thrown.
I'm probably searching in the wrong direction.
--
View this message in context:
http://www.nabble.com/Router-doesn%27t-route-tf3991003s16154.html#a11332967
Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Small Bug in Xend_Layout
Hi Ralph,
I've been fiddling around with your layout class for the last days and
always asked myself why I had to set the response segment name myself
when using the addRequest method. A little digging into the sources
today gave the answer :-)
In LayoutProcessor.php line 161 the code reads
$this->_layoutManager->setResponseSegmentName($current_request_name);
this should be
$this->_layoutManager->setResponseSegmentName($current_request->getName());
and everything works just fine.
Thanks a lot for your great work on this!
Oh, and for everyone asking what I'm talking about or wanting a small
example, here's what I do to use layout with subparts (say additional
rendered actions):
bootstrap.php
// Do this directly before calling dispatch()
Xend_Layout::setup(array('path' => PATH_APPLICATION . 'common' .
DIRECTORY_SEPARATOR . 'views' . DIRECTORY_SEPARATOR));
Xend_Layout::setDefaultLayoutName('base');
ControllerClass where the subpart is needed (best would be to do this
via an extended action controller)
=
$this->getHelper('LayoutManager')->getLayout('base')->addRequest(new
Xend_Layout_Request('LoginBox', 'loginbox', 'auth'));
base.phtml (layout)
===
_('Skip to
main content'); ?>
LoginBox; ?>
content; ?>
That's it :-)
Thanks again and read you later,
Sascha
Re: [fw-general] Re: Zend_Validate_Alnum and Zend_Validate_Alpha failing(ZF1.0RC3)
Hi Josh,
It's already filed as:
http://framework.zend.com/issues/browse/ZF-1641
We can post further comments and results there for further investigation.
Best regards,
Darby
Joshua Ross wrote:
> I can file the bug report.
> I'll take a look at the link you posted here and report back as well,
> thanks!!
> Josh
>
>
> "Darby Felton" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Hi Josh,
>>
>> Maybe this helps you get UTF-8 support on your system?
>>
>> http://drupal.org/node/40961
>>
>> We should likely put detection of such support into the class in order
>> to prevent such problems from happening in the future. Would you mind
>> filing a bug report, or shall I do it for us?
>>
>> Best regards,
>> Darby
>>
>> Joshua Ross wrote:
>>> I posted this once in response to another post and then in my
>>> investigation
>>> I found that these validators have changed in 1.0RC3 somewhat
>>> dramatically.We are having problems using Zend_Validate_Alpha and
>>> Zend_Validate_Alnum but only on our production RHEL5 server. Using xampp
>>> locally on windows XP the same code works perfectly. Prior to 1.0RC3
>>> this
>>> worked on production as well. We are running ZF 1.0RC3. Here is the
>>> test
>>> code(similar to original post):
>>>
>>> $validator = new Zend_Validate_Alnum();
>>>
>>> $vars = array('Alnum' => 'foobar1',
>>> 'notAlnum' => '[EMAIL PROTECTED]');
>>> foreach ($vars as $var) {
>>> echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
>>> }
>>>
>>> RHEL5 response:
>>> foobar1:false
>>> [EMAIL PROTECTED]:false
>>>
>>> WindowsXP response:
>>> foobar1:true
>>> [EMAIL PROTECTED]:false
>>>
>>> Looking at the code both validators now leverage the filters instead of
>>> using ctype functions. The filters use perl reg exp but even those have
>>> changed.
>>> For example, Zend_Validate_Alnum was:
>>> /[^[:alnum:]]/
>>>
>>> and now it is:
>>> /[^\p{L}\p{N}]/u
>>>
>>> minus the whitespace logic. I assume the whitespace logic is why this
>>> was
>>> changed. Testing the new expression using pcretest I am receiving false
>>> for
>>> valid strings.
>>>
>>> RHEL5 & Windows XP
>>> **
pcretest
>>> PCRE version 6.6 06-Feb-2006
>>>
>>> re> /[^\p{L}\p{N}]/u
>>> ** Unknown option 'u'
>>> re> /[^\p{L}\p{N}]/
>>> data> foobar1
>>> 0: f
>>> data> foobar
>>> 0: f
>>> data> [EMAIL PROTECTED]
>>> 0: f
>>>
>>> I am quite confused! Is the regular expression incorrect? It appears
>>> correct based on my investigation but it is obviously not working. This
>>> failed on both windowsXP and the RHEL5 server, both of which are running
>>> pcretest 6.6. It did, however, work in my test php script on Windows XP.
>>> The one difference here is that my PHP install on my Windows XP box has
>>> PCRE
>>> 6.7. Is this reg exp only available in PCRE 6.7?
>>>
>>> I don't have a windows XP 6.7 pcretest at the moment, going to look to
>>> see
>>> if cygwin has it ready for download. Once I test it I will post the
>>> results. Below are some server details:
>>>
>>>
>>> RHEL 5 System details:
>>> **
>>> PHP 5.1.6 (cli) (built: Apr 4 2007 11:38:24)
>>> Copyright (c) 1997-2006 The PHP Group
>>> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>>> with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
>>> Technologies
>>> with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
>>> Technologies
>>>
>>> yum info:
>>> ***
>>> PCRE
>>> ---
>>> pcre.x86_64 6.6-1.1installed
>>>
>>> PHP
>>> ---
>>> php.x86_64 5.1.6-11.el5 installed
>>> php-bcmath.x86_645.1.6-11.el5 installed
>>> php-cli.x86_64 5.1.6-11.el5 installed
>>> php-common.x86_645.1.6-11.el5 installed
>>> php-dba.x86_64 5.1.6-11.el5 installed
>>> php-devel.x86_64 5.1.6-11.el5 installed
>>> php-gd.x86_645.1.6-11.el5 installed
>>> php-imap.x86_64 5.1.6-11.el5 installed
>>> php-ldap.x86_64 5.1.6-11.el5 installed
>>> php-mbstring.x86_64 5.1.6-11.el5 installed
>>> php-mysql.x86_64 5.1.6-11.el5 installed
>>> php-ncurses.x86_64 5.1.6-11.el5 installed
>>> php-odbc.x86_64 5.1.6-11.el5 installed
>>> php-pdo.x86_64 5.1.6-11.el5 installed
>>> php-pear.noarch 1:1.4.9-4 installed
>>> php-pgsql.x86_64 5.1.6-11.el5 installed
[fw-general] Re: Zend_Validate_Alnum and Zend_Validate_Alpha failing(ZF1.0RC3)
I can file the bug report.
I'll take a look at the link you posted here and report back as well,
thanks!!
Josh
"Darby Felton" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Josh,
>
> Maybe this helps you get UTF-8 support on your system?
>
> http://drupal.org/node/40961
>
> We should likely put detection of such support into the class in order
> to prevent such problems from happening in the future. Would you mind
> filing a bug report, or shall I do it for us?
>
> Best regards,
> Darby
>
> Joshua Ross wrote:
>> I posted this once in response to another post and then in my
>> investigation
>> I found that these validators have changed in 1.0RC3 somewhat
>> dramatically.We are having problems using Zend_Validate_Alpha and
>> Zend_Validate_Alnum but only on our production RHEL5 server. Using xampp
>> locally on windows XP the same code works perfectly. Prior to 1.0RC3
>> this
>> worked on production as well. We are running ZF 1.0RC3. Here is the
>> test
>> code(similar to original post):
>>
>> $validator = new Zend_Validate_Alnum();
>>
>> $vars = array('Alnum' => 'foobar1',
>> 'notAlnum' => '[EMAIL PROTECTED]');
>> foreach ($vars as $var) {
>> echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
>> }
>>
>> RHEL5 response:
>> foobar1:false
>> [EMAIL PROTECTED]:false
>>
>> WindowsXP response:
>> foobar1:true
>> [EMAIL PROTECTED]:false
>>
>> Looking at the code both validators now leverage the filters instead of
>> using ctype functions. The filters use perl reg exp but even those have
>> changed.
>> For example, Zend_Validate_Alnum was:
>> /[^[:alnum:]]/
>>
>> and now it is:
>> /[^\p{L}\p{N}]/u
>>
>> minus the whitespace logic. I assume the whitespace logic is why this
>> was
>> changed. Testing the new expression using pcretest I am receiving false
>> for
>> valid strings.
>>
>> RHEL5 & Windows XP
>> **
>>> pcretest
>> PCRE version 6.6 06-Feb-2006
>>
>> re> /[^\p{L}\p{N}]/u
>> ** Unknown option 'u'
>> re> /[^\p{L}\p{N}]/
>> data> foobar1
>> 0: f
>> data> foobar
>> 0: f
>> data> [EMAIL PROTECTED]
>> 0: f
>>
>> I am quite confused! Is the regular expression incorrect? It appears
>> correct based on my investigation but it is obviously not working. This
>> failed on both windowsXP and the RHEL5 server, both of which are running
>> pcretest 6.6. It did, however, work in my test php script on Windows XP.
>> The one difference here is that my PHP install on my Windows XP box has
>> PCRE
>> 6.7. Is this reg exp only available in PCRE 6.7?
>>
>> I don't have a windows XP 6.7 pcretest at the moment, going to look to
>> see
>> if cygwin has it ready for download. Once I test it I will post the
>> results. Below are some server details:
>>
>>
>> RHEL 5 System details:
>> **
>> PHP 5.1.6 (cli) (built: Apr 4 2007 11:38:24)
>> Copyright (c) 1997-2006 The PHP Group
>> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>> with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
>> Technologies
>> with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
>> Technologies
>>
>> yum info:
>> ***
>> PCRE
>> ---
>> pcre.x86_64 6.6-1.1installed
>>
>> PHP
>> ---
>> php.x86_64 5.1.6-11.el5 installed
>> php-bcmath.x86_645.1.6-11.el5 installed
>> php-cli.x86_64 5.1.6-11.el5 installed
>> php-common.x86_645.1.6-11.el5 installed
>> php-dba.x86_64 5.1.6-11.el5 installed
>> php-devel.x86_64 5.1.6-11.el5 installed
>> php-gd.x86_645.1.6-11.el5 installed
>> php-imap.x86_64 5.1.6-11.el5 installed
>> php-ldap.x86_64 5.1.6-11.el5 installed
>> php-mbstring.x86_64 5.1.6-11.el5 installed
>> php-mysql.x86_64 5.1.6-11.el5 installed
>> php-ncurses.x86_64 5.1.6-11.el5 installed
>> php-odbc.x86_64 5.1.6-11.el5 installed
>> php-pdo.x86_64 5.1.6-11.el5 installed
>> php-pear.noarch 1:1.4.9-4 installed
>> php-pgsql.x86_64 5.1.6-11.el5 installed
>> php-snmp.x86_64 5.1.6-11.el5 installed
>> php-soap.x86_64 5.1.6-11.el5 installed
>> php-xml.x86_64 5.1.6-11.el5 installed
>> php-xmlrpc.x86_645.1.6-11.el5 installed
>>
>>
>>
>> WindowsXP Sy
[fw-general] Re: Zend_Validate_Alnum and Zend_Validate_Alpha failing(ZF1.0RC3)
Darby Felton <[EMAIL PROTECTED]> writes:
>
> Hi Josh,
>
> The reason that it is failing for you appears to be that your PCRE does
> not have UTF-8 support compiled in. This is likely the result of the
> particular distribution not having used the --enable-utf8 option.
>
> What this means to us is that the class should become aware of whether
> such support is available, and act accordingly.
>
> I'll go ahead and file a JIRA issue for this so that users of
> distributions that do not have PCRE UTF-8 support may still use the
> affected classes (though of course without UTF-8 support :) ).
>
> Best regards,
> Darby
>
My newslist reader must be slow, I'm responding but it only posts about 30
minutes later. I am not sure the UTF-8 issue is the problem here. I just ran
this simple test script and received no error:
ini_set('display_errors', 'On');
error_reporting(E_ALL);
preg_match('/[^[\p{L}\p{N}]]/u', 'testing123', $matches);
var_dump($matches);
My assumption based on the link you posted is that an unsupported option such as
/u would have given me a php warning message. I am looking for a way to
determine what options were used for the PCRE distribution... it is a RHEL5
package so I should be able to find it.
Josh
Re: [fw-general] Re: Zend_Validate_Alnum and Zend_Validate_Alpha failing(ZF1.0RC3)
Hi Josh,
The reason that it is failing for you appears to be that your PCRE does
not have UTF-8 support compiled in. This is likely the result of the
particular distribution not having used the --enable-utf8 option.
What this means to us is that the class should become aware of whether
such support is available, and act accordingly.
I'll go ahead and file a JIRA issue for this so that users of
distributions that do not have PCRE UTF-8 support may still use the
affected classes (though of course without UTF-8 support :) ).
Best regards,
Darby
Joshua Ross wrote:
> Ok, so I mistook the responses from pcretest and it was returning true. So
> ignoring that I am still unsure why this is failing.
>
>
> "Joshua Ross" <[EMAIL PROTECTED]> wrote in
> message news:[EMAIL PROTECTED]
>> I posted this once in response to another post and then in my investigation
>> I found that these validators have changed in 1.0RC3 somewhat
>> dramatically.We are having problems using Zend_Validate_Alpha and
>> Zend_Validate_Alnum but only on our production RHEL5 server. Using xampp
>> locally on windows XP the same code works perfectly. Prior to 1.0RC3 this
>> worked on production as well. We are running ZF 1.0RC3. Here is the test
>> code(similar to original post):
>>
>> $validator = new Zend_Validate_Alnum();
>>
>> $vars = array('Alnum' => 'foobar1',
>> 'notAlnum' => '[EMAIL PROTECTED]');
>> foreach ($vars as $var) {
>>echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
>> }
>>
>> RHEL5 response:
>> foobar1:false
>> [EMAIL PROTECTED]:false
>>
>> WindowsXP response:
>> foobar1:true
>> [EMAIL PROTECTED]:false
>>
>> Looking at the code both validators now leverage the filters instead of
>> using ctype functions. The filters use perl reg exp but even those have
>> changed.
>> For example, Zend_Validate_Alnum was:
>> /[^[:alnum:]]/
>>
>> and now it is:
>> /[^\p{L}\p{N}]/u
>>
>> minus the whitespace logic. I assume the whitespace logic is why this was
>> changed. Testing the new expression using pcretest I am receiving false
>> for valid strings.
>>
>> RHEL5 & Windows XP
>> **
>>> pcretest
>> PCRE version 6.6 06-Feb-2006
>>
>> re> /[^\p{L}\p{N}]/u
>> ** Unknown option 'u'
>> re> /[^\p{L}\p{N}]/
>> data> foobar1
>> 0: f
>> data> foobar
>> 0: f
>> data> [EMAIL PROTECTED]
>> 0: f
>>
>> I am quite confused! Is the regular expression incorrect? It appears
>> correct based on my investigation but it is obviously not working. This
>> failed on both windowsXP and the RHEL5 server, both of which are running
>> pcretest 6.6. It did, however, work in my test php script on Windows XP.
>> The one difference here is that my PHP install on my Windows XP box has
>> PCRE 6.7. Is this reg exp only available in PCRE 6.7?
>>
>> I don't have a windows XP 6.7 pcretest at the moment, going to look to see
>> if cygwin has it ready for download. Once I test it I will post the
>> results. Below are some server details:
>>
>>
>> RHEL 5 System details:
>> **
>> PHP 5.1.6 (cli) (built: Apr 4 2007 11:38:24)
>> Copyright (c) 1997-2006 The PHP Group
>> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>>with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
>> Technologies
>>with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
>> Technologies
>>
>> yum info:
>> ***
>> PCRE
>> ---
>> pcre.x86_64 6.6-1.1installed
>>
>> PHP
>> ---
>> php.x86_64 5.1.6-11.el5 installed
>> php-bcmath.x86_645.1.6-11.el5 installed
>> php-cli.x86_64 5.1.6-11.el5 installed
>> php-common.x86_645.1.6-11.el5 installed
>> php-dba.x86_64 5.1.6-11.el5 installed
>> php-devel.x86_64 5.1.6-11.el5 installed
>> php-gd.x86_645.1.6-11.el5 installed
>> php-imap.x86_64 5.1.6-11.el5 installed
>> php-ldap.x86_64 5.1.6-11.el5 installed
>> php-mbstring.x86_64 5.1.6-11.el5 installed
>> php-mysql.x86_64 5.1.6-11.el5 installed
>> php-ncurses.x86_64 5.1.6-11.el5 installed
>> php-odbc.x86_64 5.1.6-11.el5 installed
>> php-pdo.x86_64 5.1.6-11.el5 installed
>> php-pear.noarch 1:1.4.9-4 installed
>> php-pgsql.x86_64 5.1.6-11.el5 installed
>> php-snmp.x86_64 5.1.6-11.el5 installed
>> php-soap.x86_64
[fw-general] Re: Zend_Validate_Alnum and Zend_Validate_Alpha failing(ZF1.0RC3)
Ok, so I mistook the responses from pcretest and it was returning true. So
ignoring that I am still unsure why this is failing.
"Joshua Ross" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>I posted this once in response to another post and then in my investigation
>I found that these validators have changed in 1.0RC3 somewhat
>dramatically.We are having problems using Zend_Validate_Alpha and
>Zend_Validate_Alnum but only on our production RHEL5 server. Using xampp
> locally on windows XP the same code works perfectly. Prior to 1.0RC3 this
> worked on production as well. We are running ZF 1.0RC3. Here is the test
> code(similar to original post):
>
> $validator = new Zend_Validate_Alnum();
>
> $vars = array('Alnum' => 'foobar1',
> 'notAlnum' => '[EMAIL PROTECTED]');
> foreach ($vars as $var) {
>echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
> }
>
> RHEL5 response:
> foobar1:false
> [EMAIL PROTECTED]:false
>
> WindowsXP response:
> foobar1:true
> [EMAIL PROTECTED]:false
>
> Looking at the code both validators now leverage the filters instead of
> using ctype functions. The filters use perl reg exp but even those have
> changed.
> For example, Zend_Validate_Alnum was:
> /[^[:alnum:]]/
>
> and now it is:
> /[^\p{L}\p{N}]/u
>
> minus the whitespace logic. I assume the whitespace logic is why this was
> changed. Testing the new expression using pcretest I am receiving false
> for valid strings.
>
> RHEL5 & Windows XP
> **
>> pcretest
> PCRE version 6.6 06-Feb-2006
>
> re> /[^\p{L}\p{N}]/u
> ** Unknown option 'u'
> re> /[^\p{L}\p{N}]/
> data> foobar1
> 0: f
> data> foobar
> 0: f
> data> [EMAIL PROTECTED]
> 0: f
>
> I am quite confused! Is the regular expression incorrect? It appears
> correct based on my investigation but it is obviously not working. This
> failed on both windowsXP and the RHEL5 server, both of which are running
> pcretest 6.6. It did, however, work in my test php script on Windows XP.
> The one difference here is that my PHP install on my Windows XP box has
> PCRE 6.7. Is this reg exp only available in PCRE 6.7?
>
> I don't have a windows XP 6.7 pcretest at the moment, going to look to see
> if cygwin has it ready for download. Once I test it I will post the
> results. Below are some server details:
>
>
> RHEL 5 System details:
> **
> PHP 5.1.6 (cli) (built: Apr 4 2007 11:38:24)
> Copyright (c) 1997-2006 The PHP Group
> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
> Technologies
>with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
> Technologies
>
> yum info:
> ***
> PCRE
> ---
> pcre.x86_64 6.6-1.1installed
>
> PHP
> ---
> php.x86_64 5.1.6-11.el5 installed
> php-bcmath.x86_645.1.6-11.el5 installed
> php-cli.x86_64 5.1.6-11.el5 installed
> php-common.x86_645.1.6-11.el5 installed
> php-dba.x86_64 5.1.6-11.el5 installed
> php-devel.x86_64 5.1.6-11.el5 installed
> php-gd.x86_645.1.6-11.el5 installed
> php-imap.x86_64 5.1.6-11.el5 installed
> php-ldap.x86_64 5.1.6-11.el5 installed
> php-mbstring.x86_64 5.1.6-11.el5 installed
> php-mysql.x86_64 5.1.6-11.el5 installed
> php-ncurses.x86_64 5.1.6-11.el5 installed
> php-odbc.x86_64 5.1.6-11.el5 installed
> php-pdo.x86_64 5.1.6-11.el5 installed
> php-pear.noarch 1:1.4.9-4 installed
> php-pgsql.x86_64 5.1.6-11.el5 installed
> php-snmp.x86_64 5.1.6-11.el5 installed
> php-soap.x86_64 5.1.6-11.el5 installed
> php-xml.x86_64 5.1.6-11.el5 installed
> php-xmlrpc.x86_645.1.6-11.el5 installed
>
>
>
> WindowsXP System details:
> **
> PHP 5.2.1 (cli) (built: Feb 7 2007 23:11:26)
> Copyright (c) 1997-2007 The PHP Group
> Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
>with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend
> Technologies
>with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend
> Technologies
>
> PCRE:
> *
> PCRE Libr
Re: [fw-general] Zend_Validate_Alnum and Zend_Validate_Alpha failing(ZF1.0RC3)
Hi Josh,
Maybe this helps you get UTF-8 support on your system?
http://drupal.org/node/40961
We should likely put detection of such support into the class in order
to prevent such problems from happening in the future. Would you mind
filing a bug report, or shall I do it for us?
Best regards,
Darby
Joshua Ross wrote:
> I posted this once in response to another post and then in my investigation
> I found that these validators have changed in 1.0RC3 somewhat
> dramatically.We are having problems using Zend_Validate_Alpha and
> Zend_Validate_Alnum but only on our production RHEL5 server. Using xampp
> locally on windows XP the same code works perfectly. Prior to 1.0RC3 this
> worked on production as well. We are running ZF 1.0RC3. Here is the test
> code(similar to original post):
>
> $validator = new Zend_Validate_Alnum();
>
> $vars = array('Alnum' => 'foobar1',
> 'notAlnum' => '[EMAIL PROTECTED]');
> foreach ($vars as $var) {
> echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
> }
>
> RHEL5 response:
> foobar1:false
> [EMAIL PROTECTED]:false
>
> WindowsXP response:
> foobar1:true
> [EMAIL PROTECTED]:false
>
> Looking at the code both validators now leverage the filters instead of
> using ctype functions. The filters use perl reg exp but even those have
> changed.
> For example, Zend_Validate_Alnum was:
> /[^[:alnum:]]/
>
> and now it is:
> /[^\p{L}\p{N}]/u
>
> minus the whitespace logic. I assume the whitespace logic is why this was
> changed. Testing the new expression using pcretest I am receiving false for
> valid strings.
>
> RHEL5 & Windows XP
> **
>> pcretest
> PCRE version 6.6 06-Feb-2006
>
> re> /[^\p{L}\p{N}]/u
> ** Unknown option 'u'
> re> /[^\p{L}\p{N}]/
> data> foobar1
> 0: f
> data> foobar
> 0: f
> data> [EMAIL PROTECTED]
> 0: f
>
> I am quite confused! Is the regular expression incorrect? It appears
> correct based on my investigation but it is obviously not working. This
> failed on both windowsXP and the RHEL5 server, both of which are running
> pcretest 6.6. It did, however, work in my test php script on Windows XP.
> The one difference here is that my PHP install on my Windows XP box has PCRE
> 6.7. Is this reg exp only available in PCRE 6.7?
>
> I don't have a windows XP 6.7 pcretest at the moment, going to look to see
> if cygwin has it ready for download. Once I test it I will post the
> results. Below are some server details:
>
>
> RHEL 5 System details:
> **
> PHP 5.1.6 (cli) (built: Apr 4 2007 11:38:24)
> Copyright (c) 1997-2006 The PHP Group
> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
> with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
> Technologies
> with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
> Technologies
>
> yum info:
> ***
> PCRE
> ---
> pcre.x86_64 6.6-1.1installed
>
> PHP
> ---
> php.x86_64 5.1.6-11.el5 installed
> php-bcmath.x86_645.1.6-11.el5 installed
> php-cli.x86_64 5.1.6-11.el5 installed
> php-common.x86_645.1.6-11.el5 installed
> php-dba.x86_64 5.1.6-11.el5 installed
> php-devel.x86_64 5.1.6-11.el5 installed
> php-gd.x86_645.1.6-11.el5 installed
> php-imap.x86_64 5.1.6-11.el5 installed
> php-ldap.x86_64 5.1.6-11.el5 installed
> php-mbstring.x86_64 5.1.6-11.el5 installed
> php-mysql.x86_64 5.1.6-11.el5 installed
> php-ncurses.x86_64 5.1.6-11.el5 installed
> php-odbc.x86_64 5.1.6-11.el5 installed
> php-pdo.x86_64 5.1.6-11.el5 installed
> php-pear.noarch 1:1.4.9-4 installed
> php-pgsql.x86_64 5.1.6-11.el5 installed
> php-snmp.x86_64 5.1.6-11.el5 installed
> php-soap.x86_64 5.1.6-11.el5 installed
> php-xml.x86_64 5.1.6-11.el5 installed
> php-xmlrpc.x86_645.1.6-11.el5 installed
>
>
>
> WindowsXP System details:
> **
> PHP 5.2.1 (cli) (built: Feb 7 2007 23:11:26)
> Copyright (c) 1997-2007 The PHP Group
> Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
> with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend
> Technologies
>
Re: [fw-general] Router, Controller Front, Dispatcher
-- agatone <[EMAIL PROTECTED]> wrote (on Wednesday, 27 June 2007, 08:54 AM -0700): > I'm sorry but I had to make this post, cuz I don't know what to read anymore > and i'm getting more and more lost. > > Problem: > Let's say I have application at http://exmpl.com/. > > Now this application has several modules: > http://exmpl.com/news/ > http://exmpl.com/blog/ > http://exmpl.com/gallery/ > etc. > > What I don't understand how passing params thru URL's work. As I seen it > says default it's something like this > > http://exmpl.com/gallery/id/12/user/15/ - (id = 12, user = 15) > http://exmpl.com/blog/cat/12/ > http://exmpl.com/blog/id/112/ No, that won't work. The default route is: [:module/]:controller/:action/* which means that if you want to pass params via the URL, you need to specify *each* of the module, controller, and action: http://exmpl.com/gallery/index/index/id/12/user/15 module cntrl actn A limitation of the '*' wildcard is that all the preceding elements must be present for it to match. Another option is to create a route like this: :module/* which would allow for the URLs you have above, but would preclude the idea of :controller/:action or :module/:controller or :module/:controller/:action as routes. You may want to rethink your URL schema slightly, and/or create custom routes for each module. -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Model Loading helper
Once again sorry for that question! The helper loads the model and I have to instatiate it... ;=) -- View this message in context: http://www.nabble.com/Model-Loading-helper-tf3942096s16154.html#a11328084 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Validate_Alnum and Zend_Validate_Alpha failing(ZF1.0RC3)
Hi Joshua,
My comments are inline below:
Joshua Ross wrote:
> I posted this once in response to another post and then in my investigation
> I found that these validators have changed in 1.0RC3 somewhat
> dramatically.We are having problems using Zend_Validate_Alpha and
> Zend_Validate_Alnum but only on our production RHEL5 server. Using xampp
> locally on windows XP the same code works perfectly. Prior to 1.0RC3 this
> worked on production as well. We are running ZF 1.0RC3. Here is the test
> code(similar to original post):
>
> $validator = new Zend_Validate_Alnum();
>
> $vars = array('Alnum' => 'foobar1',
> 'notAlnum' => '[EMAIL PROTECTED]');
> foreach ($vars as $var) {
> echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
> }
>
> RHEL5 response:
> foobar1:false
> [EMAIL PROTECTED]:false
>
> WindowsXP response:
> foobar1:true
> [EMAIL PROTECTED]:false
>
> Looking at the code both validators now leverage the filters instead of
> using ctype functions. The filters use perl reg exp but even those have
> changed.
> For example, Zend_Validate_Alnum was:
> /[^[:alnum:]]/
>
> and now it is:
> /[^\p{L}\p{N}]/u
>
> minus the whitespace logic. I assume the whitespace logic is why this was
> changed. Testing the new expression using pcretest I am receiving false for
> valid strings.
No, the regular expression was changed in order to support UTF-8
strings. Note the "u" modifier and the UTF-8 property checks ("L" for
letter, "N" for number).
>
> RHEL5 & Windows XP
> **
>> pcretest
> PCRE version 6.6 06-Feb-2006
>
> re> /[^\p{L}\p{N}]/u
> ** Unknown option 'u'
> re> /[^\p{L}\p{N}]/
> data> foobar1
> 0: f
> data> foobar
> 0: f
> data> [EMAIL PROTECTED]
> 0: f
Hmm, interesting. It appears that on this system the UTF-8 support is
not available.
> I am quite confused! Is the regular expression incorrect? It appears
> correct based on my investigation but it is obviously not working. This
> failed on both windowsXP and the RHEL5 server, both of which are running
> pcretest 6.6. It did, however, work in my test php script on Windows XP.
> The one difference here is that my PHP install on my Windows XP box has PCRE
> 6.7. Is this reg exp only available in PCRE 6.7?
No, I have been unable to reproduce the problem through unit testing on
the following platforms:
* PHP 5.1.4, WinXP, PCRE 6.6
* PHP 5.2.1, Ubuntu, PCRE 6.7
> I don't have a windows XP 6.7 pcretest at the moment, going to look to see
> if cygwin has it ready for download. Once I test it I will post the
> results. Below are some server details:
Thank you for posting these results. It appears that we need some more
investigation to find the root cause of the problem... calling all
volunteers!
Best regards,
Darby
>
>
> RHEL 5 System details:
> **
> PHP 5.1.6 (cli) (built: Apr 4 2007 11:38:24)
> Copyright (c) 1997-2006 The PHP Group
> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
> with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
> Technologies
> with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
> Technologies
>
> yum info:
> ***
> PCRE
> ---
> pcre.x86_64 6.6-1.1installed
>
> PHP
> ---
> php.x86_64 5.1.6-11.el5 installed
> php-bcmath.x86_645.1.6-11.el5 installed
> php-cli.x86_64 5.1.6-11.el5 installed
> php-common.x86_645.1.6-11.el5 installed
> php-dba.x86_64 5.1.6-11.el5 installed
> php-devel.x86_64 5.1.6-11.el5 installed
> php-gd.x86_645.1.6-11.el5 installed
> php-imap.x86_64 5.1.6-11.el5 installed
> php-ldap.x86_64 5.1.6-11.el5 installed
> php-mbstring.x86_64 5.1.6-11.el5 installed
> php-mysql.x86_64 5.1.6-11.el5 installed
> php-ncurses.x86_64 5.1.6-11.el5 installed
> php-odbc.x86_64 5.1.6-11.el5 installed
> php-pdo.x86_64 5.1.6-11.el5 installed
> php-pear.noarch 1:1.4.9-4 installed
> php-pgsql.x86_64 5.1.6-11.el5 installed
> php-snmp.x86_64 5.1.6-11.el5 installed
> php-soap.x86_64 5.1.6-11.el5 installed
> php-xml.x86_64 5.1.6-11.el5 installed
> php-xmlrpc.x86_645.1.6-11.el5 installed
>
>
>
> WindowsXP Sys
[fw-general] Zend_Validate_Alnum and Zend_Validate_Alpha failing(ZF1.0RC3)
I posted this once in response to another post and then in my investigation
I found that these validators have changed in 1.0RC3 somewhat
dramatically.We are having problems using Zend_Validate_Alpha and
Zend_Validate_Alnum but only on our production RHEL5 server. Using xampp
locally on windows XP the same code works perfectly. Prior to 1.0RC3 this
worked on production as well. We are running ZF 1.0RC3. Here is the test
code(similar to original post):
$validator = new Zend_Validate_Alnum();
$vars = array('Alnum' => 'foobar1',
'notAlnum' => '[EMAIL PROTECTED]');
foreach ($vars as $var) {
echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
}
RHEL5 response:
foobar1:false
[EMAIL PROTECTED]:false
WindowsXP response:
foobar1:true
[EMAIL PROTECTED]:false
Looking at the code both validators now leverage the filters instead of
using ctype functions. The filters use perl reg exp but even those have
changed.
For example, Zend_Validate_Alnum was:
/[^[:alnum:]]/
and now it is:
/[^\p{L}\p{N}]/u
minus the whitespace logic. I assume the whitespace logic is why this was
changed. Testing the new expression using pcretest I am receiving false for
valid strings.
RHEL5 & Windows XP
**
> pcretest
PCRE version 6.6 06-Feb-2006
re> /[^\p{L}\p{N}]/u
** Unknown option 'u'
re> /[^\p{L}\p{N}]/
data> foobar1
0: f
data> foobar
0: f
data> [EMAIL PROTECTED]
0: f
I am quite confused! Is the regular expression incorrect? It appears
correct based on my investigation but it is obviously not working. This
failed on both windowsXP and the RHEL5 server, both of which are running
pcretest 6.6. It did, however, work in my test php script on Windows XP.
The one difference here is that my PHP install on my Windows XP box has PCRE
6.7. Is this reg exp only available in PCRE 6.7?
I don't have a windows XP 6.7 pcretest at the moment, going to look to see
if cygwin has it ready for download. Once I test it I will post the
results. Below are some server details:
RHEL 5 System details:
**
PHP 5.1.6 (cli) (built: Apr 4 2007 11:38:24)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
Technologies
with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
Technologies
yum info:
***
PCRE
---
pcre.x86_64 6.6-1.1installed
PHP
---
php.x86_64 5.1.6-11.el5 installed
php-bcmath.x86_645.1.6-11.el5 installed
php-cli.x86_64 5.1.6-11.el5 installed
php-common.x86_645.1.6-11.el5 installed
php-dba.x86_64 5.1.6-11.el5 installed
php-devel.x86_64 5.1.6-11.el5 installed
php-gd.x86_645.1.6-11.el5 installed
php-imap.x86_64 5.1.6-11.el5 installed
php-ldap.x86_64 5.1.6-11.el5 installed
php-mbstring.x86_64 5.1.6-11.el5 installed
php-mysql.x86_64 5.1.6-11.el5 installed
php-ncurses.x86_64 5.1.6-11.el5 installed
php-odbc.x86_64 5.1.6-11.el5 installed
php-pdo.x86_64 5.1.6-11.el5 installed
php-pear.noarch 1:1.4.9-4 installed
php-pgsql.x86_64 5.1.6-11.el5 installed
php-snmp.x86_64 5.1.6-11.el5 installed
php-soap.x86_64 5.1.6-11.el5 installed
php-xml.x86_64 5.1.6-11.el5 installed
php-xmlrpc.x86_645.1.6-11.el5 installed
WindowsXP System details:
**
PHP 5.2.1 (cli) (built: Feb 7 2007 23:11:26)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend
Technologies
with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend
Technologies
PCRE:
*
PCRE Library Version => 6.7 04-Jul-2006
Josh
[fw-general] Router, Controller Front, Dispatcher
I'm sorry but I had to make this post, cuz I don't know what to read anymore and i'm getting more and more lost. Problem: Let's say I have application at http://exmpl.com/. Now this application has several modules: http://exmpl.com/news/ http://exmpl.com/blog/ http://exmpl.com/gallery/ etc. What I don't understand how passing params thru URL's work. As I seen it says default it's something like this http://exmpl.com/gallery/id/12/user/15/ - (id = 12, user = 15) http://exmpl.com/blog/cat/12/ http://exmpl.com/blog/id/112/ etc Problem is I don't want to write router for every possible path with all param posibilities. Isn't there any general soultuion whith should parse params in certain format by default? I've seen, by dumping REQUEST object, it already knows values of controller, action and module - all i'm missing is params. -- View this message in context: http://www.nabble.com/Router%2C-Controller-Front%2C-Dispatcher-tf3989103s16154.html#a11326855 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] RE: Model Loading helper
Seems like a lot of configuration that should be implicit with the
common-modular-directory-structure?
- Original Message -
From: "ArsePit" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, June 27, 2007 9:46 AM
Subject: [fw-general] RE: Model Loading helper
It sounds good to load modules as you need.
Right now for simplicity, I just created a section in config.ini for
modules
and then added some code to my bootstrap to take that information and
automatically set the controllers and models for each module.
Currently, I do the following:
--- In config.ini ---
;;; modules ;;;
; paths are relative to the 'application' directory
modules.default.controllers.directory = "controllers"
modules.default.models.directory = "models"
modules.event.controllers.directory = "modules/event/controllers"
modules.event.models.directory = "modules/event/models"
--- In bootstrap ---
$router = $frontController->getRouter(); // returns a rewrite router by
default
$aControllers = array();
// building associative array from config for module controller paths and
adding models to the include path
foreach ($config->modules as $tmpName => $oConf) {
$aControllers[$tmpName] = $app_path . $oConf->controllers->directory;
set_include_path('.' . PATH_SEPARATOR . $app_path .
$oConf->models->directory . PATH_SEPARATOR . get_include_path());
}
$frontController->setControllerDirectory($aControllers);
$registry->set('controllers', $aControllers); // add it to the registry
--
View this message in context:
http://www.nabble.com/Model-Loading-helper-tf3942096s16154.html#a11326850
Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] RE: Model Loading helper
It sounds good to load modules as you need.
Right now for simplicity, I just created a section in config.ini for modules
and then added some code to my bootstrap to take that information and
automatically set the controllers and models for each module.
Currently, I do the following:
--- In config.ini ---
;;; modules ;;;
; paths are relative to the 'application' directory
modules.default.controllers.directory = "controllers"
modules.default.models.directory = "models"
modules.event.controllers.directory = "modules/event/controllers"
modules.event.models.directory = "modules/event/models"
--- In bootstrap ---
$router = $frontController->getRouter(); // returns a rewrite router by
default
$aControllers = array();
// building associative array from config for module controller paths and
adding models to the include path
foreach ($config->modules as $tmpName => $oConf) {
$aControllers[$tmpName] = $app_path . $oConf->controllers->directory;
set_include_path('.' . PATH_SEPARATOR . $app_path .
$oConf->models->directory . PATH_SEPARATOR . get_include_path());
}
$frontController->setControllerDirectory($aControllers);
$registry->set('controllers', $aControllers); // add it to the registry
--
View this message in context:
http://www.nabble.com/Model-Loading-helper-tf3942096s16154.html#a11326850
Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Re: Zend_Validate_Alnum::isValid evaluating alnum strings as false
We are also having problems using Zend_Validate_Alpha and
Zend_Validate_Alnum but only on our production RHEL5 server. Using xampp
locally on windows XP the same code works perfectly. Prior to 1.0RC3 this
worked on production as well. We are running ZF 1.0RC3. Here is the test
code(similar to original post):
$validator = new Zend_Validate_Alnum();
$vars = array('Alnum' => 'foobar1',
'notAlnum' => '[EMAIL PROTECTED]');
foreach ($vars as $var) {
echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
}
RHEL5 response:
foobar1:false
[EMAIL PROTECTED]:false
WindowsXP response:
foobar1:true
[EMAIL PROTECTED]:false
RHEL 5 System details:
**
PHP 5.1.6 (cli) (built: Apr 4 2007 11:38:24)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
Technologies
with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
Technologies
yum info:
***
PCRE
---
pcre.x86_64 6.6-1.1installed
PHP
---
php.x86_64 5.1.6-11.el5 installed
php-bcmath.x86_645.1.6-11.el5 installed
php-cli.x86_64 5.1.6-11.el5 installed
php-common.x86_645.1.6-11.el5 installed
php-dba.x86_64 5.1.6-11.el5 installed
php-devel.x86_64 5.1.6-11.el5 installed
php-gd.x86_645.1.6-11.el5 installed
php-imap.x86_64 5.1.6-11.el5 installed
php-ldap.x86_64 5.1.6-11.el5 installed
php-mbstring.x86_64 5.1.6-11.el5 installed
php-mysql.x86_64 5.1.6-11.el5 installed
php-ncurses.x86_64 5.1.6-11.el5 installed
php-odbc.x86_64 5.1.6-11.el5 installed
php-pdo.x86_64 5.1.6-11.el5 installed
php-pear.noarch 1:1.4.9-4 installed
php-pgsql.x86_64 5.1.6-11.el5 installed
php-snmp.x86_64 5.1.6-11.el5 installed
php-soap.x86_64 5.1.6-11.el5 installed
php-xml.x86_64 5.1.6-11.el5 installed
php-xmlrpc.x86_645.1.6-11.el5 installed
WindowsXP System details:
**
PHP 5.2.1 (cli) (built: Feb 7 2007 23:11:26)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend
Technologies
with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend
Technologies
PCRE:
*
PCRE Library Version => 6.7 04-Jul-2006
Josh
"Darby Felton" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Graham,
>
> I just added the potentially offending data to the unit tests for
> Zend_Validate_Alnum, but I have been unable to reproduce the problem on
> either of the two following platforms:
>
> * PHP 5.1.4, WinXP, PCRE 6.6
>
> * PHP 5.2.1, Ubuntu, PCRE 6.7
>
> Are you on FreeBSD by chance?
>
> Anyone else experiencing such a problem?
>
> On another note, I would highly recommend upgrading your PHP beyond
> 5.2.0, which introduced some problems that have since been addressed in
> later releases.
>
> Best regards,
> Darby
>
> Graham Anderson wrote:
>> I updated against trunk and now...
>>
>> require_once('Zend/Validate/Alnum.php');
>>
>> $validator = new Zend_Validate_Alnum();
>>
>> $vars = array ( 'Alnum' => 'foobar1',
>> 'NotAlnum' => '[EMAIL PROTECTED]' );
>>
>> foreach ( $vars as $var ) {
>> echo $validator->isValid($var) ? $var .':true ' : $var . ':false ';
>> }
>>
>> --
>> result: foobar1:false [EMAIL PROTECTED]:false
>> --
>>
>> php5 -v
>> PHP 5.2.0 with Suhosin-Patch 0.9.6.1 (cli) (built: May 8 2007 20:00:45)
>> Copyright (c) 1997-2006 The PHP Group
>> Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
>> with Suhosin v0.9.10, (C) Copyright 2006, by Hardened-PHP Project
>>
>
Re: [fw-general] Model Loading helper
Sorry bu how I get my model instance?
// $oKunde is not an instance of KundeModel
// because ModelLoader::load returns
end_Controller_Action_Helper_ModelLoader
$oKunde = $this->_helper->ModelLoader('KundeModel');
Thanks
Axel
--
View this message in context:
http://www.nabble.com/Model-Loading-helper-tf3942096s16154.html#a11325670
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Debug::dump and ErrorController
-- ArsePit <[EMAIL PROTECTED]> wrote
(on Tuesday, 26 June 2007, 02:59 PM -0700):
>
> Working on getting Zend_Debug::dump to output the request and exception from
> the ErrorController
>
> I get the following error twice for each call to Zend_Debug:dump()
> Notice: Trying to get property of non-object in
> /var/www/html/cms/application/controllers/ErrorController.php on line x
>
> In the ErrorController
>
> protected $_errors = null;
>
> public function errorAction()
> {
> $this->_helper->viewRenderer->setNoRender(); // do not auto-render!
> $this->_errors = $this->_getParam('error_handler');
> switch ($this->_errors->type) {
> case
> Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
> case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
> $this->_forward('not-found');
> return;
> case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_OTHER:
> $this->_forward('server-error');
> return;
> }
> }
> public function NotFoundAction()
> {
>
> $this->view->title = "404 Page not found";
> $this->getResponse()->setRawHeader('HTTP/1.1 404 Not Found');
> if (defined('APPLICATION_STATE') && APPLICATION_STATE ==
> 'development') {
> $this->view->content = "Error Request:\n";
> $this->view->content .=
> Zend_Debug::dump($this->_errors->request, 'Errors Request', false);
The error is in the line above. Controller classes are not persisted
by the dispatcher, so in forwarding, you create a new instance of the
class. You will need to grab the error_handler object again prior to
utilizing it, just as you did in the errorAction() method.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
[fw-general] Zend_Search_Lucene - Large amount of data
Hi, I am really impressed with the performance of Zend_Search_Lucene and am trying to shift my SQL based search to an index based search for the obvious advantages of relieving stress on my MySql server. However I have a problem in that there is a massive amount of data I need to index. And when I try to index it all the script either runs out of memory or exceeds the given execution time. Of course I can use ini_set to increase these values but I have already increased them to high values and I can still only index about half of my data. Does anyone know of a good strategy to minimise or control the required memory/time of a script indexing this amount of data? Cheers, Sam -- View this message in context: http://www.nabble.com/Zend_Search_Lucene---Large-amount-of-data-tf3987316s16154.html#a11321511 Sent from the Zend Framework mailing list archive at Nabble.com.
