headers
William McKee | 16 Aug 05:59
Favicon

Modifiers and variables

Hey Jean-Michel et al,

I'm working on adding several new modifiers to Petal::Utils and have
come across an interesting proposal which I wanted to float with the
list.

When processing arguments passed to a modifier, there is not yet a
standard way of reading these values (at least to my knowledge). Warren
S. submitted a couple of modifiers which included a subroutine that he
devised which fetches the arguments in the following way:

  1 - if the argument is a number (decimals are OK) or contains single
  quotes, return the argument itself (i.e., plaintext)
  2 - otherwise use the argument as the key to the hash and return that
  value

I like this as it makes it really easy to pass in plain text without
having to use the string: modifier. However, I'm not sure whether this
is considered TAL compliant. What are your thoughts? I've included the
subroutine at the end.

Thanks,
William

  sub _fetch {
    my ($hash, $a) = @_;

    return undef unless defined($a);
    if($a =~ /\'/) {
      $a =~ s/\'//g;
(Continue reading)

Permalink | Reply |
headers
Fergal Daly | 16 Aug 11:54
Picon

Re: Modifiers and variables


Last year when I was hacking Petal, I changed the modifier code so that it
examined the modifier at runtime to see if it was new style or old style.
For an old style modifier it just passed in the whole string to the process()
method as usual. If it was new style, it parsed the string a set of function
arguments and passed them to the new_process method. This allowed me to do

mod:this/that "some string"

(I think that'sargument syntax, it's been a while)

Looking at the current code in Petal/Hash.pm

sub fetch
{
    my $self = shift;
    my $key  = shift;

    my $mod  = $self->_fetch_mod ($key);
    $key =~ s/^\Q$mod\E//;
    $key =~ s/^\s+//;

    my $module = $MODIFIERS->{$mod} || confess "$mod is not a known modifier";
    (defined $module and ref $module and ref $module eq 'CODE') and return $module->($self, $key); 
    $module->process ($self, $key);
}

just changing that last line to

		if ($module->can("new_process")
(Continue reading)

Permalink | Reply |
headers
William McKee | 16 Aug 19:58
Favicon

Re: Modifiers and variables

Hey Fergal,

Good to hear from you.

> Last year when I was hacking Petal, I changed the modifier code so that it
> examined the modifier at runtime to see if it was new style or old style.
> For an old style modifier it just passed in the whole string to the process()
> method as usual. If it was new style, it parsed the string a set of function
> arguments and passed them to the new_process method.

So you've been down this road too.

> This allowed me to do
> 
> mod:this/that "some string"
> 
> (I think that'sargument syntax, it's been a while)

If that's inside of an attribute, you'd need to use single quotes or
escape those double quotes.

> Looking at the current code in Petal/Hash.pm

<snip>

> just changing that last line to
> 
> 		if ($module->can("new_process")

Ahh, so this is how you differentiate between new style and old style
(Continue reading)

Permalink | Reply |
headers
Jean-Michel Hiver | 18 Aug 15:00

Re: Modifiers and variables


>If I understand you correctly, this sounds great. Is TALES where
>modifiers and the like are defined? I get TAL/TALES/METAL confused.
>
Well, TAL is the stuff that's in the petal: prefix.

METAL is the stuff that's in the METAL prefix.

TALES is the stuff that's supposed to go in the TAL attributes. And 
while Petal doesn't strictly speaking comply with the TALES syntax, it's 
pretty close.
Permalink | Reply |
headers
William McKee | 18 Aug 15:19
Favicon

Re: Modifiers and variables

On Wed, Aug 18, 2004 at 02:00:37PM +0100, Jean-Michel Hiver wrote:
> >If I understand you correctly, this sounds great. Is TALES where
> >modifiers and the like are defined? I get TAL/TALES/METAL confused.
> >
> Well, TAL is the stuff that's in the petal: prefix.
> 
> METAL is the stuff that's in the METAL prefix.
> 
> TALES is the stuff that's supposed to go in the TAL attributes. And 
> while Petal doesn't strictly speaking comply with the TALES syntax, it's 
> pretty close.

Ahh, so TAL is the language(?) where things like repeat, replace,
condition, etc. are defined. METAL is another language altogether; and
TALES is the the definition of what belongs inside of the TAL
attributes.

Well, now that I've figured out how TAL/TALES works, maybe it's time to
check into METAL <g>. Does METAL use TALES in its attributes or is that
a whole 'nother language definition?

Regards,
William

--

-- 
Knowmad Services Inc.
http://www.knowmad.com
Permalink | Reply |
headers
Jean-Michel Hiver | 18 Aug 15:45

Re: Modifiers and variables


>Well, now that I've figured out how TAL/TALES works, maybe it's time to
>check into METAL <g>. Does METAL use TALES in its attributes or is that
>a whole 'nother language definition?
>
With Petal it's another language definition derived from the includes 
syntax, as well as a huge big hack (... but it works!).

I don't really know how it's implemented with ZPT.
Permalink | Reply |
headers
Fergal Daly | 16 Aug 23:24
Picon

Re: Modifiers and variables

On Mon, Aug 16, 2004 at 01:58:08PM -0400, William McKee wrote:
> Hey Fergal,
> 
> Good to hear from you.

Good to be contributing again :-)

> > Last year when I was hacking Petal, I changed the modifier code so that it
> > examined the modifier at runtime to see if it was new style or old style.
> > For an old style modifier it just passed in the whole string to the process()
> > method as usual. If it was new style, it parsed the string a set of function
> > arguments and passed them to the new_process method.
> 
> So you've been down this road too.

Yeah, the objective of Petal-CodePerl was to precompile the expressions and
so I needed to find a way to do this for modifiers too. Since you can't
precompile something that's going to do it's own parsing, I made a slightly
modified modifier that let Petal do all the parsing.

> > just changing that last line to
> > 
> > 		if ($module->can("new_process")
> 
> Ahh, so this is how you differentiate between new style and old style
> modifiers.

Yeah,it's totally compatible.

> > 		{
(Continue reading)

Permalink | Reply |
headers
William McKee | 18 Aug 15:34
Favicon

Re: Modifiers and variables

On Mon, Aug 16, 2004 at 10:24:00PM +0100, Fergal Daly wrote:
> The patch attached moves about about 20 lines of code out of process() and
> into it's own subroutine called parse_args(). It also changes fetch() in the
> manner I explained earlier. Here's an example of a new modifier

Thanks, examples really help me grasp these ideas.

> #################
> package Reflect;

Interesting idea for a modifier <g>.

> Here's a more useful one:
> 
> ################
> 
> package Shorten;

I've implemented this in Petal::Utils as substr: though not with the
ability of cutting the string in half. This may prove a useful
addition if you don't mind me borrowing it.

> Give it a spin,

Cool, but I have to agree with Jean-Michel that I'd prefer the args not
be automatically parsed. However, I'm interested in your code that does
the parsing of the tokens. In the following line, has $TOKEN_RE already
been defined in Petal or is this coming from Petal::CodePerl?

    my @tokens = $argument =~ /($TOKEN_RE)/gsm;
(Continue reading)

Permalink | Reply |
headers
Fergal Daly | 18 Aug 16:42
Picon

Re: Modifiers and variables

On Wed, Aug 18, 2004 at 09:34:20AM -0400, William McKee wrote:
> > package Shorten;
> 
> I've implemented this in Petal::Utils as substr: though not with the
> ability of cutting the string in half. This may prove a useful
> addition if you don't mind me borrowing it.

Be my guest.

> > Give it a spin,
> 
> Cool, but I have to agree with Jean-Michel that I'd prefer the args not
> be automatically parsed.

They're only automatically parsed if your modifier has a parsed_process()
method, otherwise they're delivered as a string as usual.

I think it's very common for a modifier to want to treat it's arguments as
TALES expressions, currently this is done with $hash->{$args} but that
limits you to a single argument.

It would be nice if Petal had a built in way to pass multiple arguments to
modifiers, Shorten being a perfect example, currently you have to do this as
something like

tools/shorten/process string len

and you have to make sure that tools/shorten has been correctly populated
with a Shorten object.
(Continue reading)

Permalink | Reply |
headers
Jean-Michel Hiver | 18 Aug 15:49

Re: Modifiers and variables


>Cool, but I have to agree with Jean-Michel that I'd prefer the args not
>be automatically parsed. However, I'm interested in your code that does
>the parsing of the tokens. In the following line, has $TOKEN_RE already
>been defined in Petal or is this coming from Petal::CodePerl?
>
>    my @tokens = $argument =~ /($TOKEN_RE)/gsm;
>
If memory serves, 's' means that '.' also matches carriage returns, 
while 'm' means that ^ and $ match the beginning of string (as opposed 
to line) and the end of string (as opposed to line) respectively. Or 
maybe it's the reverse :-)

I always use both when dealing with multiline string 'cause it works for 
me...

As for $TOKEN_RE, take a look at Petal/Hash/String.pm
Permalink | Reply |
headers
Jean-Michel Hiver | 16 Aug 10:42

Re: Modifiers and variables

> I'm working on adding several new modifiers to Petal::Utils and have
> come across an interesting proposal which I wanted to float with the
> list.
> 
> When processing arguments passed to a modifier, there is not yet a
> standard way of reading these values (at least to my knowledge).

How do you mean? When you write a modifier, you have access to the raw 
string that comes after the modifier. What you do with that string is up 
to you.

Look at Petal::Hash::String and Petal::Hash for examples.

> Warren
> S. submitted a couple of modifiers which included a subroutine that he
> devised which fetches the arguments in the following way:
> 
>   1 - if the argument is a number (decimals are OK) or contains single
>   quotes, return the argument itself (i.e., plaintext)
>   2 - otherwise use the argument as the key to the hash and return that
>   value

Interesting, maybe this behavior could be implemented in an abstract 
modifier which could be subclassed at will.

> I like this as it makes it really easy to pass in plain text without
> having to use the string: modifier. However, I'm not sure whether this
> is considered TAL compliant. What are your thoughts? I've included the
> subroutine at the end.
(Continue reading)

Permalink | Reply |
headers
William McKee | 16 Aug 19:44
Favicon

Re: Modifiers and variables

On Mon, Aug 16, 2004 at 09:42:48AM +0100, Jean-Michel Hiver wrote:
> How do you mean? When you write a modifier, you have access to the raw 
> string that comes after the modifier. What you do with that string is up 
> to you.

Exactly, which is where the problem lies. If each modifier author is
writing custom code to break up the string, there is no consistency in
Petal's modifiers.

> Interesting, maybe this behavior could be implemented in an abstract 
> modifier which could be subclassed at will.

I'm not sure that I follow what you mean by an abstract modifier. Would
my custom modifier inherit from that? If so, this is essentially what
Petal::Utils is doing now. I was hoping to have a standard method for
extracting the arguments from the string but migrating the Plugin
modifier architecture from Petal::Utils into Petal would be great (I
know Steve would be all for this).

> >I like this as it makes it really easy to pass in plain text without
> >having to use the string: modifier. However, I'm not sure whether this
> >is considered TAL compliant. What are your thoughts? I've included the
> >subroutine at the end.
> 
> Well, it's not TALES (TAL Expression Syntax) compliant. However in my 
> view what's inside the TAL attributes doesn't really matter since it's 
> pretty much application-dependant anyway.
> 
> Petal has never been TALES compliant since it lets you pass argument to 
> methods, which in my knowledge is not supported by TALES.
(Continue reading)

Permalink | Reply |
headers
Jean-Michel Hiver | 18 Aug 14:57

Re: Modifiers and variables

William McKee wrote:

>On Mon, Aug 16, 2004 at 09:42:48AM +0100, Jean-Michel Hiver wrote:
>  
>
>>How do you mean? When you write a modifier, you have access to the raw 
>>string that comes after the modifier. What you do with that string is up 
>>to you.
>>    
>>
>
>Exactly, which is where the problem lies. If each modifier author is
>writing custom code to break up the string, there is no consistency in
>Petal's modifiers.
>
I see. Well, I wouldn't adding a base class (i.e. Petal::Plugin) which 
would be the recommended method to implement new modifiers, and then 
cabling existing modifiers onto Petal::Plugin.

I don't really see the advantage of /enforcing/ this syntax though. What 
happens when you DO want your own syntax? At the moment the string: 
modifier is quite important to me as I use it in conjunction with a 
translation service (if there is one).

In other words, I am confused and I'm not sure :-)

>I'm not sure that I follow what you mean by an abstract modifier. Would
>my custom modifier inherit from that? If so, this is essentially what
>Petal::Utils is doing now.
>
(Continue reading)

Permalink | Reply |
headers
William McKee | 19 Aug 13:44
Favicon

Re: Modifiers and variables

> I see. Well, I wouldn't adding a base class (i.e. Petal::Plugin) which 
> would be the recommended method to implement new modifiers, and then 
> cabling existing modifiers onto Petal::Plugin.

Error: Can't parse statement. Is this valid English?

> I don't really see the advantage of /enforcing/ this syntax though. What 
> happens when you DO want your own syntax? At the moment the string: 
> modifier is quite important to me as I use it in conjunction with a 
> translation service (if there is one).
> 
> In other words, I am confused and I'm not sure :-)

If you take a look at Petal::Utils::Printf, you'll see that it gets the
entire arguments statement then calls a subroutine to do the parsing.
This subroutine is what I'd like to see added to Petal.

Steve has commented to me that he thinks much of the Petal::Utils
framework can be included in Petal. However, he's more fluent in that
framework than I am, so we're going to have to wait for him to chime in
if/when he has a moment.

I really like having a set of useful modifiers available in a single
package so suspect that Petal::Utils will stick around for some time to
come.

> >I'm not sure that I follow what you mean by an abstract modifier. Would
> >my custom modifier inherit from that? If so, this is essentially what
> >Petal::Utils is doing now.
> >
(Continue reading)

Permalink | Reply |
headers
Jean-Michel Hiver | 19 Aug 13:58

Re: Modifiers and variables

William McKee wrote:

>>I see. Well, I wouldn't adding a base class (i.e. Petal::Plugin) which 
>>would be the recommended method to implement new modifiers, and then 
>>cabling existing modifiers onto Petal::Plugin.
>>    
>>
>
>Error: Can't parse statement. Is this valid English?
>
I meant 'write a base class, and then re-factor existing plugins to inherit from the base class'. In short,
'cabling' :-)
Permalink | Reply |
headers
Steve Purkis | 19 Aug 00:08

Re: Modifiers and variables

On Aug 18, 2004, at 13:57, Jean-Michel Hiver wrote:

> William McKee wrote:
>
>> On Mon, Aug 16, 2004 at 09:42:48AM +0100, Jean-Michel Hiver wrote:
>>
>>> How do you mean? When you write a modifier, you have access to the 
>>> raw string that comes after the modifier. What you do with that 
>>> string is up to you.
>>
>> Exactly, which is where the problem lies. If each modifier author is
>> writing custom code to break up the string, there is no consistency in
>> Petal's modifiers.
>>
> I see. Well, I wouldn't adding a base class (i.e. Petal::Plugin) which 
> would be the recommended method to implement new modifiers, and then 
> cabling existing modifiers onto Petal::Plugin.

I say, what a brilliant idea! :-)

> I don't really see the advantage of /enforcing/ this syntax though.

Well, maybe don't enforce it, but *strongly recommend* it.
The advantage is a consistent API for people writing Petal modifiers so 
the wheel isn't re-invented 100 times.  As William points out, that's 
essentially what we've tried to do with the Petal::Utils::Base class, 
but really this is Petal's area of responsibility.

>  What happens when you DO want your own syntax? At the moment the 
> string: modifier is quite important to me as I use it in conjunction
(Continue reading)

Permalink | Reply |

Gmane