Re: [SMARTY] Calling object methods

boots wrote:
> --- Jochem Maas <[email protected]> wrote:
> 
>>boots wrote:
>>
>>>To be fair, it was never claimed that Smarty WAS PHP. The fact that
>>>something is possible in PHP is no gaurantee that it will be
>>>possible in Smarty; however, the fact that something ISN'T possible
>>>in PHP is often indicative that it won't be doable in Smarty. Ergo 
>>>the PHP4 argument. The PHP5 sarcasm is rather unfair.
>>
>>yes but the fact that hardly anyone of the 'big' open php projects
>>show any/much interest in going php5 is not exactly a come-on for the
>>general public is it?
> 
> 
> Hi.
> 
> There is much interest in going towards PHP5. Several of my client
> projects have already migrated yet amazingly, this feature or lack
> thereof has not detered that. As Monte said, Smarty is already largely
> compatible with PHP5. Instead of trying to bolt the final pieces on to

you are correct, my point was more a general feeling that php5's specific
'benefits' (in terms of new feature) are largely being ignored.
this is actually understandable considering existing codebases (and the effort
required to refactor).

> the old codebase there are tenative plans to rewrite for PHP5 to
> achieve not only compatability but also to leverage the new features.

look forward to hearing/seeing more if/when time allows it.

> 
> 
>>IMHO php5 is really so much of an improvement and it deserves more
>>support  so that feetdragging ISPs start to actually offer it!!!
> 
> 
> This has nothing to do with Smarty.

true, but 1 high profile php project 'going for it' does hurt. :-)

> 
> 
>>in what way does being able to write {$foo->bar()->bar()} break BC?
>>maybe it's obvious but I don't see it. maybe its an implementation
>>problem, (I have hacked Smarty for this very issue so I understand 
>>that this is not a simple issue per se!)
> 
> 
> $foo->bar()->bar() doesn't work under PHP4 unless you use intermediates
> to handle to function derefrencing.
> 
> 
>>>candidate for a future version but at the same time, I think it
>>>will promote several questionable practices for template usage
> 
> (such 
> 
>>>as deeply nested hierarchies).
>>
>>I don't understand what you mean by 'deeply nested hierarchies' in
>>this context - could you explain please?
> 
> 
> A 'deeply nested hierarchy' is one where one must drill down several
> layers to get to required attributes/properties (or even methods).
> There is much debate on the merit of such designs in ANY context, but

{$app->getUser()->getName()} is not difficult to understand. not
everyone has to use it, shops that have 'unskilled' (in terms of php/etc)
designers can just do ti the way they have always done it.

> they are particularly objectionable in my view for template users.

may I, as a template user, and developer handing out templates to others,
be the judge of that as far as my work is concerned? ;-)

> Template users need to know the least about application design and
> structure. Their job is to match design to placeholders so that the
> application can fill in the details. If it is unneccessarily difficult
> for them to specificy the placeholders or if they must learn deep
> issues regarding the application structure their job (and
> effectiveness) is compromised. The main reason I see for this happening
> is that application objects are passed wholesale into templates instead
> of being decomposed into "friendlier" (ie. flatter) interfaces for the
> view layer. This relates back because allowing $foo->bar()->bar() which
> is nice for the application developers, doesn't really help template
> folks very much. Indeed, all it seems to do is encourage application
> developers to be lazy and not decompose difficult hierarchies into

time limits are also a factor. my solution is to provide custom tags
to which object vars can be passed e.g.

{shownewshighlights items=$NewsList max=5 cssclass="" type=""}

where type is something like 'ul' 'ol' 'dt' 'table', I think you can guess
how that effects the output.
but then again I don't see the templates as visual layouts - HTML is
structural markup, style belongs in stylesheets - ask Tim Berners-Lee :-)

actually sometimes I call the modifier from outside of the template and
assign the results to the template resulting in:

{$NewsHighlights}

> simpler patterns for the template users.
> 
> I should note that $foo->bar()->bar() is a special case; AFAIK,
> $foo->bar->bar is perfectly acceptable in Smarty and PHP4. So you can
> actually help yourself somewhat by overriding __get on your objects so
> that foo() is called when foo is requested. This has the benefit of
> reducing the amount of syntax that a template user will face.

help myself by programming around the template-engine/wishes-of-the-designer?
besides I might be using __get for something else and not want to further
complicate things there.

> 
> Finally, I'm not trying to suggest that $foo->bar()->bar() shouldn't
> ever appear in any version of Smarty -- but I am suggesting that there
> is some question as to its overall merit particularly when one looks at
> how it will likely be used. Moreso, unless function derefencing is
> backported to PHP4, my personal opinion is that it should not be
> included in the 2.x series of Smarty.

I'm quite happy to live with the limitations and use the hack I have
in so far as it works. :-)

besides Smarty has to become Exception aware, amongst other things,
in order to be fully capable of dealing with php5 code - an errant
Exception getting lose while a template is being parsed has
the ability to reek havoc in my experience :-/

lastly, Smarty is a fine piece of code.

rgds,
Jochem

> 
> best regards,
> xo boots

-- 
Smarty General Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php