|
|
Posted by Jochem Maas on 06/21/05 01:11
boots wrote:
> --- Jochem Maas <jochem@iamjochem.com> 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
Navigation:
[Reply to this message]
|