Chained method calls

[Diego do Nascimento Feitosa]

    Hi all,

    Today, working with Smarty, I realized that a simple feature
(chained method calls) was not present... Hopefully, after 2 minutes
searching at google, I found this patch:
    http://codepoets.co.uk/smarty_chained_function_calls

    Is there any possibility to include this patch into the engine??
    I think this will be very usefull :)

    I don't know how much impact this can bring to the entire
distribution, but at least here, there's no negative impact.

    Thanks!!  
--
Diego Feitosa
www.dnfeitosa.com <http://www.dnfeitosa.com>


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

[messju mohr]

I'm +1 for adding this, too. I know the reason this was not added to
Smarty is, that this does not work under php4. Smarty would generate
broken php code under php4 when doing {$foo->bar()->baz()}.

I don't think that the possible impact on php4 is such a big
deal. Some template code that did not compile before (Smarty syntax
error) does now throw a php syntax error. But the benefits for php5
are there - and counting the number of requests for this feature the
demand seems high.

greetings
messju

On Sun, Dec 09, 2007 at 01:27:50PM -0200, Diego Feitosa wrote:

>    Hi all,
>
>    Today, working with Smarty, I realized that a simple feature (chained
> method calls) was not present... Hopefully, after 2 minutes searching at
> google, I found this patch:
>    http://codepoets.co.uk/smarty_chained_function_calls
>
>    Is there any possibility to include this patch into the engine??
>    I think this will be very usefull :)
>
>    I don't know how much impact this can bring to the entire distribution,
> but at least here, there's no negative impact.
>
>    Thanks!!  
> --
> Diego Feitosa
> www.dnfeitosa.com <http://www.dnfeitosa.com>

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

[boots-2]

In terms of syntax/semantics, I still think this leads to a poor way of
building templates; similarly, I don't think var-vars add useful machinery to
template syntax/semantics and I hope that despite many requests, we don't
consider adding such a "feature".

Yes, PHP allows it. It makes it easier to submit application variables to
templates for raw usage. Neither of those seem to me to be good arguments for
the inclusion of chained method calls. 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'm personally -1, but I'm too tired to continue trying to convince anyone
regarding this :)

boots

--- messju mohr <messju@...> wrote:

> I'm +1 for adding this, too. I know the reason this was not added to
> Smarty is, that this does not work under php4. Smarty would generate
> broken php code under php4 when doing {$foo->bar()->baz()}.
>
> I don't think that the possible impact on php4 is such a big
> deal. Some template code that did not compile before (Smarty syntax
> error) does now throw a php syntax error. But the benefits for php5
> are there - and counting the number of requests for this feature the
> demand seems high.
>
> greetings
> messju
>
> On Sun, Dec 09, 2007 at 01:27:50PM -0200, Diego Feitosa wrote:
> >    Hi all,
> >
> >    Today, working with Smarty, I realized that a simple feature (chained
> > method calls) was not present... Hopefully, after 2 minutes searching at
> > google, I found this patch:
> >    http://codepoets.co.uk/smarty_chained_function_calls
> >
> >    Is there any possibility to include this patch into the engine??
> >    I think this will be very usefull :)
> >
> >    I don't know how much impact this can bring to the entire distribution,
> > but at least here, there's no negative impact.
> >
> >    Thanks!!  
> > --
> > Diego Feitosa
> > www.dnfeitosa.com <http://www.dnfeitosa.com>
>
> --
> 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

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

[Mark Rogers]

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

[boots-2]

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@...> 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

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

[Dave Mittner]

I'm +1 for it, as well. I've tended to walk the line between what others
perceive as acceptable template usage and I've passed quite a few objects
into templates to be accessible should the template need the data there-in.
A good example is a user object. But what if the user object has a company
object? $user->getCompany()->getCompanyName(). I don't think that'd be
breaking too many accepted conventions. And to compare to other templating
engines, I believe Velocity supports such syntax.

I personally see this opening more doors than it would cause problems,
myself. It's adding optional support that, in its absence, might require
people to assign temporary Smarty variables- an ugly process in and of
itself.

Rikaelus




-----Original Message-----
From: messju mohr [mailto:messju@...]
Sent: Thursday, January 03, 2008 3:40 AM
To: smarty-dev@...
Subject: Re: [SMARTY-DEV] Chained method calls

I'm +1 for adding this, too. I know the reason this was not added to
Smarty is, that this does not work under php4. Smarty would generate
broken php code under php4 when doing {$foo->bar()->baz()}.

I don't think that the possible impact on php4 is such a big
deal. Some template code that did not compile before (Smarty syntax
error) does now throw a php syntax error. But the benefits for php5
are there - and counting the number of requests for this feature the
demand seems high.

greetings
messju

On Sun, Dec 09, 2007 at 01:27:50PM -0200, Diego Feitosa wrote:

>    Hi all,
>
>    Today, working with Smarty, I realized that a simple feature (chained
> method calls) was not present... Hopefully, after 2 minutes searching at
> google, I found this patch:
>    http://codepoets.co.uk/smarty_chained_function_calls
>
>    Is there any possibility to include this patch into the engine??
>    I think this will be very usefull :)
>
>    I don't know how much impact this can bring to the entire distribution,

> but at least here, there's no negative impact.
>
>    Thanks!!  
> --
> Diego Feitosa
> www.dnfeitosa.com <http://www.dnfeitosa.com>

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



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

[Marcus Bointon]

On 3 Jan 2008, at 19:11, Dave Mittner wrote:

> I personally see this opening more doors than it would cause problems,
> myself. It's adding optional support that, in its absence, might  
> require
> people to assign temporary Smarty variables- an ugly process in and of
> itself.

I agree with that - whenever I do an assign it makes me feel somehow  
grubby...

Another aspect is that chained method calls are already very commonly  
used in Javascript libraries (particularly in JQuery, not so much with  
Prototype), so those on the template side are fairly likely to have  
encountered it.

Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK resellers of info@hand CRM solutions
marcus@... | http://www.synchromedia.co.uk/