I understand this point of view and I do have sympathy; however, I
fundamentally disagree that chained-method calls represent a data-structure.
This is actually part of my main objection to their inclusion. Data structures
are static representations while method calls are inherently non-static. I
realize, of course, that many use the semantics of either in an interchangeable
way -- but I think that unwise at this level. Never-the-less, Mark makes some
reasonable proposals. Still, the slope is slippery.

BTW, I don't think their are "two types of template designers". I rather think
that there are several ways to structure an application and only some of those
strategies lead to reasonably scalable and abstracted code artifacts.

Anyways, I've written too much on this in too many places. I'll leave this for
others to decide :)

--- Mark Rogers <mark@quarella.co.uk> wrote:

> boots wrote:
> > What I see this as is just another way
> > for application programmers to download complexity into templates so that
> they
> > can reduce the amount of code they have to write to interface with the
> > templates. At least, that's what it looks like from my little pigeon hole..
> >   
> 
> I think there are two types of template designers: those who also wrote 
> the code (and just want to keep the logic separate from the display) and 
> those who didn't. For the latter set (no idea if that's a majority?) I'd 
> be -1 with boots, but for the first lot (of which I'm one) I think there 
> is merit in providing the functionality.
> 
> I do think we should play down its inclusion even if it's made to work. 
> If it is documented then it should have a "please don't do it" note 
> citing the reasons boots has mentioned.
> 
> Ultiimately, where the template designer is familiar with the PHP code 
> behind it, having a separate data structure in the templates from the 
> application causes more problems than it solves, in my experience. When 
> you're switching between template design and coding, it's not 
> unreasonable to expect data structures to be the same in both. Adding 
> extra logic to  simplify the structure for the benefit of a real 
> designer is essential in some cases, and overkill in others.
> 
> -- 
> Mark Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555
> Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG
> 
> -- 
> Smarty Development Mailing List (http://smarty.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs