On 26-11-2009 at 09:14:14 Werner wrote:
That is possible currently:
function phptal_tales_fullname($expr)
{
foreach(explode(',',$expr) as $subexpr) …
}
Fair enough, that's exactly how I approach some custom modifiers
currently. I agree that building it (parameters) into the PHPTAL core
Kornel Lesiński wrote:
That is possible currently:
function phptal_tales_fullname($expr)
{
foreach(explode(',',$expr) as $subexpr) …
}
Fair enough, that's exactly how I approach some custom modifiers
currently. I agree that building it (parameters) into the PHPTAL core
only saves a few lin
On 25-11-2009 at 11:35:43 Werner wrote:
Simply because it allows for multiple modifier parameters (of which some
can be optional), which in turn can allow for more flexibility in
certain kinds of modifiers, e.g:
tal:content="fullName:name/title,name/first,/name/last">
That is possible cu
Simply because it allows for multiple modifier parameters (of which some
can be optional), which in turn can allow for more flexibility in
certain kinds of modifiers, e.g:
tal:content="fullName:name/title,name/first,/name/last">
Kornel Lesiński wrote:
On 24-11-2009 at 23:43:16 Werner wrot
On 24-11-2009 at 23:43:16 Werner wrote:
Given this, one can speculate about a more leal-life example, which even
a new TAL user would easily be able to pick up:
tal:content="item/value">
Just my 2 cents ;)
But how is that better than "item/value == saved/value"?
--
regards, Kornel
___
On 25-11-2009 at 08:49:18 tarjei wrote:
Hi,
I think in that case best solution would be to make TALES more
powerful, but I wonder how much powerful? Should I add math
expressions? String concatenation? Should I allow passing of function
arguments? What the syntax should be like?
Maybe you ca
Hi,
I think in that case best solution would be to make TALES more
powerful, but I wonder how much powerful? Should I add math
expressions? String concatenation? Should I allow passing of function
arguments? What the syntax should be like?
Maybe you can find some inspiration from the Nevows tal
In agreement with some of you, I also don't like having php expressions
in my TAL templates.
I was wondering if some "arguments" as an extension to modifiers cannot
be done in a way that simply introduces a new separator to the existing
syntax, e.g. just as tal expressions already makes use of
I'd like TALES to be made more powerful. The changes won't affect those who
don't want to use the new capabilities, so I don't see any harm in extending
TALES.
___
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listi
While I was looking at the pager example, I couldn't help but think
this could be fixed by having a few helper classes for this; helper
classes that would make your phptal code cleaner and abstract out
certain typical tasks of a pager.
The same could be said for the dropdown scenario. All in all,
> href="${php:pager.getURL(pager.getNumberOfPages())}#p${latest_post/id}">Last
> >>
>
> Why not write it like this:
>
> href="${pager/getURL(pager/getNumberOfPages)}#p${latest_post/id}">Last >>
>
Or JavaBeans way :)
>
Where pager/numberOfPages is looking for getter first :)
--
Regards,
Łukas
On 17-11-2009 at 18:42:50 Iván Montes wrote:
After looking at the wiki page examples, couldn't we solve this with
specialized tales modifiers?
This is taken straight from one of my pages:
href="${php:pager.getURL(pager.getNumberOfPages())}#p${latest_post/id}">Last
»
I could replace it wi
On 18-11-2009 at 00:33:02 Tjerk Meesters wrote:
The problem of modifier scope is difficult, unless you can introduce
syntax like this:
(php:foo()) + foo/bar
Braces around the modifier code would define the scope, but this is
still error prone if you decide to have something like php:foo('(hi'
On 17-11-2009 at 18:37:30 Iván Montes wrote:
foo
This would work nicely with syntax highlighting and other editor/IDE
features, is common enough for PHP developers and allows for arbitrary
complex expressions.
That doesn't look any more elegant than "selected php:item.index ==
selected
To maintain proper bc I would suggest another namespace, like ntales (new tales)
The problem of modifier scope is difficult, unless you can introduce
syntax like this:
(php:foo()) + foo/bar
Braces around the modifier code would define the scope, but this is
still error prone if you decide to hav
After looking at the wiki page examples, couldn't we solve this with
specialized tales modifiers?
It's a bit more verbose but they are quite declarative and should be
easy to implement in the current PHPTAL infrastructure.
/imv
On 11/17/09 2:05 PM, Kornel Lesiński wrote:
On 17-11-2009
I would advocate to don't make Tales syntax more complex. There is
however one point which I would think as a good compromise, the use of
inline PHP. For example:
foo
This would work nicely with syntax highlighting and other editor/IDE
features, is common enough for PHP developers and allows
On 17-11-2009 at 12:35:02 Marco Pivetta wrote:
I know it's not an elegant solution, but it's a solution and I already
use it: what about tal:define?
It is already possible to fix those tales problems wrapping content
within a tal:omit-tag-ed "definer element" or directly a tal:define
block
I know it's not an elegant solution, but it's a solution and I already use
it: what about tal:define?
It is already possible to fix those tales problems wrapping content within a
tal:omit-tag-ed "definer element" or directly a tal:define block. Otherwise
we can set a tal:define also inside the same
19 matches
Mail list logo
