Just to clarify,
Any templating solution will allow arbitrary logic - so it doesn't limit logic
at all. Zend_View allows the full use of PHP, Smarty just conceals that with
miscellaneous tags but the presence of {if} is all it takes to allow for logic
duplication ;). Both however allow for encapsulating reusable presentational
logic in View Helpers. Smarty does allow View Helpers (keep meaning to blog a
tutorial) by writing new plugin functions to catch such logic for reuse. It's
quite a simple exercise to write a Model reading plugin for Smarty using a tag
syntax like:
{model class="FeedSubscriberCache" rss="http://www.php.net/news.rss"; count="5"}
Which relies on a Model in use for storing cached RSS/Atom feeds
(Subscriber/Publisher setup using cron to download and cache feeds every hour
for example) to select and return the last 5 news headlines for php.net (the
URI is a primary key). The class file for this is pretty straightforward. The
Model is already existing using Zend_Db or something else.
The only truly evil logic is when domain logic finds it's way into a template.
The moment a template starts interpreting data (e.g. a bank balance is negative
therefore it should be highlighted red says a template) is when it's crossed
the line. The Model should tell the View if a balance is red worthy...;). Maybe
the Model only differentiates between authorised and unauthorised overdrafts...
Both are negatives, only one should be highlighted red!
Pádraic
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com
----- Original Message ----
From: James Andrews <[EMAIL PROTECTED]>
To: Gunter Sammet <[EMAIL PROTECTED]>
Cc: fw-general@lists.zend.com
Sent: Wednesday, May 30, 2007 1:00:49 AM
Subject: Re: [fw-general] Really complications Zend_Controller is purpose ZF?
Isn't using Smarty on top of MVC kind of counter intuitive. You should be
using one or the other, not both. Any template engine that has logic in it is
pointless the entire idea is that you do all your logic in the php and then the
template engine should just displays the results. Then again I am quite anti
smarty. (sorry big pet peeve of mine.)
James
On May 29, 2007, at 7:02 PM, Gunter Sammet wrote:
Matthew, thank you for your hard work and prompt responses. Here a few lines on
my experience so far:
I am pretty new to ZF and MVC. On top of that I want to implement Smarty as the
template engine. Been spending a few days on reading the documentation, what I
could find on the Internet and playing around with the zfdemo code. Still don't
get the whole picture but it makes more and more sense. Figure it will take me
another few days of playing around to understand it a bit more.
Managed to get some views working through piecing together code pieces from
several tutorials and the zfdemo app. I followed the emails in the last few
weeks, so I knew that there were some changes that are not compatible. That's
why I upgraded today to 1.0.
This broke my setup with the Smarty view, injecting templates out of a template
directory. Since I am still not very proficient in debugging the ZF and I had
$frontController->throwExceptions(true) set, I didn't get the error message
that it didn't find 'index/index.phtml'. It took me a few hours to figure it
out and I am thinking about my potential new structure.
Besides the above, I had to change my smarty view to use "extends
Zend_View_Abstract" instead of "implements Zend_View_Interface" which required
me to declare the "_run" method.
For now till I have my new template structure, I managed to bypass the auto
view settings by using the following lines of code;
$viewRenderer = new
Zend_Controller_Action_Helper_ViewRenderer($view);
$viewRenderer->setViewBasePathSpec($tmplPath)
->setViewScriptPathSpec('landing.tpl')
->setViewScriptPathNoControllerSpec(' landing.tpl')
->setViewSuffix('tpl');
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
//Zend_View_Controller_HelperBroker::addHelper($viewRenderer);
NOTE:
=====
-->The sample code at
http://framework.zend.com/manual/en/zend.controller.actionhelpers.html#zend.controller.actionhelpers.viewrenderer
(paragraph 7.9) wants you to implement
Zend_View_Controller_HelperBroker::addHelper($viewRenderer);. However, I didn't
find a HelperBroker there. Seems to be the Zend_Controller_Action_HelperBroker
that is meant there.
Your changes make sense and should make the default setup easier. I will try to
implement it as close as possible to be open for future refactoring. That's why
I didn't use the
$front->setParam
('noErrorHandler', true);
If I understand it correctly, that should have solved my problem without
changes. A good read for it is the migration page (
http://framework.zend.com/manual/en/zend.controller.migration.html#zend.controller.migration.fromzeroninethree)
Hope these lines help some other users to figure it out a bit earlier and for
you to understand the issues ZF newbies may face.
Gunter
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
