[fw-general] problem for zend_feed

[Jacky Chen]

Hi,there
i met a problem when i produce a rss feed.How can i encode the entry
title?If the entry title contain the & char,a warning would occure.
*Warning*: DOMDocument::createElement()
[function.DOMDocument-createElement]:
unterminated entity reference

Regards,
Jacky

Re: [fw-general] Zend_Filter_Input...

[Pádraic Brady]

>Not trying to pick on you, Simon and Pádraic.  :-)  But I would actually
>PREFER that developers always be aware that their data can come from
>anywhere, just so they stay paranoid.

np ;), but isn't that the same or a related point I reiterated? Yes, developers 
should be aware data can come from anywhere, which also makes it important they 
know to narrow down access methods to eliminate unexpected ones - standard 
security practice. Surely that was always the problem of using $_REQUEST in 
preference to deliberately selecting one of $_POST, $_GET, $_COOKIE. Just as 
improperly relying on getParam (since it's currently an accessible public 
method) instead of getPost hides where the data came from, adding an 
unnecessary element of risk which today we see in CSRF vectors. All I intended 
to note (sorry if my wording was obscure!)  was using a multi-source method was 
bad practice. I have bad habit I think of stating the obvious across a page of 
text :). Yep, definitely bad.

Also, I wish I understood or had read more about the Request object. It was my 
impression the Request object was not solely intended for controller logic. I 
guess I misinterpreted its uses since it seemed a natural fit for any standard 
Request object - really should note the distinction in the manual because it 
should be avoided if that's the case. Or maybe I should read the manual more 
often in case it already is!
 
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com


- Original Message 
From: Matthew Ratzloff <[EMAIL PROTECTED]>
To: Zend Framework General 
Sent: Thursday, March 22, 2007 6:23:47 PM
Subject: Re: [fw-general] Zend_Filter_Input...

"[I]f we have too many sources for input variables, some of which check
varying sources in priority it's just another $_REQUEST situation where
these values could conceivably come from anywhere."

The data DOES come from anywhere.  Data is not somehow more secure if it
is POST.  POST variables can be manipulated with only slightly more
difficulty in a browser than modifying the query string, and when using
something like cURL or Zend_Http_Client the difference is insignificant.

Data should be checked not only for "well-formedness" (e.g., correct data
type) but also for validity and access rights.  Whatever filtering
solution is created post-1.0, it is not going to be a comprehensive
solution unless used in combination with Zend_Validate, Zend_Auth, and
Zend_Acl.

Most PHP developers either don't understand this, don't care about this,
or their development timeline is paced so ridiculously short that they
don't have time to deal with it.  Most of the time it's one of the first
two.  In the third case, I've had to show clients numerous times how easy
it is to get into supposedly secure web applications, just to show how
important it is to get it right.  You would be surprised how little
difficulty you encounter when trying to gain access to supposedly secure
web systems because of attitudes like "it comes from POST, therefore it's
more secure".

Not trying to pick on you, Simon and Pádraic.  :-)  But I would actually
PREFER that developers always be aware that their data can come from
anywhere, just so they stay paranoid.

-Matt

On Thu, March 22, 2007 3:36 am, Pádraic Brady wrote:
> In agree with you Simon - if we have too many sources for input
> variables, some of which check varying sources in priority it's just
> another $_REQUEST situation where these values could conceivably come
> from anywhere. It's better practice to use a method which selects
> values from a known source on the basis if it comes from anywhere else
> unexpectedly it should ring a few alarm bells for the developer. I'd
> actually call it first line filtering/validation - if we know a value
> should be received via POST then if the same value is retrievable from
> GET it should be ignored unless it's for a valid reason.
> Pádraic Brady
> http://blog.astrumfutura.com
> http://www.patternsforphp.com
>
>
> - Original Message 
> From: Simon R Jones <[EMAIL PROTECTED]>
> To: Zend Mailing List 
> Sent: Thursday, March 22, 2007 8:13:19 AM
> Subject: RE: [fw-general] Zend_Filter_Input...
>
>> You can use $this->_getParam('key', 'default'); in a Controller, because
>>  _getParam() use the Request->getParam() method, which tries first to
>> load the param from the url, then from $_GET and after this from $_POST.
>
> If $this->_getParam() looks at the URL, GET and POST isn't it a potential
> security issue to use it for POST variables since you don't know exactly
> where your input variables are coming from?
>
> Seems rather similar to $_REQUEST to me which should also be avoided for
> similar reasons -
> http://shiflett.org/articles/ideology
>
> A quick look at the (nicely growing) manual it seems you can do the
> following which does the job nicely for POST variables:
>
> $myVar = $this->getPost('name');
>
> (See API docs / Zend_Controller_Request_Http for more)
>
> There do seem to

Re: [fw-general] Zend_Filter_Input...

[Matthew Ratzloff]

Well, my point was that because any of those can be manipulated (POST,
GET, COOKIE, etc.), selecting from a specific source can lead to a false
sense of added security.  Better to make your application capable of
reliably accepting data from any source and acting on it appropriately. 
In other words, to deal with user data as if it had come from a single
source: the user.

-Matt

On Thu, March 22, 2007 3:27 pm, Pádraic Brady wrote:
> np ;), but isn't that the same or a related point I reiterated? Yes,
> developers should be aware data can come from anywhere, which also makes
> it important they know to narrow down access methods to eliminate
> unexpected ones - standard security practice. Surely that was always the
> problem of using $_REQUEST in preference to deliberately selecting one of
> $_POST, $_GET, $_COOKIE. Just as improperly relying on getParam (since
> it's currently an accessible public method) instead of getPost hides where
> the data came from, adding an unnecessary element of risk which today we
> see in CSRF vectors. All I intended to note (sorry if my wording was
> obscure!)  was using a multi-source method was bad practice. I have bad
> habit I think of stating the obvious across a page of text :). Yep,
> definitely bad.
>
> Also, I wish I understood or had read more about the Request object. It
> was my impression the Request object was not solely intended for
> controller logic. I guess I misinterpreted its uses since it seemed a
> natural fit for any standard Request object - really should note the
> distinction in the manual because it should be avoided if that's the case.
> Or maybe I should read the manual more often in case it already is!
>
> Pádraic Brady
> http://blog.astrumfutura.com
> http://www.patternsforphp.com
>
>
> - Original Message 
> From: Matthew Ratzloff <[EMAIL PROTECTED]>
> To: Zend Framework General 
> Sent: Thursday, March 22, 2007 6:23:47 PM
> Subject: Re: [fw-general] Zend_Filter_Input...
>
> "[I]f we have too many sources for input variables, some of which check
> varying sources in priority it's just another $_REQUEST situation where
> these values could conceivably come from anywhere."
>
> The data DOES come from anywhere.  Data is not somehow more secure if it
> is POST.  POST variables can be manipulated with only slightly more
> difficulty in a browser than modifying the query string, and when using
> something like cURL or Zend_Http_Client the difference is insignificant.
>
> Data should be checked not only for "well-formedness" (e.g., correct data
> type) but also for validity and access rights.  Whatever filtering
> solution is created post-1.0, it is not going to be a comprehensive
> solution unless used in combination with Zend_Validate, Zend_Auth, and
> Zend_Acl.
>
> Most PHP developers either don't understand this, don't care about this,
> or their development timeline is paced so ridiculously short that they
> don't have time to deal with it.  Most of the time it's one of the first
> two.  In the third case, I've had to show clients numerous times how easy
> it is to get into supposedly secure web applications, just to show how
> important it is to get it right.  You would be surprised how little
> difficulty you encounter when trying to gain access to supposedly secure
> web systems because of attitudes like "it comes from POST, therefore it's
> more secure".
>
> Not trying to pick on you, Simon and Pádraic.  :-)  But I would actually
> PREFER that developers always be aware that their data can come from
> anywhere, just so they stay paranoid.
>
> -Matt
>
> On Thu, March 22, 2007 3:36 am, Pádraic Brady wrote:
>> In agree with you Simon - if we have too many sources for input
>> variables, some of which check varying sources in priority it's just
>> another $_REQUEST situation where these values could conceivably come
>> from anywhere. It's better practice to use a method which selects
>> values from a known source on the basis if it comes from anywhere else
>> unexpectedly it should ring a few alarm bells for the developer. I'd
>> actually call it first line filtering/validation - if we know a value
>> should be received via POST then if the same value is retrievable from
>> GET it should be ignored unless it's for a valid reason.
>> Pádraic Brady
>> http://blog.astrumfutura.com
>> http://www.patternsforphp.com
>>
>>
>> - Original Message 
>> From: Simon R Jones <[EMAIL PROTECTED]>
>> To: Zend Mailing List 
>> Sent: Thursday, March 22, 2007 8:13:19 AM
>> Subject: RE: [fw-general] Zend_Filter_Input...
>>
>>> You can use $this->_getParam('key', 'default'); in a Controller,
>>> because
>>>  _getParam() use the Request->getParam() method, which tries first to
>>> load the param from the url, then from $_GET and after this from
>>> $_POST.
>>
>> If $this->_getParam() looks at the URL, GET and POST isn't it a
>> potential
>> security issue to use it for POST variables since you don't know exactly
>> where your input variables are coming 

[fw-general] JIRA Issue Tracker Linking - "is related to"

[Gavin Vess]

Greetings,

I added a new issue linking relationship to our issue tracker called "is 
related to".  Previously, only "duplicate" and "depends on" were 
supported.  However, sometimes issues are related, similar, or variants 
worthy of their own issue.  Rather than create numerous additional 
relationships, I only created "is related to" for now.


Cheers,
Gavin

P.S. JIRA issue linking is directional, and each direction has its own 
name.  For example, "duplicates" vs. "is duplicated by".  However, for 
general-purpose "is related to", the relationship is identical in both 
directions, but JIRA lists both in the drop down box (i.e. twice).  
Please ignore this duplication.

Re: [fw-general] getting-started-with-the-zend-framework_124.pdf

[Alexander Netkachev]

Hi,

1. Probably it is better to address this issue to the author of the
tutorial...
2. It would be nice to narrow down the problem and create example that shows
a problem and this example should be as small as possible.

Sincerely,
Alex


On 3/22/07, José de Menezes Soares Neto <[EMAIL PROTECTED]> wrote:


 Hi,

I am following this tutorial. And I am getting this error for redirecting:

*Fatal error*: Uncaught exception 'Zend_Controller_Response_Exception'
with message 'Cannot send headers; headers already sent' in
D:\www\projeto\lib\Zend\Controller\Response\Abstract.php:240 Stack trace: #0
D:\www\projeto\lib\Zend\Controller\Response\Abstract.php(125):
Zend_Controller_Response_Abstract->canSendHeaders(true) #1
D:\www\projeto\lib\Zend\Controller\Action.php(607):
Zend_Controller_Response_Abstract->setRedirect('/projeto/', 302) #2
D:\www\projeto\application\controllers\IndexController.php(143):
Zend_Controller_Action->_redirect('/') #3
D:\www\projeto\lib\Zend\Controller\Action.php(392):
IndexController->deleteAction() #4
D:\www\projeto\lib\Zend\Controller\Dispatcher\Standard.php(211):
Zend_Controller_Action->dispatch('deleteAction') #5
D:\www\projeto\lib\Zend\Controller\Front.php(750):
Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http),
Object(Zend_Controller_Response_Http)) #6 D:\www\projeto\index.php(44):
Zend_Controller_Front->dispatch() #7 {main} thrown in *
D:\www\projeto\lib\Zend\Controller\Response\Abstract.php* on line *240*
**
Could someone help me?

Re: [fw-general] Tutorial Zend Framework and Smarty

[Alexander Netkachev]

Consider the following:
* Primitus application: http://framework.zend.com/wiki/x/hw0, now available
in SVN.
* http://akrabat.com/zend-framework-tutorial/
* External Resources - Tutorials, Articles, and Examples:
http://framework.zend.com/wiki/x/q

Sincerely,

On 3/22/07, José de Menezes Soares Neto <[EMAIL PROTECTED]> wrote:


 Friends,

I am looking for two tutorials that helps me to:

- Use Zend Framework
- Integrate ZF and Smarty

Best regards,

José de Menezes





--
Alexander
http://www.alexatnet.com/ - Blog and CMS created with Zend Framework and
Ajax.

Re: [fw-general] How to create my own exception handler method ?

[Alexander Netkachev]

Here is code from CMS of my site:
function errorHandler($errno, $errstr, $errfile, $errline) {
   throw new Exception($errstr, $errno);
}
set_error_handler('errorHandler');

... skip initialization code 

   try {
   $front->dispatch();
   } catch (Exception $e) {
   if ($e instanceof Zend_Controller_Dispatcher_Exception) {
   $front->setRequest(new
Zend_Controller_Request_Http(MYSPHERE_URL . '/error/error404'));
   $front->dispatch();
   } elseif ('debug' == $config->mode) {
   throw $e;
   } else {
   $front->setRequest(new
Zend_Controller_Request_Http(MYSPHERE_URL . '/error/error500'));
   $front->dispatch();
   }
   }


Sincerely,

On 3/22/07, Juan Felipe Alvarez Saldarriaga <[EMAIL PROTECTED]> wrote:


Hey :)

Im traying to make my own exception handler, I set a global exception
handler function, "set_exception_handler( 'exceptionHandler' )", to deal
with the "throw Exception()" command, so when the Exception "jumps" to
this function I want to show all the Exception information into a view,
but how to redirect this data to a view ? I mean, how to call a
Controller there ? this function is defined on the bootstrap index.php,
so I try to do something like that:

Define a global method to deal with the exceptions, this method is on
the bootstrap index.php.
In this function I make a Zend::loadClass( 'ExceptionHandler' ); this
class is where Im going to send an email or something and off course
show some Exceptions attributes, like the line of the error and stuff
like that. But cause this class is not part of the framework I can't
never load a controller to instance an action there an then show this
information into a view. Somebody can help me on this ?

Thx.





--
Alexander
http://www.alexatnet.com/ - Blog and CMS created with Zend Framework and
Ajax.

[fw-general] How to create my own exception handler method ?

[Juan Felipe Alvarez Saldarriaga]

Hey :)

Im traying to make my own exception handler, I set a global exception 
handler function, "set_exception_handler( 'exceptionHandler' )", to deal 
with the "throw Exception()" command, so when the Exception "jumps" to 
this function I want to show all the Exception information into a view, 
but how to redirect this data to a view ? I mean, how to call a 
Controller there ? this function is defined on the bootstrap index.php, 
so I try to do something like that:


Define a global method to deal with the exceptions, this method is on 
the bootstrap index.php.
In this function I make a Zend::loadClass( 'ExceptionHandler' ); this 
class is where Im going to send an email or something and off course 
show some Exceptions attributes, like the line of the error and stuff 
like that. But cause this class is not part of the framework I can't 
never load a controller to instance an action there an then show this 
information into a view. Somebody can help me on this ?


Thx.

[fw-general] Tutorial Zend Framework and Smarty

[José de Menezes Soares Neto]

Friends,

I am looking for two tutorials that helps me to:

- Use Zend Framework
- Integrate ZF and Smarty

Best regards,

José de Menezes

RE: [fw-general] Bug in Table/Abstract and more

[Bill Karwin]

There are more changes that need to be made in the Table::insert() method to 
support other cases.  Sequences and tables with natural keys need to be 
supported.  I have posted a couple of times to the fw-db list about some 
thoughts regarding this, but so far I have been too busy to post an actual 
proposal.

Regards,
Bill Karwin

> -Original Message-
> From: Kevin McArthur [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 22, 2007 2:31 PM
> To: Teemu Välimäki; fw-general@lists.zend.com
> Subject: Re: [fw-general] Bug in Table/Abstract and more
> 
> Ya I noticed the sequence issues, but running 8.1 the defaults (now 0.9.0)
> work right.
> 
> I wonder, is there a way to set the sequence name and if not maybe there
> should be...
> 
> K
> - Original Message -
> From: "Teemu Välimäki" <[EMAIL PROTECTED]>
> To: 
> Sent: Thursday, March 22, 2007 1:29 PM
> Subject: [fw-general] Bug in Table/Abstract and more
> 
> 
> > Hi,
> >
> > with 22 day snapshot Db/Table/Abstract.php on line 399 "return
> > $this->_db->lastInsertId();" should apparently give $this->_name as a
> > parameter, otherwise the call will always fail. lastInsertId has a
> > $tableName = null and the first thing is if (!$tableName) throw. After I
> > fixed line 399 with $this->_name I got sequence does not exists error.
> >
> > On Db/Adapter/Pdo/Pgsql.php on line 202 there's a huge assumption how
> the
> > sequence is formed. With 8.2 auto generated sequences are named like
> > "{$tableName}_{$tableName}_{$primaryKey}_seq".
> >
> > After fixing these all seem to work well. I'm not sure if this automatic
> > sequence creation is defined in Postgresql configurations but this has
> > been the setup on FreeBSD 6.2 and *buntu 6.10.
> >
> > Cheers!

Re: [fw-general] Bug in Table/Abstract and more

[Kevin McArthur]

Ya I noticed the sequence issues, but running 8.1 the defaults (now 0.9.0) 
work right.


I wonder, is there a way to set the sequence name and if not maybe there 
should be...


K
- Original Message - 
From: "Teemu Välimäki" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, March 22, 2007 1:29 PM
Subject: [fw-general] Bug in Table/Abstract and more



Hi,

with 22 day snapshot Db/Table/Abstract.php on line 399 "return 
$this->_db->lastInsertId();" should apparently give $this->_name as a 
parameter, otherwise the call will always fail. lastInsertId has a 
$tableName = null and the first thing is if (!$tableName) throw. After I 
fixed line 399 with $this->_name I got sequence does not exists error.


On Db/Adapter/Pdo/Pgsql.php on line 202 there's a huge assumption how the 
sequence is formed. With 8.2 auto generated sequences are named like 
"{$tableName}_{$tableName}_{$primaryKey}_seq".


After fixing these all seem to work well. I'm not sure if this automatic 
sequence creation is defined in Postgresql configurations but this has 
been the setup on FreeBSD 6.2 and *buntu 6.10.


Cheers! 

[fw-general] Bug in Table/Abstract and more

[Teemu Välimäki]

Hi,

with 22 day snapshot Db/Table/Abstract.php on line 399 "return 
$this->_db->lastInsertId();" should apparently give $this->_name as a 
parameter, otherwise the call will always fail. lastInsertId has a $tableName = 
null and the first thing is if (!$tableName) throw. After I fixed line 399 with 
$this->_name I got sequence does not exists error.

On Db/Adapter/Pdo/Pgsql.php on line 202 there's a huge assumption how the 
sequence is formed. With 8.2 auto generated sequences are named like 
"{$tableName}_{$tableName}_{$primaryKey}_seq".

After fixing these all seem to work well. I'm not sure if this automatic 
sequence creation is defined in Postgresql configurations but this has been the 
setup on FreeBSD 6.2 and *buntu 6.10.

Cheers!

[fw-general] ZF 0.9.1 code freeze tonight

[Bill Karwin]

Hi,

We will have a code-freeze for the Zend Framework 0.9.1 beta refresh
tonight at 9:00pm Pacific time.  There have been 26 bugs fixed in the
past week, and it will be worthwhile to do a beta refresh.

We are planning another beta refresh (0.9.2) before we get to 1.0.0 RC1.
Probably in two weeks (about April 6).

Regards,
Bill Karwin

Re: [fw-general] Zend_Filter_Input...

[Matthew Ratzloff]

"[I]f we have too many sources for input variables, some of which check
varying sources in priority it's just another $_REQUEST situation where
these values could conceivably come from anywhere."

The data DOES come from anywhere.  Data is not somehow more secure if it
is POST.  POST variables can be manipulated with only slightly more
difficulty in a browser than modifying the query string, and when using
something like cURL or Zend_Http_Client the difference is insignificant.

Data should be checked not only for "well-formedness" (e.g., correct data
type) but also for validity and access rights.  Whatever filtering
solution is created post-1.0, it is not going to be a comprehensive
solution unless used in combination with Zend_Validate, Zend_Auth, and
Zend_Acl.

Most PHP developers either don't understand this, don't care about this,
or their development timeline is paced so ridiculously short that they
don't have time to deal with it.  Most of the time it's one of the first
two.  In the third case, I've had to show clients numerous times how easy
it is to get into supposedly secure web applications, just to show how
important it is to get it right.  You would be surprised how little
difficulty you encounter when trying to gain access to supposedly secure
web systems because of attitudes like "it comes from POST, therefore it's
more secure".

Not trying to pick on you, Simon and Pádraic.  :-)  But I would actually
PREFER that developers always be aware that their data can come from
anywhere, just so they stay paranoid.

-Matt

On Thu, March 22, 2007 3:36 am, Pádraic Brady wrote:
> In agree with you Simon - if we have too many sources for input
> variables, some of which check varying sources in priority it's just
> another $_REQUEST situation where these values could conceivably come
> from anywhere. It's better practice to use a method which selects
> values from a known source on the basis if it comes from anywhere else
> unexpectedly it should ring a few alarm bells for the developer. I'd
> actually call it first line filtering/validation - if we know a value
> should be received via POST then if the same value is retrievable from
> GET it should be ignored unless it's for a valid reason.
> Pádraic Brady
> http://blog.astrumfutura.com
> http://www.patternsforphp.com
>
>
> - Original Message 
> From: Simon R Jones <[EMAIL PROTECTED]>
> To: Zend Mailing List 
> Sent: Thursday, March 22, 2007 8:13:19 AM
> Subject: RE: [fw-general] Zend_Filter_Input...
>
>> You can use $this->_getParam('key', 'default'); in a Controller, because
>>  _getParam() use the Request->getParam() method, which tries first to
>> load the param from the url, then from $_GET and after this from $_POST.
>
> If $this->_getParam() looks at the URL, GET and POST isn't it a potential
> security issue to use it for POST variables since you don't know exactly
> where your input variables are coming from?
>
> Seems rather similar to $_REQUEST to me which should also be avoided for
> similar reasons -
> http://shiflett.org/articles/ideology
>
> A quick look at the (nicely growing) manual it seems you can do the
> following which does the job nicely for POST variables:
>
> $myVar = $this->getPost('name');
>
> (See API docs / Zend_Controller_Request_Http for more)
>
> There do seem to be a lot of methods that return variables from GET, POST,
> COOKIE, etc. I think it would be a good idea to mention the security
> implications of depending on these in the manual..
>
> Si

Re: [fw-general] Zend_Filter_Input...

[Ed Finkler]

On 3/22/07, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote:


Once I realized people were using the request object in order to pull
GET and POST data -- instead of accessing those superglobals themselves,
or using a proxy such as Zend_Filter_Input, I realized that this would
be a security vector.  However, without stable validation/filtering
classes ready, this simply could not be addressed properly. Now that
they are, we can begin addressing this. This is why I mentioned that it
will be dealt with in a later iteration. Any solution will need to
remain backwards compatible with the current API, however. This should
not be difficult due to the nature of the accessors.


Fair enough.  Here's hoping that happens quickly.
--
- Ed Finkler
http://funkatron.com/

[fw-general] headers already sent

[José de Menezes Soares Neto]

how do I solve this kind of problem in ZF??

Re: [fw-general] Zend_Filter_Input...

[Kevin McArthur]

getParam should, imho, return params only, if theres need for routing for 
cacaded stuff then maybe a getInput or similar. You shouldn't be able to 
override post data with a param, or, at least thats not how the fw should be 
recommending apps be built using getParam like $_REQUEST.


If you get rid of the $_request-like way of getParam, then the validation 
question of origin becomes less problematic. Anyone using getParams etc 
should already be validating the type of data (as it's from userland) with 
Zend_Validate/Zend_Filter, and/or putting a regexp on the route.


However, my response was in response to


That's fine, just as long as new users always use $_POST or getPost() to
retrieve POST variables so they know where they are coming from.


If you change getParams, this problem goes away completely.

Kevin


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

To: 
Sent: Thursday, March 22, 2007 10:59 AM
Subject: Re: [fw-general] Zend_Filter_Input...



-- Kevin McArthur <[EMAIL PROTECTED]> wrote
(on Thursday, 22 March 2007, 11:36 AM -0700):

Hopefully getParam will be unified with the rest of the get* methods in
Zend_Request, and this all wont be a problem.


I fail to see how this is even related to the discussion. The request
you had earlier this week was to have getParam(null) return the entire
list of params, vs. having a getParams() method -- what does this have
to do with input filtering?

Additionally, getParam() right now looks through several arrays:

   * internal param store (usu. set by the router from the request uri)
   * $_GET params
   * $_POST params

The reason for this is that information necessary for routing can be
found in each of these, and if not found in one should cascade down
through the others until found (if available).

Note: getUserParam()/getUserParams() return just the internal param
store.

To normalize the API, I will definitely consider modifying getParam()
and getUserParam() to accept a null argument to return the entire
arrays, and then remove getParams() and getUserParams(). But I'm not
sure that these changes address the input filtering discussion.

- Original Message - 
From: "Simon R Jones" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, March 22, 2007 10:34 AM
Subject: RE: [fw-general] Zend_Filter_Input...

> > It was never intended as a general-purpose object for
> > input filtering -- that's a goal for a later iteration, which will 
> > still

> > need to account for the variety of sources when dealing with routing.
>
> That's fine, just as long as new users always use $_POST or getPost() 
> to

> retrieve POST variables so they know where they are coming from.
>
> Just something that may be worth highlighting in the manual for 1.0 -
> Presumably there will be/is a small section saying where to get various
> things when using the Router (i.e. URL parameters, GET vars, POST 
> vars)?


--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/ 

Re: [fw-general] Zend_Filter_Input...

[Matthew Weier O'Phinney]

-- Kevin McArthur <[EMAIL PROTECTED]> wrote
(on Thursday, 22 March 2007, 11:36 AM -0700):
> Hopefully getParam will be unified with the rest of the get* methods in 
> Zend_Request, and this all wont be a problem.

I fail to see how this is even related to the discussion. The request
you had earlier this week was to have getParam(null) return the entire
list of params, vs. having a getParams() method -- what does this have
to do with input filtering?

Additionally, getParam() right now looks through several arrays:

* internal param store (usu. set by the router from the request uri)
* $_GET params
* $_POST params

The reason for this is that information necessary for routing can be
found in each of these, and if not found in one should cascade down
through the others until found (if available).

Note: getUserParam()/getUserParams() return just the internal param
store.

To normalize the API, I will definitely consider modifying getParam()
and getUserParam() to accept a null argument to return the entire
arrays, and then remove getParams() and getUserParams(). But I'm not
sure that these changes address the input filtering discussion.

> - Original Message - 
> From: "Simon R Jones" <[EMAIL PROTECTED]>
> To: 
> Sent: Thursday, March 22, 2007 10:34 AM
> Subject: RE: [fw-general] Zend_Filter_Input...
> 
> > > It was never intended as a general-purpose object for
> > > input filtering -- that's a goal for a later iteration, which will still
> > > need to account for the variety of sources when dealing with routing.
> > 
> > That's fine, just as long as new users always use $_POST or getPost() to
> > retrieve POST variables so they know where they are coming from.
> > 
> > Just something that may be worth highlighting in the manual for 1.0 -
> > Presumably there will be/is a small section saying where to get various
> > things when using the Router (i.e. URL parameters, GET vars, POST vars)?

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

[fw-general] getting-started-with-the-zend-framework_124.pdf

[José de Menezes Soares Neto]

Hi,

I am following this tutorial. And I am getting this error for redirecting:

Fatal error: Uncaught exception 'Zend_Controller_Response_Exception' with 
message 'Cannot send headers; headers already sent' in 
D:\www\projeto\lib\Zend\Controller\Response\Abstract.php:240 Stack trace: #0 
D:\www\projeto\lib\Zend\Controller\Response\Abstract.php(125): 
Zend_Controller_Response_Abstract->canSendHeaders(true) #1 
D:\www\projeto\lib\Zend\Controller\Action.php(607): 
Zend_Controller_Response_Abstract->setRedirect('/projeto/', 302) #2 
D:\www\projeto\application\controllers\IndexController.php(143): 
Zend_Controller_Action->_redirect('/') #3 
D:\www\projeto\lib\Zend\Controller\Action.php(392): 
IndexController->deleteAction() #4 
D:\www\projeto\lib\Zend\Controller\Dispatcher\Standard.php(211): 
Zend_Controller_Action->dispatch('deleteAction') #5 
D:\www\projeto\lib\Zend\Controller\Front.php(750): 
Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http),
 Object(Zend_Controller_Response_Http)) #6 D:\www\projeto\index.php(44): 
Zend_Controller_Front->dispatch() #7 {main} thrown in 
D:\www\projeto\lib\Zend\Controller\Response\Abstract.php on line 240

Could someone help me?

Re: [fw-general] Zend_Filter_Input...

[Matthew Weier O'Phinney]

-- Ed Finkler <[EMAIL PROTECTED]> wrote
(on Thursday, 22 March 2007, 01:27 PM -0400):
> On 3/22/07, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote:
> > Please remember that Zend_Controller_Request_* was built to help with
> > routing and dispatching -- which is why getParam() pulls from a variety
> > of sources (when determining how to route a request, the salient input
> > could come from a variety of sources -- the path, query parameters, post
> > parameters, etc.). It was never intended as a general-purpose object for
> > input filtering -- that's a goal for a later iteration, which will still
> > need to account for the variety of sources when dealing with routing.
> 
> That security considerations are not part of the initial
> implementation, but something added later in the process, is in and of
> itself worrisome.

There's a heavy amount of filtering going on in the router and
dispatcher -- that's where the security is residing for this
implementation.

Zend_Controller_Request_Abstract has *no* methods for interacting with
the environment whatsoever -- simply accessors for setting parameters
and module/controller/action values.

The HTTP version is designed to pull information out of the HTTP
environment in order to aid routing and dispatch tasks; this includes
the path, query string parameters, post variables, cookies, and more.
Again, the point was not for general purpose consumption by userland
scripts. However, since it is made accessible by the action controllers
(in order to allow things like action forwarding), many have used it for
pulling data in much the way $_REQUEST has been used in the past. 

Once I realized people were using the request object in order to pull
GET and POST data -- instead of accessing those superglobals themselves,
or using a proxy such as Zend_Filter_Input, I realized that this would
be a security vector.  However, without stable validation/filtering
classes ready, this simply could not be addressed properly. Now that
they are, we can begin addressing this. This is why I mentioned that it
will be dealt with in a later iteration. Any solution will need to
remain backwards compatible with the current API, however. This should
not be difficult due to the nature of the accessors.

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

Re: [fw-general] A common pattern for instantiation of alternative classes by an object.

[Matthew Ratzloff]

In that case, you might as well make it a true factory and just have:

return Zend_Delegate::factory('Zend_Controller_Request_Http', $parameters);

which queries Zend_Delegate for any user-specified delegates and
instantiates them.

Defining delegates would be specified like this:

Zend_Delegate::setDelegate('Zend_Controller_Request_Http',
'My_Controller_Request_Http');

There's no need to limit it solely to Zend_Db.  Any instantiated class in
the framework could be overridden from the bootstrap (so long as its
method signatures matched).  This is actually something I'm currently
doing in one of my projects, in a slightly different way (because no
delegating is taking place internally in Zend Framework).

This then would only need to be used with internal code, or for
extensibility-minded open-source developers releasing code based on Zend
Framework.  So code-completion concerns aren't so much an issue for the
broader user base.

Also, it probably would be better to just have it at a class-level, not a
method level.  Users can just extend a class and add or modify a single
method if they need to.

-Matt

On Thu, March 22, 2007 4:34 am, Mark Gibson wrote:
> There was no intention of it being used for static classes.
> It is purely a generalisation or a standard practice for classes
> that instantiate objects, and allow the class of these new objects
> to be changed. Zend_Db_Table_Abstract has these methods that
> manage this:
>
> [...]
>
>  public function select()
>  {
>  $class = Zend_Factory::getClass(__CLASS__, 'select');
>  return new $class();
>  }
>
> Then we can register an alternative/subclass of Zend_Db_Select using
> something like:
>
>  Zend_Factory::setClass('Zend_Db_Adapter_Abstract', 'select',
>  'MyAlternativeSelect');

Re: [fw-general] Zend_Filter_Input...

[Kevin McArthur]

Hopefully getParam will be unified with the rest of the get* methods in 
Zend_Request, and this all wont be a problem.


- Original Message - 
From: "Simon R Jones" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, March 22, 2007 10:34 AM
Subject: RE: [fw-general] Zend_Filter_Input...



It was never intended as a general-purpose object for
input filtering -- that's a goal for a later iteration, which will still
need to account for the variety of sources when dealing with routing.


That's fine, just as long as new users always use $_POST or getPost() to
retrieve POST variables so they know where they are coming from.

Just something that may be worth highlighting in the manual for 1.0 -
Presumably there will be/is a small section saying where to get various
things when using the Router (i.e. URL parameters, GET vars, POST vars)?

best wishes,
Si

RE: [fw-general] Zend_Filter_Input...

[Simon R Jones]

> It was never intended as a general-purpose object for
> input filtering -- that's a goal for a later iteration, which will still
> need to account for the variety of sources when dealing with routing.

That's fine, just as long as new users always use $_POST or getPost() to
retrieve POST variables so they know where they are coming from. 

Just something that may be worth highlighting in the manual for 1.0 -
Presumably there will be/is a small section saying where to get various
things when using the Router (i.e. URL parameters, GET vars, POST vars)?

best wishes,
Si

Re: [fw-general] Zend_Filter_Input...

[Ed Finkler]

On 3/22/07, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote:


Please remember that Zend_Controller_Request_* was built to help with
routing and dispatching -- which is why getParam() pulls from a variety
of sources (when determining how to route a request, the salient input
could come from a variety of sources -- the path, query parameters, post
parameters, etc.). It was never intended as a general-purpose object for
input filtering -- that's a goal for a later iteration, which will still
need to account for the variety of sources when dealing with routing.


That security considerations are not part of the initial
implementation, but something added later in the process, is in and of
itself worrisome.

--
- Ed Finkler
http://funkatron.com/

Re: [fw-general] [Zend][Controller][Action] unsetParam() and some suggestions

[Shekar C Reddy]

The point of accessors is to normalize access to properties. Using the
properties directly within methods such as render(), _forward(), etc.
could cause issues later for those who *do* override the
getRequest()/getResponse() accessors -- basically, we'd be breaking
*other* people's apps.

Ok. I did not comprehend what you were saying earlier and it's clear now.


As a performance optimization, typically what I do is, if needing the
property more than once, I grab it like this:

  $request = $this->getRequest();

which will cut down on the number of times it's retrieved by the
accessor.


Yes, I use that technique, too.

Thanks!





On 3/22/07, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote:


-- Shekar C Reddy <[EMAIL PROTECTED]> wrote
(on Wednesday, 21 March 2007, 09:34 PM -0400):
> 1. Perhaps, the setParam() method could be enhanced to unset/blow-off
the key
> if the value passed is null... We don't want any keys with null values
> lingering around - that would increase complexity as we have to deal
with null
> values! I know getParam() returns default null if the key does not exist
but
> when I invoke getAllParams() to traverse the array, I may end up with
some keys
> that have null values :(  Or maybe, with a third/default $unset argument
if the
> value passed is null, like so:
>
> Signature: _setParam( $key, $value, $unset = false )
> Usage: _setParam( $key, null, true )
>
> [if $value = null && $unset = true, blow off the key]

Good plan. I'll implement this soon.


> 2. Understandable. I did not request to eliminate the
> getRequest/getResponse methods - they are there to serve as an API to
> external objects. What I was referring to was invoking of these
> methods inside Zend_Controller_Action class script to access the
> protected request/response vars that are declared/defined right inside
> the same class. That would degrade performance (you may try
> load-testing the application). These vars could, instead, be accessed
> directly inside Zend_Controller_Action script:
>
> Eg: $this->_request->setParam( ... )

The point of accessors is to normalize access to properties. Using the
properties directly within methods such as render(), _forward(), etc.
could cause issues later for those who *do* override the
getRequest()/getResponse() accessors -- basically, we'd be breaking
*other* people's apps.

As a performance optimization, typically what I do is, if needing the
property more than once, I grab it like this:

   $request = $this->getRequest();

which will cut down on the number of times it's retrieved by the
accessor. This is the only concession I'll make in this regard.


>
> On 3/21/07, Matthew Weier O'Phinney <[EMAIL PROTECTED] > wrote:
>
> -- Shekar C Reddy < [EMAIL PROTECTED]> wrote
> (on Wednesday, 21 March 2007, 06:00 AM -0400):
> > 1. There is no method to unset a param in action controller or its
> request
> > class. We need a unsetParam() method in action/request.
>
> You can always pass a null to setParam():
>
>$this->setParam('someKey', null);
>
> The controller parameters are not really intended to be a general
> purpose storage mechanism; they're primarily for pushing values and
> objects from the front controller down through the controller chain
> (router, dispatcher, action controllers). I personally feel that
> if you're needing something like that, use a Zend_Config object in
> read/write mode and push it in either the registry or as a
controller
> param.
>
> > 2. I see usage of getRequest() and getResponse() methods inside
the
> > action class although these vars are sitting right inside the
class
> > itself (protected $_request, $_response) that can be accessed
directly
> > instead of invoking a method to access them. Accessing them
directly
> > inside the action class should improve performance.
>
> This is true. However, the accessors are there for cases where the
> developer may want to wrap some logic around retrieving these
objects --
> perhaps grabbing them from a registry, for instance. That said, when
I
> know that there's no such logic in classes I'm using, I access them
> directly from the class properties.
>
> --
> Matthew Weier O'Phinney
> PHP Developer| [EMAIL PROTECTED]
> Zend - The PHP Company   | http://www.zend.com/
>
>

--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

[fw-general] How to configure this route

[Php (Absolom)]

Hi, I don't see how to implements this structure : 

/application
/controllers
/models
/views
/my_module
/controllers
IndexController.php
/admin
IndexController.php
/models
/admin
/views
/admin

I write this, and I don't see where to say that the controller directory fot 
the route : /my_module/admin is : /application//my_module/controllers/admin

Thanks for your help

$router = new Zend_Controller_Router_Rewrite();
 
$route = new Zend_Controller_Router_Route(
"my_module/admin/",
array(  "controller"=> 'index',
"action"=>"index"
)
);
$router->addRoute("admin",$route);

$controller = Zend_Controller_Front::getInstance();
$controller->setControllerDirectory(array(
'default' => CONTROLLERS_PATH,
'qualix'   => HOME_PATH . 'application/qualix/controllers/',
)); 
$controller->setRouter($router);
$controller->throwExceptions(true);  
$controller->dispatch();

Re: [fw-general] CLA procesing time?

[Thomas Weidner]

Be happy that they rarely take the 3 weeks as Thomas reported anymore.
:-)


That's true...
Nowadays things go much smoother and faster than in "je old days" ;-)

Greetings
Thomas
I18N Team Leader

Re: [fw-general] CLA procesing time?

[Matthew Weier O'Phinney]

-- Jack Sleight <[EMAIL PROTECTED]> wrote
(on Thursday, 22 March 2007, 07:46 AM -0700):
> I was just wondering how long it takes to process the CLAs? I submitted mine
> a couple of days ago and not heard anything yet.

Bill processes them fairly quickly -- I usually see most requests take
no more than a few days anymore, and sometimes they happen the same day.

We have to either scan in faxed documents or conversely print out
emailed documents for each CLA submitted for our records, verify
information, create accounts, etc. Unfortunately, this means there's
some waiting time involved.

Be happy that they rarely take the 3 weeks as Thomas reported anymore.
:-)

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

Re: [fw-general] CLA procesing time?

[Jack Sleight]

Oh, OK, guess I'll have to wait.

Cheers, 
Jack


Thomas Weidner-2 wrote:
> 
>> I was just wondering how long it takes to process the CLAs? I submitted 
>> mine
>> a couple of days ago and not heard anything yet.
> 
> No hurry...
> mine took about 3 weeks ;-)
> 
> Greetings
> Thomas 
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/CLA-procesing-time--tf3448016s16154.html#a9616441
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] CLA procesing time?

[Thomas Weidner]

I was just wondering how long it takes to process the CLAs? I submitted 
mine

a couple of days ago and not heard anything yet.


No hurry...
mine took about 3 weeks ;-)

Greetings
Thomas 

Re: [fw-general] CLA procesing time?

[Shaun Rowe]

Jack Sleight wrote:
Hi, 
I was just wondering how long it takes to process the CLAs? I submitted mine

a couple of days ago and not heard anything yet.

Cheers, 
Jack


I'd also like to ask the same question. Although I'm not trying to rush 
anyone along.



Many Thanks

Shaun Rowe

[fw-general] CLA procesing time?

[Jack Sleight]

Hi, 
I was just wondering how long it takes to process the CLAs? I submitted mine
a couple of days ago and not heard anything yet.

Cheers, 
Jack
-- 
View this message in context: 
http://www.nabble.com/CLA-procesing-time--tf3448016s16154.html#a9616288
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] ZF 0.8.0

[Alexander Netkachev]

http://framework.zend.com/releases/ZendFramework-0.8.0.zip

On 3/22/07, José de Menezes Soares Neto <[EMAIL PROTECTED]> wrote:


 Could someone send me the ZF 0.8.0?

I will start with it, cause there is no tutorial for ZF 0.9.0...

Best Regards,

José





--
Alexander
http://www.alexatnet.com/ - Blog and CMS created with Zend Framework and
Ajax.

[fw-general] ZF 0.8.0

[José de Menezes Soares Neto]

Could someone send me the ZF 0.8.0?

I will start with it, cause there is no tutorial for ZF 0.9.0...

Best Regards,

José

Re: [fw-general] Multiple ControllerDirectory paths

[Werner]

Thanks Matthew

Extending the front controller will do the trick nicely.

Ditching the multiple directory support in favor of performance is also
not something I will complain about :-) The nice thing about ZF is that
it can easily be extended, so I'll take that route for this specific
project.

Thanks again,
Werner


Matthew Weier O'Phinney wrote:

-- Werner <[EMAIL PROTECTED]> wrote
(on Thursday, 22 March 2007, 01:44 PM +0200):
  
I want to specify multiple controller directories that should all be 
searched for controllers. I want to do this without deploying any 
predefined modular directory structures - just multiple paths for 
controllers (whether modules will be used or not).


However, when specifying any additional directory path it seems like the 
first path is overwritten by the last specified path.


E.g, is it possible to make something like this work...?

$controller->throwExceptions(true)
   ->setRouter($router)
   ->setBaseUrl($baseUrl)
   ->setControllerDirectory('/my/first/path') // Default 
directory
   ->addControllerDirectory('/my/second/path') // Another 
directory
   ->addControllerDirectory('/my/third/path'); // Yet 
another directory


Any ideas, hint or tips on how to achieve this?



This functionality was ditched prior to 0.8.0 as it added too much
overhead, and won't be added again anytime soon. Basically, keeping
track of a stack of directories *per* *module*, and then having to
search each *set* of directories for a controller was very resource
intensive, for very little benefit.

If you need several directories of controllers all in the same
namespace, you might want to try using symlinks or consolidating.

Alternatively, you can implement your own dispatcher and front
controller -- you'd need to override the front controller's
add/setControllerDirectory() methods, and the dispatcher's
getControllerName() method.

  

Re: [fw-general] Feature-Request for Zend_Translate

[Thomas Weidner]

I´m not sure if this really makes a big difference  ;)


There is a difference when you are using views:

Now you have to do it so:

translate('mystring', $locale); ?>


With the change you can do:

print('mystring', $locale); ?>


I dont know how much views you have, but I think there is a simplification 
and a benefit for the users. ;-)
It may be a small benefit for you, but a big for another one... depends on 
how often you are using it.



Whats about a flag?
$tranlsate->print = true;
$tranlsate->_(


No... a flag would break the API and you would have problems when you use 
Zend_Translate not only for output generation.
Two strict seperated function are much more simpler from API's view than 
having a flag.


Greetings
Thomas
I18N Team Leader 

Re: [fw-general] Zend_Filter_Input...

[Matthew Weier O'Phinney]

-- Pádraic Brady <[EMAIL PROTECTED]> wrote
(on Thursday, 22 March 2007, 03:36 AM -0700):
> In agree with you Simon - if we have too many sources for input
> variables, some of which check varying sources in priority it's just
> another $_REQUEST situation where these values could conceivably come
> from anywhere. It's better practice to use a method which selects
> values from a known source on the basis if it comes from anywhere else
> unexpectedly it should ring a few alarm bells for the developer. I'd
> actually call it first line filtering/validation - if we know a value
> should be received via POST then if the same value is retrievable from
> GET it should be ignored unless it's for a valid reason.

Please remember that Zend_Controller_Request_* was built to help with
routing and dispatching -- which is why getParam() pulls from a variety
of sources (when determining how to route a request, the salient input
could come from a variety of sources -- the path, query parameters, post
parameters, etc.). It was never intended as a general-purpose object for
input filtering -- that's a goal for a later iteration, which will still
need to account for the variety of sources when dealing with routing.


> - Original Message 
> From: Simon R Jones <[EMAIL PROTECTED]>
> To: Zend Mailing List 
> Sent: Thursday, March 22, 2007 8:13:19 AM
> Subject: RE: [fw-general] Zend_Filter_Input...
> 
> > You can use $this->_getParam('key', 'default'); in a Controller, because
> >  _getParam() use the Request->getParam() method, which tries first to
> > load the param from the url, then from $_GET and after this from $_POST.
> 
> If $this->_getParam() looks at the URL, GET and POST isn't it a potential
> security issue to use it for POST variables since you don't know exactly
> where your input variables are coming from?
> 
> Seems rather similar to $_REQUEST to me which should also be avoided for
> similar reasons -
> http://shiflett.org/articles/ideology
> 
> A quick look at the (nicely growing) manual it seems you can do the
> following which does the job nicely for POST variables:
> 
> $myVar = $this->getPost('name');
> 
> (See API docs / Zend_Controller_Request_Http for more)
> 
> There do seem to be a lot of methods that return variables from GET, POST,
> COOKIE, etc. I think it would be a good idea to mention the security
> implications of depending on these in the manual..

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

Re: [fw-general] Multiple ControllerDirectory paths

[Matthew Weier O'Phinney]

-- Werner <[EMAIL PROTECTED]> wrote
(on Thursday, 22 March 2007, 01:44 PM +0200):
> I want to specify multiple controller directories that should all be 
> searched for controllers. I want to do this without deploying any 
> predefined modular directory structures - just multiple paths for 
> controllers (whether modules will be used or not).
> 
> However, when specifying any additional directory path it seems like the 
> first path is overwritten by the last specified path.
> 
> E.g, is it possible to make something like this work...?
> 
> $controller->throwExceptions(true)
>->setRouter($router)
>->setBaseUrl($baseUrl)
>->setControllerDirectory('/my/first/path') // Default 
> directory
>->addControllerDirectory('/my/second/path') // Another 
> directory
>->addControllerDirectory('/my/third/path'); // Yet 
> another directory
> 
> Any ideas, hint or tips on how to achieve this?

This functionality was ditched prior to 0.8.0 as it added too much
overhead, and won't be added again anytime soon. Basically, keeping
track of a stack of directories *per* *module*, and then having to
search each *set* of directories for a controller was very resource
intensive, for very little benefit.

If you need several directories of controllers all in the same
namespace, you might want to try using symlinks or consolidating.

Alternatively, you can implement your own dispatcher and front
controller -- you'd need to override the front controller's
add/setControllerDirectory() methods, and the dispatcher's
getControllerName() method.

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

[fw-general] Re: [fw-mvc] Render-method question

[Pádraic Brady]

Hi Jörg,

You could likely add such behaviour if you wanted by subclassing the 
Zend_Controller_Action class - actually you do quite a lot of setup tasks using 
subclassing. Since render() is a public method, you can subclass Action and add 
your own version to meet any requirements you wish.

I wouldn't really recommend it for the core class however - there's already a 
View object and while some proxy methods are a welcome addition the more they 
are added to the less the core class starts to look like an independent entity.


 
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com


- Original Message 
From: Jörg Sandkuhle <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 10:35:34 AM
Subject: [fw-mvc] Render-method question

Hello!

I have a suggestion to the new Zend_Controller_Action->render() method.
Wouldnt it be nice to pass additional parameter to the render method for 
the view ?

e.g. public function render($action = null, $name = null, $noController 
= false, $params=array()).

So you dont have to instantiate the view in an action befor you can pass 
parameter to it.

initView();
$this->view->errorMessage = "Login or password is wrong!"
$this->render();

}
.
?>

Or did i missed something?

Regards Jörg














 

Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel 
bargains.
http://farechase.yahoo.com/promo-generic-14795097

[fw-general] Re: [fw-db] A common pattern for instantiation of alternative classes by an object.

[Mark Gibson]

Matthew Ratzloff wrote:

This would be a nice idea for a generalized component that would apply to
all classes, but unfortunately you can't do it.

For example, this doesn't work:

$object = new Zend_Delegate::getClassName('Zend_Example');

It has to be in two steps:

$class  = Zend_Delegate::getClassName('Zend_Example');
$object = new $class;

And it's downright impossible for static classes unless you use
call_user_func() or call_user_func_array():

$class = Zend_Delegate::getClassName('Zend_Example');
call_user_func(array($class, 'method')); // Works
$class::method(); // Syntax error


There was no intention of it being used for static classes.
It is purely a generalisation or a standard practice for classes
that instantiate objects, and allow the class of these new objects
to be changed. Zend_Db_Table_Abstract has these methods that
manage this:

 setRowClass();
 getRowClass();
 setRowsetClass();
 getRowsetClass();

Also, Zend_Db_Adapter_Abstract can currently generate Zend_Db_Profiler
and Zend_Db_Select objects, but provides no way of selecting alternative
implementations or subclasses of these.

My proposal is to provide a generic way of allowing any class that
has this behaviour to allow the user to set the class of these
objects before they are instantiated.

It's all about instantiation, so static access isn't an issue.

If we went along the global registration route,
using Zend_Db_Adapter_Abstract for example:

public function select()
{
return new Zend_Db_Select($this);
}

becomes:

public function select()
{
$class = Zend_Factory::getClass(__CLASS__, 'select');
return new $class();
}

Then we can register an alternative/subclass of Zend_Db_Select using
something like:

Zend_Factory::setClass('Zend_Db_Adapter_Abstract', 'select',
'MyAlternativeSelect');

then everytime we call $adapter->select(), an instance of
MyAlternativeSelect is returned rather than Zend_Db_Select.

This would eliminate the need for get/set*Class() style methods in
each class.

- Mark.

Re: [fw-general] Question about Zend_Filter_Input

[Pádraic Brady]

Hi Thomas,

Zend_Filter_Input has been deprecated and is no longer available - as you've 
noticed the current methodology is to set up filter or validator chains and 
pass in an element from $_POST, which of course means you need to run your 
isset() check to avoid the index error. Other possible options are using 
controller methods like Zend_Controller_Request_Http::getPost() which runs an 
isset() check though it's still verbose.

In the future there should be proposals for improved chaining of $_POST so 
there's less individual handling of $_POST elements such as this. I also hope 
it's configurable so I can avoid the setup almost entirely - ;).

Until then however - we're all in the same boat. The new classes are a big 
improvement design wise, so while it's making more work it opens vastly 
superior solutions in the future not possible with Zend_Filter_Input. It should 
be a price well paid for the long term gains.

Paddy
 
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com


- Original Message 
From: Thomas Eriksson <[EMAIL PROTECTED]>
To: fw-general@lists.zend.com
Sent: Wednesday, March 21, 2007 10:29:59 PM
Subject: [fw-general] Question about Zend_Filter_Input




 
 








Hi
 

  
 

What happened with the Zend_Filter_Input functions?
 

  
 

I had this in my bootstrap file (index.php)
 

Zend::register('post', new Zend_Filter_Input($_POST),
false);
 

Zend::register('get', new Zend_Filter_Input($_GET),
false);
 

  
 

And then I used that to filter input made by the user
like this…
 

$imaId = trim($post->noTags('imaId'));
 

  
 

This was really good because if the imaId in the form
that was submitted were an unchecked checkbox I didn’t get an error…
 

  
 

But if I know use…
 

  
 

Zend_Loader::loadClass('Zend_Filter_Striptags');
 

$filterChain = new Zend_Filter();
 

$filterChain->addFilter(new
Zend_Filter_Striptags());
 

$imaId= $filterChain->filter($_POST['imaId']);
 

  
 

I get a error notice out of this…Notice:
undefined index imaId …and so on…
 

  
 

Anybody who can help how to do this without having to
use…isset($_POST[“…”]) everywhere?
 

  
 

Regards
 

/Thomas
 

  
 

  
 










 

Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097

Re: [fw-general] Zend_Filter_Input...

[Pádraic Brady]

In agree with you Simon - if we have too many sources for input
variables, some of which check varying sources in priority it's just
another $_REQUEST situation where these values could conceivably come
from anywhere. It's better practice to use a method which selects
values from a known source on the basis if it comes from anywhere else
unexpectedly it should ring a few alarm bells for the developer. I'd
actually call it first line filtering/validation - if we know a value
should be received via POST then if the same value is retrievable from
GET it should be ignored unless it's for a valid reason. 
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com


- Original Message 
From: Simon R Jones <[EMAIL PROTECTED]>
To: Zend Mailing List 
Sent: Thursday, March 22, 2007 8:13:19 AM
Subject: RE: [fw-general] Zend_Filter_Input...

> You can use $this->_getParam('key', 'default'); in a Controller, because
>  _getParam() use the Request->getParam() method, which tries first to
> load the param from the url, then from $_GET and after this from $_POST.

If $this->_getParam() looks at the URL, GET and POST isn't it a potential
security issue to use it for POST variables since you don't know exactly
where your input variables are coming from?

Seems rather similar to $_REQUEST to me which should also be avoided for
similar reasons - 
http://shiflett.org/articles/ideology

A quick look at the (nicely growing) manual it seems you can do the
following which does the job nicely for POST variables:

$myVar = $this->getPost('name');

(See API docs / Zend_Controller_Request_Http for more)

There do seem to be a lot of methods that return variables from GET, POST,
COOKIE, etc. I think it would be a good idea to mention the security
implications of depending on these in the manual..

Si









 

TV dinner still cooling? 
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/

[fw-general] Feature-Request for Zend_Translate

[Thomas Weidner]

Hy fellows,

a user in the general list had an idea for simplification for 
Zend_Translate.
Background is to increase readability and simplification of Zend_Translate 
by making it possible to autoecho the translation.


Please see related issue ZF-1096.
http://framework.zend.com/issues/browse/ZF-1096

As Zend_Translate is a class which is also used within the view to output 
the translated content this issue would not break the MVC Pattern in my 
opinion.


We would like to collect opinions from others than Alex and me as we have 
different opinions for this issue ;-)


We hope to get enough opinions, to make a decission before 0.9.1 or 0.9.2 to 
have this included or declined before 1.0. So please give us feedback ;-)


Greetings
Thomas
I18N Team Leader 

Re: [fw-general] Wildcards routes and reset parameter

[Martel Valgoerad]

Olivier Sirven wrote:

(...)

I have tried to add the "reset" parameter to true but then I don't have any 
parameter at all, just "/":

echo $this->url(array('key1' => 'newvalue'), 'root', true);

Is it a bug or a feature? 


It's more a bug than a feature. Fixed with commit 4715. Good catch, thanks :)

If this is a feature, is there a way to assemble a wildcard route without 
taking into account the current parameters?


There is another way to reset parameters. You can leave $reset as false but 
pass 'var' => null to assemble if you wish to reset specific url variables only.


--
Martel Valgoerad aka Michal Minicki | [EMAIL PROTECTED] | 
http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything." --
Floyd Dell

Re: [fw-general] How to search multiple phrases using Zend_Search

[Alexander Veremyev]

Hi David,

You have to retrieve text from MS-Word documents by yourself now.

It would be good to have possibility for Word documents indexing, but 
Zend_Search_Lucene can only parse HTML documents - 
http://framework.zend.com/manual/en/zend.search.html#zend.search.index-creation.html-documents



With best regards,
   Alexander Veremyev.

[EMAIL PROTECTED] wrote:

Alexander Veremyev,

Thank you very much. I noticed that in the document of other languages, this 
feature was not mentioned.

And another question. I have a lot of MS Word files, and I need to search 
them(just the text content). How could Zend_Search support this function or 
solve my question in any other way?

Thanks in advance.

David
Linkfirst Solutions,Shanghai
2007-03-22


- Original Message - 
From: "Alexander Veremyev" <[EMAIL PROTECTED]>

To: "Partout" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, March 05, 2007 3:10 PM
Subject: Re: [fw-general] How to search multiple phrases using Zend_Search



Hi,

Yes, it can.

Use:
---
"My cool phrase1" AND "My cool phrase2" AND 
---
or
---
+"My cool phrase1" +"My cool phrase2" 
---
or
---
"My cool phrase1" OR "My cool phrase2" OR 
---
or
---
"My cool phrase1" "My cool phrase2" 
---

Take a look at query language description - 
http://framework.zend.com/manual/en/zend.search.query-language.html



With best regards,
   Alexander Veremyev.


Partout wrote:
I need to get the results by searching several phrases, for example, 
phrase "Software Engineer" and phrase "Telecom Related" both. Could 
Zend_Search support this? And if it couldn't, how could I find the way 
to solve this? Thanks a lot in advance.


View this message in context: How to search multiple phrases using 
Zend_Search 

Sent from the Zend Framework mailing list archive 
 at Nabble.com.

[fw-general] Multiple ControllerDirectory paths

[Werner]

Hi!

I want to specify multiple controller directories that should all be 
searched for controllers. I want to do this without deploying any 
predefined modular directory structures - just multiple paths for 
controllers (whether modules will be used or not).


However, when specifying any additional directory path it seems like the 
first path is overwritten by the last specified path.


E.g, is it possible to make something like this work...?

$controller->throwExceptions(true)
   ->setRouter($router)
   ->setBaseUrl($baseUrl)
   ->setControllerDirectory('/my/first/path') // Default 
directory
   ->addControllerDirectory('/my/second/path') // Another 
directory
   ->addControllerDirectory('/my/third/path'); // Yet 
another directory


Any ideas, hint or tips on how to achieve this?

Thank you for your time,
Werner

Re: [fw-general] Trouble with setControllerDirectory() in 0.9.0Beta

[Werner]

Thanks, Alexander

When switching to modules everything is on track again - your 
suggestions worked, and I could get it running again.


However, I still miss the functionality that 0.8.0 had, which enabled me 
to add multiple directories that will be searched for controllers.


I'm going to start a new thread to address this specific issue, as the 
current issue I was having was solved by using the predefined modular 
structure.


Thank you,
Werner


Alexander Netkachev wrote:



On 3/21/07, *Werner* <[EMAIL PROTECTED] 
> wrote:


Hello, fellow ZF users

I ran into trouble with setControllerDirectory() when switching from
0.8.0 to 0.9.0Beta.

The following worked fine in 0.7.0 to 0.8.0:

$frontController->setControllerDirectory(
array(
'./src/admin/con',
'./src/con'
)
);

$routePageHandler = new Zend_Controller_Router_Route(
':section/:task/:identifier/:subidentifier',
array(
'section'   => 'home',
'task'  => 'view',
'identifier'=> '',
'subidentifier' => '',
'controller'=> 'page',
'action'=> 'index'
)
);
$router->addRoute('*', $routePageHandler);

$routeAdminHandler = new Zend_Controller_Router_Route(
'admin/:section/:task/:identifier/:subidentifier',
array(
'section'   => 'login',
'task'  => 'view',
'identifier'=> '',
'subidentifier' => '',
'controller'=> 'admin',
'action'=> 'admin'
)
);
$router->addRoute('admin', $routeAdminHandler);

$frontController->setRouter($router);
$frontController->dispatch();



I changed the setControllerDirectory params to the following in 0.8.0,
and it still seemed to work:

$frontController->setControllerDirectory(
array(
'default' => './src/con',
'admin'   => './src/admin/con'
)
);



1. The code above specifies that you have two modules 'default' and 
'admin'. So you have controllers of /src/admin/con in admin module. 
That also means that controllers class names should be prefixed with 
Admin_, e.g. Admin_IndexController so please check this.


2. I think that you have the error because $routeAdminHandler does not 
specify a module the request should be passed to. So, the 'default' is 
used, not 'admin'. Just add 'module' => 'admin' to the parameters.



Sincerely,

--
Alexander
http://www.alexatnet.com/ - Blog and CMS created with Zend Framework 
and Ajax. 

Re: [fw-general] [Zend][Controller][Action] unsetParam() and some suggestions

[Matthew Weier O'Phinney]

-- Shekar C Reddy <[EMAIL PROTECTED]> wrote
(on Wednesday, 21 March 2007, 09:34 PM -0400):
> 1. Perhaps, the setParam() method could be enhanced to unset/blow-off the key
> if the value passed is null... We don't want any keys with null values
> lingering around - that would increase complexity as we have to deal with null
> values! I know getParam() returns default null if the key does not exist but
> when I invoke getAllParams() to traverse the array, I may end up with some 
> keys
> that have null values :(  Or maybe, with a third/default $unset argument if 
> the
> value passed is null, like so:
>  
> Signature: _setParam( $key, $value, $unset = false )
> Usage: _setParam( $key, null, true )
>  
> [if $value = null && $unset = true, blow off the key]

Good plan. I'll implement this soon.


> 2. Understandable. I did not request to eliminate the
> getRequest/getResponse methods - they are there to serve as an API to
> external objects. What I was referring to was invoking of these
> methods inside Zend_Controller_Action class script to access the
> protected request/response vars that are declared/defined right inside
> the same class. That would degrade performance (you may try
> load-testing the application). These vars could, instead, be accessed
> directly inside Zend_Controller_Action script:
>  
> Eg: $this->_request->setParam( ... )

The point of accessors is to normalize access to properties. Using the
properties directly within methods such as render(), _forward(), etc.
could cause issues later for those who *do* override the
getRequest()/getResponse() accessors -- basically, we'd be breaking
*other* people's apps.

As a performance optimization, typically what I do is, if needing the
property more than once, I grab it like this:

$request = $this->getRequest();

which will cut down on the number of times it's retrieved by the
accessor. This is the only concession I'll make in this regard.


>  
> On 3/21/07, Matthew Weier O'Phinney <[EMAIL PROTECTED] > wrote:
> 
> -- Shekar C Reddy < [EMAIL PROTECTED]> wrote
> (on Wednesday, 21 March 2007, 06:00 AM -0400):
> > 1. There is no method to unset a param in action controller or its
> request
> > class. We need a unsetParam() method in action/request.
> 
> You can always pass a null to setParam():
> 
>$this->setParam('someKey', null);
> 
> The controller parameters are not really intended to be a general
> purpose storage mechanism; they're primarily for pushing values and
> objects from the front controller down through the controller chain
> (router, dispatcher, action controllers). I personally feel that
> if you're needing something like that, use a Zend_Config object in
> read/write mode and push it in either the registry or as a controller
> param.
> 
> > 2. I see usage of getRequest() and getResponse() methods inside the
> > action class although these vars are sitting right inside the class
> > itself (protected $_request, $_response) that can be accessed directly
> > instead of invoking a method to access them. Accessing them directly
> > inside the action class should improve performance.
> 
> This is true. However, the accessors are there for cases where the
> developer may want to wrap some logic around retrieving these objects --
> perhaps grabbing them from a registry, for instance. That said, when I
> know that there's no such logic in classes I'm using, I access them
> directly from the class properties.
> 
> --
> Matthew Weier O'Phinney
> PHP Developer| [EMAIL PROTECTED]
> Zend - The PHP Company   | http://www.zend.com/
> 
> 

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

Re: [fw-general] How to create a new issue?

[Andries Seutens]

Niko Sams schreef:

Hello,

This may sound stupid, but I can't create a new issue in the
Zend Framework Issue Tracker.

someone else had this problem too:
http://framework.zend.com/wiki/display/ZFDEV/Issue+Tracker+Etiquette?focusedCommentId=19252#comment-19252

I have registered and logged in successfully, but I can't find the
"Create New Issue" link.

this doesn't work either:
http://framework.zend.com/issues/secure/CreateIssue!default.jspa


please help!

niko


  


To report an issue or comment on an existing issue, you must email your 
JIRA account name to [EMAIL PROTECTED], and ask for posting privileges. 
Spammers forced us to use this new approval process.


--
Andries Seutens
http://andries.systray.be


Gecontroleerd op virussen door de JOJO Secure Gateway.

Re: [fw-general] How to create a new issue?

[Tom Staals]

You have to request posting permissions by email use the following link to
mail for permission

http://www.nabble.com/user/SendEmail.jtp?type=post&post=9600436&i=0

Be sure to mention your account name 

cheers
Tom

Niko Sams wrote:
> 
> Hello,
> 
> This may sound stupid, but I can't create a new issue in the
> Zend Framework Issue Tracker.
> 
> someone else had this problem too:
> http://framework.zend.com/wiki/display/ZFDEV/Issue+Tracker+Etiquette?focusedCommentId=19252#comment-19252
> 
> I have registered and logged in successfully, but I can't find the
> "Create New Issue" link.
> 
> this doesn't work either:
> http://framework.zend.com/issues/secure/CreateIssue!default.jspa
> 
> 
> please help!
> 
> niko
> 
> 

-- 
View this message in context: 
http://www.nabble.com/How-to-create-a-new-issue--tf3446224s16154.html#a9610615
Sent from the Zend Framework mailing list archive at Nabble.com.

[fw-general] How to create a new issue?

[Niko Sams]

Hello,

This may sound stupid, but I can't create a new issue in the
Zend Framework Issue Tracker.

someone else had this problem too:
http://framework.zend.com/wiki/display/ZFDEV/Issue+Tracker+Etiquette?focusedCommentId=19252#comment-19252

I have registered and logged in successfully, but I can't find the
"Create New Issue" link.

this doesn't work either:
http://framework.zend.com/issues/secure/CreateIssue!default.jspa


please help!

niko

RE: [fw-general] Zend_Filter_Input...

[Simon R Jones]

> You can use $this->_getParam('key', 'default'); in a Controller, because
>  _getParam() use the Request->getParam() method, which tries first to
> load the param from the url, then from $_GET and after this from $_POST.

If $this->_getParam() looks at the URL, GET and POST isn't it a potential
security issue to use it for POST variables since you don't know exactly
where your input variables are coming from?

Seems rather similar to $_REQUEST to me which should also be avoided for
similar reasons - 
http://shiflett.org/articles/ideology

A quick look at the (nicely growing) manual it seems you can do the
following which does the job nicely for POST variables:

$myVar = $this->getPost('name');

(See API docs / Zend_Controller_Request_Http for more)

There do seem to be a lot of methods that return variables from GET, POST,
COOKIE, etc. I think it would be a good idea to mention the security
implications of depending on these in the manual..

Si