Here's the problem:

http://framework.zend.com/manual/en/zend.view.html#zend.view.introduction.view

Note the long tags. It's no wonder people are getting confused.

I agree with Matthew's justification and also Jordan's concerns. It just needs 
to be made crystal clear and consistent also consistent in the code examples 
I guess.

Regards,
Mark

On Thursday 20 March 2008 21:11, Jordan Moore wrote:
> My fear is that new PHP developers will see short open tags in the ZF
> documentation, think, "Sweet! That makes things easier!", and start
> using them in all areas of their applications (not just views).
>
> I don't see it being a big problem, as long as...
>
> 1. There's decent explanations in the documentation when/why short
> open tags are used.
> 2. The stream wrapper can be disabled, so I don't take a performance
> hit when I upgrade to 1.5.x. :)
>
> On Thu, Mar 20, 2008 at 1:34 PM, Matthew Weier O'Phinney
>
> <[EMAIL PROTECTED]> wrote:
> > -- Jordan Moore <[EMAIL PROTECTED]> wrote
> >
> >  (on Thursday, 20 March 2008, 01:05 PM -0700):
> > > I just verified that "short_open_tag" is disabled in the
> > >
> >  > "php.ini-recommended" file that is distributed with PHP. I believe
> >  > this is to discourage users from using short open tags in
> >  > redistributable applications to ensure greater compatibility. If logic
> >  > is added to Zend_View that "supports" this functionality, it will be
> >  > promoting something that appears to be considered bad practice. I
> >  > realize that ZF would restrict it to views, but developers/users may
> >  > get in the habit of using short open tags elsewhere.
> >
> >  So, you're advocating for more verbose view scripts, then?
> >
> >  Sorry, had to get the dig in. However, the question is serious. View
> >  scripts should be readable. If you use the same coding standards for
> >  view scripts that we have for the general framework components, they
> >  quickly become unreadable, even in a good IDE/editor with syntax
> >  highlighting.
> >
> >  I personally feel it's not difficult to switch back and forth between
> >  view scripts and regular code -- in part because there is an immediate
> >  *visual* difference when I do so.
> >
> >  I'm *not* recommending that we use short tags everywhere, and am fact
> >  recommending we restrict their usage to view scripts -- the stricter
> >  conventions would continue to apply where they matter most, which is
> >  with the core code. My proposal is that we append the manual to make
> >  this clear, and also to outline the rationale behind it.
> >
> >  Besides the typical rationale about the recommended php.ini settings
> >  (this has been brought up before), and the fact that short tags are not
> >  on by default in all configurations (which I plan to address with a
> >  stream wrapper), what other objections are there to using short tags for
> >  view scripts? I personally feel that these two objections are pedantic
> >  -- being strict for strictness' sake -- and don't focus on
> >  maintainability and readability of the view scripts. But I'm willing to
> >  listen to other arguments.
> >
> >  > On Thu, Mar 20, 2008 at 12:49 PM, Jordan Moore
> >  >
> >  > <[EMAIL PROTECTED]> wrote:
> >  > > Doesn't the recommended php.ini that is distributed with PHP disable
> >  > > short tags?
> >  > >
> >  > >
> >  > >
> >  > >  On Thu, Mar 20, 2008 at 12:28 PM, Matthew Weier O'Phinney
> >  > >
> >  > >  <[EMAIL PROTECTED]> wrote:
> >  > >  > -- Aaron D. Campbell <[EMAIL PROTECTED]> wrote
> >  > >  >
> >  > >  >  (on Thursday, 20 March 2008, 12:06 PM -0700):
> >  > >  > > I'm sure I'll eventually appreciate it.  However, I'm a little
> >  > >  > > frustrated
> >  > >  > >
> >  > >  >  > that I'm going to have to go through and fix all the short
> >  > >  >  > tags to get it working on my servers.
> >  > >  >
> >  > >  >  Add this to your .htaccess:
> >  > >  >
> >  > >  >     php_flag short_open_tag On
> >  > >  >
> >  > >  >  I'm working on a stream wrapper to transparently enable this for
> >  > >  > people who have the flag disabled, but the recommendation will be
> >  > >  > to have this on so that your view scripts will work with optimal
> >  > >  > performance.
> >  > >  >
> >  > >  >  > Ralph Schindler wrote:
> >  > >  >  > > Hello everyone,
> >  > >  >  > >
> >  > >  >  > > I have put together a demo application that showcases some
> >  > >  >  > > features of Zend_Layout and Zend_View Enhancements within
> >  > >  >  > > the MVC environment. If you would like to download, set it
> >  > >  >  > > up and play/browse the code within it, it is located here:
> >  > >  >  > >
> >  > >  >  > > http://framework.zend.com/wiki/display/ZFUSER/Zend_Layout+an
> >  > >  >  > >d+Zend_View+Enhancements+Demo
> >  > >  >  > >
> >  > >  >  > > The demo currently includes ZF version 1.5 and Dojo 1.0.2 in
> >  > >  >  > > the download. So basically, this demo app is pretty self
> >  > >  >  > > contained.  Not alot of setup aside from pointing a doc root
> >  > >  >  > > to its public folder is necessary.
> >  > >  >  > >
> >  > >  >  > > Over the course of the coming weeks, I will be taking the
> >  > >  >  > > time to add more examples (I will increment the version
> >  > >  >  > > number of the download as I do).
> >  > >  >  > >
> >  > >  >  > > If anyone has any feedback, or requests as to what you would
> >  > >  >  > > like to see Demo'ed within it either reply here or add
> >  > >  >  > > comments directly to that page.
> >  > >  >
> >  > >  >  --
> >  > >  >  Matthew Weier O'Phinney
> >  > >  >  PHP Developer            | [EMAIL PROTECTED]
> >  > >  >  Zend - The PHP Company   | http://www.zend.com/
> >  > >
> >  > >  --
> >  > >  Jordan Moore - Creative Director
> >  > >  Sanctus Studios LLC
> >  > >  PO Box 2202
> >  > >  Tacoma, WA 98401
> >  > >  (253) 238-8676
> >  >
> >  > --
> >  > Jordan Moore - Creative Director
> >  > Sanctus Studios LLC
> >  > PO Box 2202
> >  > Tacoma, WA 98401
> >  > (253) 238-8676
> >
> >  --
> >
> >
> > Matthew Weier O'Phinney
> >  PHP Developer            | [EMAIL PROTECTED]
> >  Zend - The PHP Company   | http://www.zend.com/

Reply via email to