Re: [fw-general] Comment on Zend_Validate
Troy L. Marker schrieb:
My suggestion is to change how the validation receives it values. For
instance, you have an array as follows:
$aData = ('username' = 'someone', 'password' = 'somepass');
You could pass this array to Zend_Validata as follows:
$valid = new Zend_Validate($aData);
Now each validator could be changed to accept another parameter indicating
which element of the array the validator would validate. For example:
$valid-addValidator(new Zend_Validate_StringLength(8, 20), true,
'username');
This would validate the 'username' array element.
Hi Troy,
I can't believe it - I actually needed a component like this, and
Zend_Validate somehow slipped completely under my radard. As a result, I
spent some time last week while I was on vacation to write a class
precisely like this from scratch.
This should teach me once and for all to check all the directories in
the latest checkout, including the incubator, whenever I'm searching for
components :-/
The approach I used was almost exactly like what you described in your
post - except for the parameter order. Thus, I second your request :-)
If noone else has the time to implement this, I'll gladly volunteer (I
already have the code anyway, I just have to adapt it to Zend_Validate,
which is very similar to my own approach).
The question remains though, how to do it in detail:
1. Use the array approach exclusively, single values can no longer be
checked
2. Allow both arrays and single values using the same isValid() method
3. Have separate methods for checking either arrays or single values
4. Have a specialized subclass, like Zend_ValidateForm or something,
that specifically handles arrays from web forms
Personally, I am in favour of door 2.
CU
Markus
[fw-general] Re: OFFI-SPAM [fw-formats] Re: [fw-general] Authentication in Mail Class
Though this should be part of Zend_Auth, and not Zend_Mail please see:
http://framework.zend.com/wiki/display/ZFDEV/Zend_Auth
Best,
Andriesss
Gavin Vess schreef:
Looking at the code below, and the C code I wrote for SASL
authentication in Postfix, I am not confident that sufficient code
would be shared to justify the complexity of creating a component to
export APIs to these different components, although I can imagine a
helper class might contain a small amount of common code, especially
if we created something vaguely like a fly-weight version of the
expect language. Regardless, my recent experience with
Zend_Session* classes went the opposite direction, by carefully
segmenting APIs and publishing them only for consumption by the
intended classes, without polluting APIs with irrelevant methods,
using superclasses with protected methods.
If PHP had more robust syntactical methods for isolating methods of a
class and exporting them only to selected classes, then the situation
would be different.
I trust Justin's working code is better than what we have now
(nothing), and I personally will need this functionality, so I am
hoping Justin will sign our CLA and contribute the code. There would
be plenty of opportunities to examine options and alternative ways of
using this code :)
Cheers,
Gavin
Nico Edtinger wrote:
Maybe we could create a seperate class for auth methods so we can use
them with POP3 and IMAP too.
nico
[01.02.2007 23:10] Gavin Vess wrote:
Moving discussion to fw-formats list ...
Hi Justin,
Would you like to sign our CLA and create an issue in our issue
tracker with this patch?
http://framework.zend.com/wiki/display/ZFPROP/Contributor+License+Agreement
http://framework.zend.com/issues/secure/Dashboard.jspa
Thanks!
Gavin
Justin Hendrickson wrote:
I wrote this a few weeks back and it seems to be working alright.
It only supports AUTH LOGIN and AUTH PLAIN though.
?php
require_once 'Zend/Mail/Transport/Smtp.php';
class My_Zend_Mail_Transport_Smtp_Auth extends
Zend_Mail_Transport_Smtp {
/[EMAIL PROTECTED]
* Authentication types
* @var string
*/
const LOGIN = 'LOGIN';
const PLAIN = 'PLAIN';
/[EMAIL PROTECTED]/
/**
* @param string $username
* @param string $password
* @param string $method
*/
protected function authenticate($username, $password, $method =
self::PLAIN) {
switch($method) {
case self::LOGIN:
$this-authenticateLogin($username, $password);
break;
case self::PLAIN:
$this-authenticatePlain($username, $password);
break;
}
}
/**
* @param string $username
* @param string $password
* @throws Zend_Mail_Transport_Exception
*/
protected function authenticateLogin($username, $password) {
$this-_send('AUTH LOGIN');
try {
$this-_expect(334);
} catch(Zend_Mail_Transport_Exception $e) {
if(substr($e-getMessage(), 0, 3) == 503) {
return;
}
throw $e;
}
$this-_send(base64_encode($username));
$this-_expect(334);
$this-_send(base64_encode($password));
$this-_expect(235);
}
/**
* @param string $username
* @param string $password
* @throws Zend_Mail_Transport_Exception
*/
protected function authenticatePlain($username, $password) {
$this-_send('AUTH PLAIN');
try {
$this-_expect(334);
} catch(Zend_Mail_Transport_Exception $e) {
if(substr($e-getMessage(), 0, 3) == 503) {
return;
}
throw $e;
}
$this-_send(base64_encode(chr(0) . $username . chr(0) .
$password));
$this-_expect(235);
}
}
On 1/31/07, *Sanjay Aggarwal* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Right Now SMTP authentication is not there in the mail class. Is
there anyone who has implemented SMTP authentication with Zend
Framework any how? If so - do let me know asap. That will be a
great help for us.
Regards,
Sanjay Aggarwal
--Cheers,
Gavin
Which ZF List?
=
Everything, except the topics below: fw-general@lists.zend.com
Authorization, Authentication, ACL, Access Control, Session Management
[EMAIL PROTECTED]
Tests, Caching, Configuration, Environment, Logging
[EMAIL PROTECTED]
All things related to databases
[EMAIL PROTECTED]
Documentation, Translations, Wiki Manual / Tutorials
[EMAIL PROTECTED]
Internationalization Localization, Dates, Calendar, Currency, Measure
[EMAIL PROTECTED]
Mail, MIME, PDF, Search, data formats (JSON, ...)
[EMAIL PROTECTED]
MVC, Controller, Router, Views, Zend_Request*
[EMAIL PROTECTED]
Community Servers/Services (shell account, PEAR channel, Jabber)
[EMAIL PROTECTED]
Web Services Servers (HTTP, SOAP, Feeds, XMLRPC, REST)
[EMAIL
Re: [fw-general] Comment on Zend_Validate
Darby Felton schrieb:
We do not yet have a component that provides full functionality for
working with forms; this is a large undertaking, and there are a couple
of proposals for such:
Zend_Form - Simon Mundy Ralf Eggert
http://framework.zend.com/wiki/x/DA4
Zend_Form_Controller Proposal - Simon Mundy
http://framework.zend.com/wiki/x/mQE
I don't think that form validation and the actual form definition should
be too deeply tied together. You shouldn't need to have to use a
fully-featured form package supporting building of the actual form
fields to use data validation for form-like data arrays.
Having said that, I think Zend_Validate is the right place to do
validation of data coming from forms, and when a form package is in a
developed-enough state to be actually useable, it should make use of
Zend_Validate.
It must however also be possible to build forms by hand (markup or
helpers in Zend_View templates) and define rules for validating incoming
data from these forms.
This is why the proposed functionality is needed.
I have seen suggestions similar to this before. How would this support
multidimensional arrays? For example, assume that you need to validate
an array where:
$aData['favorites']['colors'] = array('red', 'blue');
Good point - I suppose this could be done by nesting Zend_Validate
objects. In other words: Define a separate ruleset for each possible
nesting level in a new instance of Zend_Validate and pass that instance
to addValidator() in the main Zend_Validate object.
Yes, though I think there is some confusion over the Zend_Validate
component. It alone is not intended to solve the problem of form
validation. It is intended to solve the problem of validating a single
value against possibly multiple criteria. Zend_Validate would provide
the foundation, however, on which to build a component that eases the
pain of working with form data.
In that case, I think it may be a good option to provide a specialized
subclass of Zend_Validate to deal with array data, which could
optionally be used by a Zend_Form component.
CU
Markus
Re: [fw-general] updating /library to current SVN problems
Hi Michael, I also use find() fetchRow(). What am I doing wrong? I guess you are doing nothing wrong. I just updated to the latest nightly myself and encountered the same notices. These notices are due to a change to the Zend_Db_Adapter_Pdo_Mysql::describeTable() method which does not work properly yet. Just comment out the lines 109 to 111 in the Zend_Db_Adapter_Pdo_Mysql class and it should work again for the moment. This issue has already been reported for MySQL and MSSQL here: http://framework.zend.com/issues/browse/ZF-839 http://framework.zend.com/issues/browse/ZF-840 Best Regards, Ralf
[fw-general] zend_date
I've been trying to use zend_date to rearrange mysql dates and am having
problems.
when i try the examples from the manual
$date = new Zend_Date();
print $date;
or
$date = new Zend_Date();
print $date-get();
I get Warning: Missing argument 1 for Zend_Date::__construct(), called
in /home/applications/controllers/TestController.php on line 13 and
defined in /home/library/Zend/Date.php on line 147
I found an example of rearranging a date from the mailing list
$mydate is a mysql date 2007-01-31
$date = new Zend_Date($myDate, Zend_Date::ISO_8601);
$date-toString('dd.MM. HH:mm:ss');
when i try this i get the date that is stored in the mysql but the
toString() as no effect on the output. Changing any of the MM. does
not change the output.
All I want to do is change 2007-01-31 to 01-31-2007.
Thanks in advance for any help,
Mike
Re: [fw-general] PEAR Channel Distro
I see much value in each of the following scenarios, which combined form what I expect to cover the majority of use cases: 1) PEAR component distributing entire ZF (for developers interested primarily in the latest official release of the incubator, docs, and tests, with an easy mechanism to update to a future official release). 2) PEAR component distributing only the stable, production-ready code tree (for easy deployment to production servers) 3) SVN checkout of the entire ZF (for developers interested in the latest and greatest incubator, docs, and tests) 4) Downloadable tarballs/zip archives for those in a hurry, who want a specific release once and no updates. 5) Downloadable nightly snapshots for those who one to make a one-time evaluation/analysis of the latest versions of everything in our source code repository. 6) Online docs - I have a personal bias due to a belief that online documentation usually enables more rapid and frequent updates, user comments and contributions, and ease of use, thus resulting in greater developer productivity. Developers doing actual development probably want #1 or #3 for the reasons Matthew lists below. My personal preference for deploying to production servers is #2. Unfortunately, when we look at the directory structure (zftrunk/library/Zend and zftrunk/incubator/library/Zend) in combination with the conventions of PEAR components, combining both into a single PEAR component (i.e. #1 above) becomes slightly problematic, so #1 might not result in a convenient layout for some. I suggest we start with implementing #2 first by updating and finishing the system started at http://pear.zfdev.com/. Cheers, Gavin Matthew Weier O'Phinney wrote: -- Rob Allen [EMAIL PROTECTED] wrote (on Friday, 02 February 2007, 06:42 AM +): Michael Caplan wrote: Being a newbie, perhaps I am overlooking something here, but I don't understand your comment that The Zend Framework works together, as a complete unit. I understand their are various component dependencies, but I don't believe that I can't use Zend_Pdf, for example, if the _entire_ framework is not installed. If PDF generation is my goal, I don't care to have to install 15MB of framework just to use that piece. If anything I see that as being an inhibitor for framework use, especially as the core framework size grows (and it is, isn't it?). Personally, I think that we should consider packaging up just library/ for each release in addition to the entire caboodle that we do at the moment. Certainly, on our production servers, we don't need demos/ documentation/, incubator/ or tests/. Just a note: most PEAR packages contain, minimally, tests, and often documentation and examples. Granted, however, the ZF documentation is the larger part of the install, so it may make sense to have it available separately. (It's good to have the tests available, as you may run them on an architecture different than those developing a component, which may expose new errors. Additionally, tests show you how the code is intended to work.)
[Fwd: Re: [fw-general] PEAR Channel Distro]
I forgot to reply to the list. ---BeginMessage--- Solution #2 would be great for silverorange. If we want the latest and greatest from the incubator packages for our dev servers we can do a SVN checkout. Also, we love your on-line documentation. On Fri, 2007-02-02 at 14:05 -0800, Gavin Vess wrote: I see much value in each of the following scenarios, which combined form what I expect to cover the majority of use cases: 1) PEAR component distributing entire ZF (for developers interested primarily in the latest official release of the incubator, docs, and tests, with an easy mechanism to update to a future official release). 2) PEAR component distributing only the stable, production-ready code tree (for easy deployment to production servers) 3) SVN checkout of the entire ZF (for developers interested in the latest and greatest incubator, docs, and tests) 4) Downloadable tarballs/zip archives for those in a hurry, who want a specific release once and no updates. 5) Downloadable nightly snapshots for those who one to make a one-time evaluation/analysis of the latest versions of everything in our source code repository. 6) Online docs - I have a personal bias due to a belief that online documentation usually enables more rapid and frequent updates, user comments and contributions, and ease of use, thus resulting in greater developer productivity. Developers doing actual development probably want #1 or #3 for the reasons Matthew lists below. My personal preference for deploying to production servers is #2. Unfortunately, when we look at the directory structure (zftrunk/library/Zend and zftrunk/incubator/library/Zend) in combination with the conventions of PEAR components, combining both into a single PEAR component (i.e. #1 above) becomes slightly problematic, so #1 might not result in a convenient layout for some. I suggest we start with implementing #2 first by updating and finishing the system started at http://pear.zfdev.com/. Cheers, Gavin Matthew Weier O'Phinney wrote: -- Rob Allen [EMAIL PROTECTED] wrote (on Friday, 02 February 2007, 06:42 AM +): Michael Caplan wrote: Being a newbie, perhaps I am overlooking something here, but I don't understand your comment that The Zend Framework works together, as a complete unit. I understand their are various component dependencies, but I don't believe that I can't use Zend_Pdf, for example, if the _entire_ framework is not installed. If PDF generation is my goal, I don't care to have to install 15MB of framework just to use that piece. If anything I see that as being an inhibitor for framework use, especially as the core framework size grows (and it is, isn't it?). Personally, I think that we should consider packaging up just library/ for each release in addition to the entire caboodle that we do at the moment. Certainly, on our production servers, we don't need demos/ documentation/, incubator/ or tests/. Just a note: most PEAR packages contain, minimally, tests, and often documentation and examples. Granted, however, the ZF documentation is the larger part of the install, so it may make sense to have it available separately. (It's good to have the tests available, as you may run them on an architecture different than those developing a component, which may expose new errors. Additionally, tests show you how the code is intended to work.) ---End Message---
Re: [fw-general] zend_date
Hi Mike,
If you're pulling dates from MySQL, why not use DATE_FORMAT()?
http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function-date-format
Hope that helps,
-Matt
I've been trying to use zend_date to rearrange mysql dates and am having
problems.
when i try the examples from the manual
$date = new Zend_Date();
print $date;
or
$date = new Zend_Date();
print $date-get();
I get Warning: Missing argument 1 for Zend_Date::__construct(), called
in /home/applications/controllers/TestController.php on line 13 and
defined in /home/library/Zend/Date.php on line 147
I found an example of rearranging a date from the mailing list
$mydate is a mysql date 2007-01-31
$date = new Zend_Date($myDate, Zend_Date::ISO_8601);
$date-toString('dd.MM. HH:mm:ss');
when i try this i get the date that is stored in the mysql but the
toString() as no effect on the output. Changing any of the MM. does
not change the output.
All I want to do is change 2007-01-31 to 01-31-2007.
Thanks in advance for any help,
Mike
[fw-general] getting controllers into subdirectories
Greetings to Zend Framework team; Is there an example of getting the rewrite router to work with controllers in subdirectories? I have several controllers and I would like to group them into different functional areas and place them into subdirectories. I want the URL *' /testing/test/info' *to map to /testing/TestController.php. Where TestController.php contains infoAction.. I have tried several different urls similar to */testing_test/info. *I have tried using the 'useModules' switch (in both front controller and router) and then URL */testing/test/info* but nothing seems to work. Is there a code snippet that shows controller setup that works with subdirectories? A very plain example would be most appreciated. Thanks. pat
Re: [fw-general] PEAR Channel Distro
Matthew Weier O'Phinney wrote: Just a note: most PEAR packages contain, minimally, tests, and often documentation and examples. I only actually discovered this recently when one pear package put it's docs and tests in c:\php\pear even though my install is in c:\programs\php\pear ... Regards, Rob...
