Re: [fw-general] Controller and View Question
Another method I use:
I extend the Zend_Controller_Action and put an Intermediate class there,
as you can see from this sample controller.
The inter class contains a toView method, I can then simply assign any
values.
I control all elements in my translation files so product can change
anything through POEdit works really well.
Please comment, would like to know from people within this thread what
is the best method ie speed wise with least overhead.
class Finances_InvoicesController extends Zend_Action
{
// {{{ properties
protected $_view = null;
// }}}
// {{{ __init()
public function init()
{
// Maps to arg 'view' from: $frontController->setParam('view',
$view);
$this->_view = $this->getInvokeArg('view');
}
// }}}
// {{{ indexAction()
/**
* Basically this action acts as the home page.
*
* @access public
* @return object
*/
public function indexAction()
{
// Add items required from the registry
$translate = Zend_Registry::get('translate');
// Add items required from the registry
$config = Zend_Registry::get('config');
// Sort out the SMS Navigation
$finances = new Modules_Finances_Classes_Finances();
if (empty($this->getParam['selfbill'])) {
$table = 'db_tbl_finances_invoices';
$addon = 'invoices';
} else {
$table = 'db_tbl_finances_self_bills';
$addon = 'selfbill';
}
// Add items required from the registry
$db = Zend_Registry::get('DB');
$string = '';
for ($i = 1; $i <= 15; $i++) {
$string .= 'IF (a.qty' . $i . ', a.qty' . $i . ' * a.unit'
. $i . ', 0) + ';
}
$string = rtrim($string, ' + ');
// Query to get the invoices.
$select = $db->select()
->from(array('a' => $config->$table), array('a.code',
'b.company',
'a.sale_date', 'a.paid_date', 'total_net' => '@tn:=' .
$string,
'output_vat' => '@ov:=FORMAT(IF (a.vat_exempt = "0",
(@tn) * 1.175 - @tn, 0), 2)',
'total_gross' => 'FORMAT((@tn) + (@ov), 2)', 'a.status'))
->joinLeft(array('b' => $config->db_tbl_finances_debtors),
'a.debtor_id = b.debtor_id', array())
->order('a.code DESC');
$result = $db->fetchAll($select);
if ($result) {
// Create the options
$options['dataGrid'] = array('perPage' => '50', 'page' =>
$this->_getParam('page'));
$options['fields'] = array(
'code' => 'Code', 'company' => 'Company', 'sale_date' =>
'Sale Date',
'paid_date' => 'Paid Date', 'total_net' => 'Total Net',
'output_vat' => 'Output VAT',
'total_gross' => 'Total Gross', 'status' => 'Status'
);
$options['primary_key'] = array(
'code'
);
// Render the table
$rowSet = parent::tableRender($result, 'HTMLTable', $options);
}
if (is_null($this->_getParam('ajax'))) {
// Render the view
$this->_view->page_title=
$translate->_('financesInvoices_page_title');
$this->_view->h1=
$translate->_('financesInvoices_h1');
$this->_view->title =
$translate->_('financesInvoices_title');
$this->_view->navigation=
$translate->_('financesInvoices_navigation');
$this->_view->feature = $finances->getHeader();
$this->_view->text =
$translate->_('financesInvoices_text') . $rowSet['string'];
$this->_view->template =
$translate->_('financesInvoices_template');
$this->_view->template_span =
$translate->_('financesInvoices_template_span');
// Render the view
parent::toView($this->_view);
} else {
echo $rowSet['string'];
}
}
// }}}
// {{{ __call()
/**
* Method to redirect the page if a dodgy action is put into this
controller
*
* @param string $action
* @param string $arguments
* @return string
*/
public function __call($action, $arguments)
{
$this->_redirect('/finances');
}
// }}}
}
Arnaud Limbourg wrote:
Matthew Weier O'Phinney wrote:
I throw a Zend_View object in the registry, and then access this from my
controllers and plugins. The benefit of doing this is that the
controllers can set values in the view that are unused in their
individual view, but used later in the sitewide template.
Then, I use a dispatchLoopShutdown() plugin to inject any generated
content into a sitwide template:
class SiteTemplatePlugin extends Zend_Controller_Plugin_Abstract
{
public function dispatchLoopShutdown()
{
$response =
Zend_Controller_Front:;getInstance()->getResponse();
$view = Zend_Registry
Re: [fw-general] Controller and View Question
Matthew Weier O'Phinney wrote:
I throw a Zend_View object in the registry, and then access this from my
controllers and plugins. The benefit of doing this is that the
controllers can set values in the view that are unused in their
individual view, but used later in the sitewide template.
Then, I use a dispatchLoopShutdown() plugin to inject any generated
content into a sitwide template:
class SiteTemplatePlugin extends Zend_Controller_Plugin_Abstract
{
public function dispatchLoopShutdown()
{
$response = Zend_Controller_Front:;getInstance()->getResponse();
$view = Zend_Registry::get('view');
$view->content = $response->getBody();
$response->setBody($view->render('site.phtml'));
}
}
Which poses a problem when you want to send back json (or whatever) and
you don't want a site wide template :)
Arnaud.
Re: [fw-general] Controller and View Question
-- frederic wolf <[EMAIL PROTECTED]> wrote
(on Sunday, 25 March 2007, 11:31 PM +0200):
> Matthew Weier O'Phinney a écrit :
> > -- Ralph Schindler <[EMAIL PROTECTED]> wrote
> > (on Sunday, 25 March 2007, 09:37 AM -0500):
> >
> > > I am curious how everyone implements common headers and footers
> > > within a given application. As I see it there are two methods:
> > >
> > > a) include the header and footer in each view script via the
> > > $this->render(..) routine.
> > >
> > > b) use Zend_Controller Plugins to write to the view a standard header
> > > and footer to the view body at preDispatch() postDispatch() /
> > > preRouteStartup / postRouteStartup times.
> > >
> > > Both methods have their pros and cons..
> > >
> > > In method a) you are required to handle it in every script, which can be
> > > tedious. But it allows you flexibility to not include the common header
> > > and footer blanketly on all requests when it makes sense not to include
> > > it.
> > >
> > > Method b) writes headers and footers on all requests, unless I am
> > > missing something. The benefit is that you can write specific
> > > controller/action scripts and they can be completely autonomous from the
> > > rest of the application.
> > >
> > > I like method b), but I wonder: Are there ways to inject (or callback)
> > > to write specific controller/action needed headers to the common header,
> > > for example, adding a page specific JS script to a pages . Are
> > > there ways that a specific controller/action can choose not to use a
> > > header/footer dispatched previously?
> > >
> >
> > I throw a Zend_View object in the registry, and then access this from my
> > controllers and plugins. The benefit of doing this is that the
> > controllers can set values in the view that are unused in their
> > individual view, but used later in the sitewide template.
> >
> > Then, I use a dispatchLoopShutdown() plugin to inject any generated
> > content into a sitwide template:
> >
> >
> >class SiteTemplatePlugin extends Zend_Controller_Plugin_Abstract
> >{
> >public function dispatchLoopShutdown()
> >{
> >$response =
> >Zend_Controller_Front:;getInstance()->getResponse();
> >$view = Zend_Registry::get('view');
> >$view->content = $response->getBody();
> >$response->setBody($view->render('site.phtml'));
> >}
> >}
> >
> > Any other variables you've set in your template object to this point are
> > also available, not just $content. As a result, you could in your action
> > controllers specify additional values:
> >
> >public function formAction()
> >{
> >// Set the sitewide template's $pageTitle element
> >$this->view->pageTitle = 'Login Form';
> >
> >$this->render();
> >}
> >
> > By doing the sitewide template at the end, instead of doing a header in
> > the preDispatch() and footer in the postDispatch(), you can affect the
> > entire layout of the page, and also chain together several actions to
> > build the final page.
> >
> >
> Is it possible to imagine to throw a Zend_View object in the Response
> object instead of the registry. The view object would still available in
> the controllers.
> What do you think ?
> I don't even know why I would like to not throw the view object in the
> registry, :) but may be it could be easier to combine data content,
> vairaibles and templates if the view object and the response one
> are tied together.
You're free to extend the response object to do exactly this. :-)
Truly, though -- I've done this in a project once already, and there are
some definite benefits to doing so -- the response object is already
available in the action controllers as well as in the plugins (plugins
have both the request and response objects registered within them), and
you can then do some fairly easy context switching.
The reason I haven't proposed doing so for the default response object
is that it typically also adds a ton of complexity to the response
object, and tightly couples the view and response objects.
Another alternative to using the registry is to pass the view object
through as a front controller param:
$front->setParam('view', $view);
You can then access it in your action controllers:
$view = $this->_getInvokeParam('view');
or via the front controller singleton:
$view = Zend_Controller_Front::getInstance()->getParam('view');
Basically, there are a variety of mechanisms at your disposal -- choose
whatever works best for your project.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] DB Select
Thanks Bill
I am using PEAR structures - so I throw the results straight into that,
and hence keeping the column order is important to save on overhead of
code used in Structures, I am now ordering in this now.
Cheers
Ian
Bill Karwin wrote:
Currently Zend_Db_Select sorts columns by the correlation name as it
builds the query. I can log a feature request to preserve the column
order, and we'll try fixing it at some later time.
But I need to give the disclaimer that I would not choose to prioritize
this change very high, relative to other improvements to Zend_Db we need
to do. Since the result set of a query is usually returned as an
associative array anyway, the difference of column-order is pretty
trivial.
If you have specific needs that are not satisfied by Zend_Db_Select, the
workaround I can offer right away is that you can put SQL into a string
manually, and execute it with the query() method.
Regards,
Bill Karwin
-Original Message-
From: Ian Warner [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 25, 2007 11:17 AM
To: Zend Framework
Subject: [fw-general] DB Select
Hi
I want to select the following in the following column order:
$select = $db->select()
->from(array('a' => $config->$table), array('a.code',
'b.company', 'a.sale_date'))
->joinLeft(array('b' =>
$config->db_tbl_finances_debtors),
'a.debtor_id = b.debtor_id', array())
->order('a.code DESC');
When th SQL is generated I get this:
[_query:protected] => SELECT
`a`.`code`,
`a`.`sale_date`,
`b`.`company`
FROM `finances_invoices` AS `a`
LEFT JOIN `finances_debtors` AS `b` ON a.debtor_id = b.debtor_id
ORDER BY
`a`.`code` DESC
It has reordered the Columns!!
How do I stop this doing this behaviour.
Cheers
Ian
RE: [fw-general] DB Select
Feature request logged: http://framework.zend.com/issues/browse/ZF-1135 Regards, Bill Karwin > -Original Message- > From: Bill Karwin [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 25, 2007 2:29 PM > To: Zend Framework > Subject: RE: [fw-general] DB Select > > Currently Zend_Db_Select sorts columns by the correlation name as it > builds the query. I can log a feature request to preserve the column > order, and we'll try fixing it at some later time.
Re: [fw-general] Controller and View Question
Matthew Weier O'Phinney a écrit :
-- Ralph Schindler <[EMAIL PROTECTED]> wrote
(on Sunday, 25 March 2007, 09:37 AM -0500):
I am curious how everyone implements common headers and footers
within a given application. As I see it there are two methods:
a) include the header and footer in each view script via the
$this->render(..) routine.
b) use Zend_Controller Plugins to write to the view a standard header
and footer to the view body at preDispatch() postDispatch() /
preRouteStartup / postRouteStartup times.
Both methods have their pros and cons..
In method a) you are required to handle it in every script, which can be
tedious. But it allows you flexibility to not include the common header
and footer blanketly on all requests when it makes sense not to include it.
Method b) writes headers and footers on all requests, unless I am
missing something. The benefit is that you can write specific
controller/action scripts and they can be completely autonomous from the
rest of the application.
I like method b), but I wonder: Are there ways to inject (or callback)
to write specific controller/action needed headers to the common header,
for example, adding a page specific JS script to a pages . Are
there ways that a specific controller/action can choose not to use a
header/footer dispatched previously?
I throw a Zend_View object in the registry, and then access this from my
controllers and plugins. The benefit of doing this is that the
controllers can set values in the view that are unused in their
individual view, but used later in the sitewide template.
Then, I use a dispatchLoopShutdown() plugin to inject any generated
content into a sitwide template:
class SiteTemplatePlugin extends Zend_Controller_Plugin_Abstract
{
public function dispatchLoopShutdown()
{
$response = Zend_Controller_Front:;getInstance()->getResponse();
$view = Zend_Registry::get('view');
$view->content = $response->getBody();
$response->setBody($view->render('site.phtml'));
}
}
Any other variables you've set in your template object to this point are
also available, not just $content. As a result, you could in your action
controllers specify additional values:
public function formAction()
{
// Set the sitewide template's $pageTitle element
$this->view->pageTitle = 'Login Form';
$this->render();
}
By doing the sitewide template at the end, instead of doing a header in
the preDispatch() and footer in the postDispatch(), you can affect the
entire layout of the page, and also chain together several actions to
build the final page.
Is it possible to imagine to throw a Zend_View object in the Response
object instead of the registry. The view object would still available in
the controllers.
What do you think ?
I don't even know why I would like to not throw the view object in the
registry, :) but may be it could be easier to combine data content,
vairaibles and templates if the view object and the response one
are tied together.
RE: [fw-general] DB Select
Currently Zend_Db_Select sorts columns by the correlation name as it
builds the query. I can log a feature request to preserve the column
order, and we'll try fixing it at some later time.
But I need to give the disclaimer that I would not choose to prioritize
this change very high, relative to other improvements to Zend_Db we need
to do. Since the result set of a query is usually returned as an
associative array anyway, the difference of column-order is pretty
trivial.
If you have specific needs that are not satisfied by Zend_Db_Select, the
workaround I can offer right away is that you can put SQL into a string
manually, and execute it with the query() method.
Regards,
Bill Karwin
> -Original Message-
> From: Ian Warner [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 25, 2007 11:17 AM
> To: Zend Framework
> Subject: [fw-general] DB Select
>
> Hi
>
> I want to select the following in the following column order:
>
> $select = $db->select()
> ->from(array('a' => $config->$table), array('a.code',
> 'b.company', 'a.sale_date'))
> ->joinLeft(array('b' =>
$config->db_tbl_finances_debtors),
> 'a.debtor_id = b.debtor_id', array())
> ->order('a.code DESC');
>
>
> When th SQL is generated I get this:
>
> [_query:protected] => SELECT
> `a`.`code`,
> `a`.`sale_date`,
> `b`.`company`
> FROM `finances_invoices` AS `a`
> LEFT JOIN `finances_debtors` AS `b` ON a.debtor_id = b.debtor_id
> ORDER BY
> `a`.`code` DESC
>
>
> It has reordered the Columns!!
>
> How do I stop this doing this behaviour.
>
> Cheers
>
> Ian
RE: [fw-general] Use magic methods in Db_Table relationships
I implemented both magic and non-magic methods (the former simply calls
the latter). I knew that there was demand for the magic methods. But
it's totally optional, and in most cases it is merely a matter of
preference.
Here are some considerations for using the magic vs. non-magic methods:
- Some people like the readability of magic methods; they are somewhat
Rails-like.
- There is slightly more overhead to using the magic methods. It's
pretty small though, just a couple of calls to preg_match() and then a
function call to the appropriate non-magic method.
- The non-magic methods accepts a Table object, as alternative to a
string naming the Table class. Sometimes this could be convenient.
- Editors that perform code-completion have a hard time guessing at
magic methods or magic properties. If you prefer to use
code-completion, then you should use the non-magic methods.
- If you choose rule keys in the $_referenceMap containing characters
that are illegal to use in a PHP method name, you can't use the rule
keys in magic method calls, but you can still use them in non-magic
methods. Example:
class MyTable extends Zend_Db_Table_Abstract
{
protected $_referenceMap = array(
'The Rule' => array( ... )
);
}
$parentRow->findDependentRowset('MyTable', 'The Rule'); // works
$parentRow->findMyTableByThe Rule(); // doesn't work
A rule key with a space in it, like 'the rule' above, doesn't work well
when you try to use it in a magic method. If you want to use magic
methods, name your rule keys using only characters that are legal for
normal PHP method names.
Regards,
Bill Karwin
> -Original Message-
> From: Troy Marker [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 25, 2007 9:10 AM
> To: fw-general@lists.zend.com
> Subject: [fw-general] Use magic methods in Db_Table relationships
>
> I am trying to wrap my head around the new relationship function in
> Db_Table. They are a welcome addition.
>
> My question is what is better. Calling the relation normally or by
using
> the magic functions. I feel there is more overhead in the magic
> function, as they need to determine what rules to apply.
>
> I can see merit in both ways. I was just wondering what other people
> thougut/do.
>
> Thanks for the input.
>
> Regards,
> Troy
Re: [fw-general] User authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 José de Menezes Soares Neto wrote: > Ok, thanks very much for both of you! > Its like Alan said, I need this. > > You know some tutorial to do it in the best way? Cause I was thinking... > If I create some new functions for the application, re-arrange things > will be bad :( > Whilst not necessarily "the best way", you might find http://akrabat.com/zend-auth-tutorial/ useful as a starting point. Regards, Rob... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGBtUi421+qn4cITwRAoViAJ453UEVUEgdcLVDHZ/6Xf9gB6TvgACfTtja b5qsjTQF/oy6NXtBEqYOwRs= =RN+o -END PGP SIGNATURE-
Re: [fw-general] Controller and View Question
-- Ralph Schindler <[EMAIL PROTECTED]> wrote
(on Sunday, 25 March 2007, 09:37 AM -0500):
> I am curious how everyone implements common headers and footers
> within a given application. As I see it there are two methods:
>
> a) include the header and footer in each view script via the
> $this->render(..) routine.
>
> b) use Zend_Controller Plugins to write to the view a standard header
> and footer to the view body at preDispatch() postDispatch() /
> preRouteStartup / postRouteStartup times.
>
> Both methods have their pros and cons..
>
> In method a) you are required to handle it in every script, which can be
> tedious. But it allows you flexibility to not include the common header
> and footer blanketly on all requests when it makes sense not to include it.
>
> Method b) writes headers and footers on all requests, unless I am
> missing something. The benefit is that you can write specific
> controller/action scripts and they can be completely autonomous from the
> rest of the application.
>
> I like method b), but I wonder: Are there ways to inject (or callback)
> to write specific controller/action needed headers to the common header,
> for example, adding a page specific JS script to a pages . Are
> there ways that a specific controller/action can choose not to use a
> header/footer dispatched previously?
I throw a Zend_View object in the registry, and then access this from my
controllers and plugins. The benefit of doing this is that the
controllers can set values in the view that are unused in their
individual view, but used later in the sitewide template.
Then, I use a dispatchLoopShutdown() plugin to inject any generated
content into a sitwide template:
class SiteTemplatePlugin extends Zend_Controller_Plugin_Abstract
{
public function dispatchLoopShutdown()
{
$response = Zend_Controller_Front:;getInstance()->getResponse();
$view = Zend_Registry::get('view');
$view->content = $response->getBody();
$response->setBody($view->render('site.phtml'));
}
}
Any other variables you've set in your template object to this point are
also available, not just $content. As a result, you could in your action
controllers specify additional values:
public function formAction()
{
// Set the sitewide template's $pageTitle element
$this->view->pageTitle = 'Login Form';
$this->render();
}
By doing the sitewide template at the end, instead of doing a header in
the preDispatch() and footer in the postDispatch(), you can affect the
entire layout of the page, and also chain together several actions to
build the final page.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Zend_Filter_Input...
Chris, I was clearly not arguing in favor of ignorance, or that it's a valid method of security. Please re-read my messages. -Matt - Original Message - From: "Chris Shiflett" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Zend Framework General" Sent: Sunday, March 25, 2007 7:31 AM Subject: Re: [fw-general] Zend_Filter_Input... Matthew Ratzloff wrote: 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. The idea that ignorance promotes security is fundamentally flawed. Pádraic clearly understands the risks associated with this perspective. In addition, this approach works against the HTTP spec, eroding the important distinction between GET and POST requests. Chris
Re: [fw-general] User authentication
Ok, thanks very much for both of you! Its like Alan said, I need this. You know some tutorial to do it in the best way? Cause I was thinking... If I create some new functions for the application, re-arrange things will be bad :( Best regardos! - Original Message - From: Alan Wagstaff To: José de Menezes Soares Neto Cc: fw-general@lists.zend.com Sent: Sunday, March 25, 2007 3:40 PM Subject: Re: [fw-general] User authentication Hi, Take a look at Zend_Auth (lets users login/logout) and Zend_ACL (restricts what users can get access to). These 2 combined should do what you need. Thanks, Alan. On 25/03/07, José de Menezes Soares Neto <[EMAIL PROTECTED]> wrote: Hi again friends, I would like to start an application if protected parts. Some users can do some functions and others don´t. With ZF, this is more easier? where I can found about this? Um forte abraço, José de Menezes -- Kind regards, Alan.
Re: [fw-general] User authentication
Hi, Take a look at Zend_Auth (lets users login/logout) and Zend_ACL (restricts what users can get access to). These 2 combined should do what you need. Thanks, Alan. On 25/03/07, José de Menezes Soares Neto <[EMAIL PROTECTED]> wrote: Hi again friends, I would like to start an application if protected parts. Some users can do some functions and others don´t. With ZF, this is more easier? where I can found about this? Um forte abraço, José de Menezes -- Kind regards, Alan.
[fw-general] DB Select
Hi
I want to select the following in the following column order:
$select = $db->select()
->from(array('a' => $config->$table), array('a.code',
'b.company', 'a.sale_date'))
->joinLeft(array('b' => $config->db_tbl_finances_debtors),
'a.debtor_id = b.debtor_id', array())
->order('a.code DESC');
When th SQL is generated I get this:
[_query:protected] => SELECT
`a`.`code`,
`a`.`sale_date`,
`b`.`company`
FROM `finances_invoices` AS `a`
LEFT JOIN `finances_debtors` AS `b` ON a.debtor_id = b.debtor_id
ORDER BY
`a`.`code` DESC
It has reordered the Columns!!
How do I stop this doing this behaviour.
Cheers
Ian
RE: [fw-general] Controller and View Question
Hi
We're using some different "views" to get a useful layout for each purpose.
We start using:
- portal-layout.php
- clean-layout.php
The first one has the header, footer, top menu, the main content and
optionally the left and right menus.
The clean layout only has the header and footer.
So, in our scripts we can do the following (extending the Zend_View
component):
$view = new TemplateView();
$view->tplMain = 'articles/view.php';
$view->tplLeft = 'articles/leftMenu.php';
$view->tplRight = 'articles/contextual.php';
$view->articles = $oArticles->get();
$view->render('portal-layout.php');
The "portal-layout.php" is constructed this way:
$this->render('header.php');
$this->render('topMenu.php');
if(isset($this->tplLeft))
$this->render($this->tplLeft);
$this->render($this->tplMain);
if(isset($this->tplRight))
$this->render($this->tplRight);
$this->render('footer.php');
More or less...
Xavier Vidal Piera
Enginyer Tècnic d'Informàtica de Gestió
Tècnic Especialista en Informàtica de Sistemes
[EMAIL PROTECTED]
610 68 41 78
http://www.webpersonal.net/redness
http://www.myspace.com/xaviervidalmusic
> -Mensaje original-
> De: Ian Warner [mailto:[EMAIL PROTECTED]
> Enviado el: domingo, 25 de marzo de 2007 18:08
> Para: Ralph Schindler
> CC: Zend Framework General
> Asunto: Re: [fw-general] Controller and View Question
>
> Ralph Schindler wrote:
> > Hey group,
> > I am curious how everyone implements common headers and footers
> > within a given application. As I see it there are two methods:
> >
> > a) include the header and footer in each view script via the
> > $this->render(..) routine.
>
> I simply within the main site view call in the following files:
>
> render('../themes/' . $this->theme_template .
> '/html/html_head.inc.php') ?>
>
> echo $this->render($this->actionTemplate);
>
> This allows the view to specify the template and the template
> elements are called via the theme.
>
> >
> > b) use Zend_Controller Plugins to write to the view a
> standard header
> > and footer to the view body at preDispatch() postDispatch() /
> > preRouteStartup / postRouteStartup times.
> >
> > Both methods have their pros and cons..
> >
> > In method a) you are required to handle it in every script,
> which can
> > be tedious. But it allows you flexibility to not include
> the common
> > header and footer blanketly on all requests when it makes
> sense not to include it.
> >
> > Method b) writes headers and footers on all requests, unless I am
> > missing something. The benefit is that you can write specific
> > controller/action scripts and they can be completely
> autonomous from
> > the rest of the application.
> >
> > I like method b), but I wonder: Are there ways to inject (or
> > callback) to write specific controller/action needed headers to the
> > common header, for example, adding a page specific JS script to a
> > pages . Are there ways that a specific controller/action can
> > choose not to use a header/footer dispatched previously?
> >
> > Looking for best practices / ideas here..
> >
> > Thanks,
> > Ralph
> >
> >
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.17/732 - Release
> Date: 24/03/2007 16:36
>
>
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.17/732 - Release Date: 24/03/2007
16:36
[fw-general] User authentication
Hi again friends, I would like to start an application if protected parts. Some users can do some functions and others don´t. With ZF, this is more easier? where I can found about this? Um forte abraço, José de Menezes
[fw-general] Zend_Session - feature request or help
Hello all, I am porting our company's framework to the Zend Framework, and I was looking into Zend Session, while I noticed that it would be very usefull to have some sort of ::setFrom() method. Take the following scenario: --- $permissionNamespace = new Zend_Session_Namespace($config->namespace->permissions); $priveledges = $userModel->getPermissions(); --- Currently, i see no convenience way for getting $priveledges in the $permissionNamespace, unless I am missing something? Having a ::setFrom() method, which takes an array as input, would solve this by doing: --- $permissionNamespace = new Zend_Session_Namespace($config->namespace->permissions); $priveledges = $userModel->getPermissions(); $permissionNamespace->setFrom($priveledges); var_dump($permissionNamespace->controller->action)); --- What do you guys think? Best, Andries
[fw-general] Use magic methods in Db_Table relationships
I am trying to wrap my head around the new relationship function in Db_Table. They are a welcome addition. My question is what is better. Calling the relation normally or by using the magic functions. I feel there is more overhead in the magic function, as they need to determine what rules to apply. I can see merit in both ways. I was just wondering what other people thougut/do. Thanks for the input. Regards, Troy
Re: [fw-general] Controller and View Question
Ralph Schindler wrote:
Hey group,
I am curious how everyone implements common headers and footers within
a given application. As I see it there are two methods:
a) include the header and footer in each view script via the
$this->render(..) routine.
I simply within the main site view call in the following files:
render('../themes/' . $this->theme_template .
'/html/html_head.inc.php') ?>
echo $this->render($this->actionTemplate);
This allows the view to specify the template and the template elements
are called via the theme.
b) use Zend_Controller Plugins to write to the view a standard header
and footer to the view body at preDispatch() postDispatch() /
preRouteStartup / postRouteStartup times.
Both methods have their pros and cons..
In method a) you are required to handle it in every script, which can be
tedious. But it allows you flexibility to not include the common header
and footer blanketly on all requests when it makes sense not to include it.
Method b) writes headers and footers on all requests, unless I am
missing something. The benefit is that you can write specific
controller/action scripts and they can be completely autonomous from the
rest of the application.
I like method b), but I wonder: Are there ways to inject (or callback)
to write specific controller/action needed headers to the common header,
for example, adding a page specific JS script to a pages . Are
there ways that a specific controller/action can choose not to use a
header/footer dispatched previously?
Looking for best practices / ideas here..
Thanks,
Ralph
Re: [fw-general] Zend_Filter_Input...
Chris Shiflett wrote: The idea that ignorance promotes security is fundamentally flawed. Pádraic clearly understands the risks associated with this perspective. In addition, this approach works against the HTTP spec, eroding the important distinction between GET and POST requests. Thats a bit loaded :) I would consider the web in general to be the eroder of GET and POST as the current web browers do not make it easy for developers to easily make truly RESTful applications for browsers. From my (albeit limited) knowledge, ZF is not RESTful and I am not sure if its a goal. Currently (across the web), we simulate PUT and DELETE by loading variables into our GET and POST, which, I can only imagine is one reason why you might see Get/Post variables accessible via the get/setParam utilities.. so that we can further simulate a RESTful architecture via a modern browser with so easily implements GET/POST. On the subject of Filtering, I did like the previous method of pulling directly from source $input = new Zend_Filter_Input($_POST/$_GET).. But I am interested to see what the future plans have in store for us. But, then again, I haven't written an HTTP Developers Handbook ;) -ralph
[fw-general] Controller and View Question
Hey group, I am curious how everyone implements common headers and footers within a given application. As I see it there are two methods: a) include the header and footer in each view script via the $this->render(..) routine. b) use Zend_Controller Plugins to write to the view a standard header and footer to the view body at preDispatch() postDispatch() / preRouteStartup / postRouteStartup times. Both methods have their pros and cons.. In method a) you are required to handle it in every script, which can be tedious. But it allows you flexibility to not include the common header and footer blanketly on all requests when it makes sense not to include it. Method b) writes headers and footers on all requests, unless I am missing something. The benefit is that you can write specific controller/action scripts and they can be completely autonomous from the rest of the application. I like method b), but I wonder: Are there ways to inject (or callback) to write specific controller/action needed headers to the common header, for example, adding a page specific JS script to a pages . Are there ways that a specific controller/action can choose not to use a header/footer dispatched previously? Looking for best practices / ideas here.. Thanks, Ralph
Re: [fw-general] Zend_Filter_Input...
Matthew Ratzloff wrote: > 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. The idea that ignorance promotes security is fundamentally flawed. Pádraic clearly understands the risks associated with this perspective. In addition, this approach works against the HTTP spec, eroding the important distinction between GET and POST requests. Chris
[fw-general] Unit Testing Actions/Views
Inspired by Alexander Netkachev's unit testing article:
http://www.alexatnet.com/blog/2/2007/03/20/automatic-testing-of-mvc-
applications-created-with-zend-framework
I've been trying out some methods of testing actions/views and
finding myself unable to get Alex's method to work I tried another
approach:
public function testIndexAction()
{
$client = new Zend_Http_Client( 'http://site.com/hello-world/' );
$response = $client->request();
$this->assertContains('Hello World', $response->getBody());
}
The simplicity of this is very satisfying and I was wondering of the
pros and cons between the above and kind of approach that Alex
mentions and I've seen mentioned on this list:
public function testIndexAction()
{
$front = Zend_Controller_Front::getInstance();
$request = new Zend_Controller_Request_Http( 'http://site.com/
hello-world/' );
$front->dispatch( $request );
$response = $front->getResponse();
$this->assertContains('Hello World', $response->getBody());
}
Note the above (as well as slight variations of) was not working in
my tests. I probably need to set up a bit more thoroughly, however,
that fact in itself makes me like the first variation even more as
the fact that it works with so little setup does make it less fragile.
Anyway, I was just wondering then what the pros and cons of these
methods are and/or if there are any other approaches worth considering.
Thanks (and to Alex in particular for getting me thinking about this),
Nick
