From chris at webarchitects.co.uk  Wed Sep  3 13:15:08 2003
From: chris at webarchitects.co.uk (Chris Croome)
Date: Wed Sep  3 12:15:11 2003
Subject: [Petal] [BUG] XML CDATA is not supported by Petal
Message-ID: <20030903111508.GF30889@webarchitects.co.uk>

Hi

In XHTML the best way to do Javascript and inline CSS is to use CDATA
marked sections, like this:

  <script type="text/javascript">
  <![CDATA[
  ... unescaped script content ...
  ]]>
  </script>

  http://www.w3.org/TR/xhtml1/#h-4.8

However Petal does not support this, the above is munged into this:

  <script type="text/javascript">

  ... unescaped script content ...

  </script>

For more on this please see the XML and XHTML specifications:

  2.7 CDATA Sections
  http://www.w3.org/TR/REC-xml#sec-cdata-sect

  4.8. Script and Style elements
  http://www.w3.org/TR/xhtml1/#h-4.8

Chris

-- 
Chris Croome                               <chris@webarchitects.co.uk>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
From chris at webarchitects.co.uk  Wed Sep  3 13:28:12 2003
From: chris at webarchitects.co.uk (Chris Croome)
Date: Wed Sep  3 12:28:14 2003
Subject: [BUG] Petal removes XML comments, was: Re: [Petal] HTML Comments
In-Reply-To: <20020820164841.GA15837@mkdoc.com>
References: <3D621A9C.5297.4C397C7@localhost> <3D622238.9245.4E15331@localhost>
	<20020820150654.GG12681@webarchitects.co.uk>
	<20020820164841.GA15837@mkdoc.com>
Message-ID: <20030903112812.GG30889@webarchitects.co.uk>

Hi

The bug I just reported about CDATA reminded me of the outstanding issue
with comments (over a year old!).

Currently all comments are removed by Petal, what I think should happen
is that comments like this should be preserved:

  <!-- foo -->

And comments in the Petal style should be removed:

  <!--? bar -->

Perhaps this bug can be fixed at the same time as the CDATA one?

For reference the section in the XML spec on comments is here:

  http://www.w3.org/TR/REC-xml#sec-comments

Chris  

On Tue 20-Aug-2002 at 05:48:41 +0100, Jean-Michel Hiver wrote:
> On Tue 20-Aug-2002 at 04:06:54PM +0100, Chris Croome wrote:
> > 
> > On Tue 20-Aug-2002 at 11:04:24 -0400, William McKee wrote:
> > >  
> > > However, enclosing a script within comment tags is a habit that
> > > most Javascript authors and websites recommend. It's probably not
> > > necessary anymore but enough people are doing it to make it
> > > problematic if Petal strips the html Comments.
> > 
> > I totally agree.
> 
> Ok, ok guys, I understood it's a bug :-)
> 
> I'm sorry I'm a bit busy with MKDoc right now. You know refactoring,
> cleaning up, implementing new things, that kind of work... I'll make
> sure I take a look at this on friday or something.

-- 
Chris Croome                               <chris@webarchitects.co.uk>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
From william at knowmad.com  Thu Sep  4 11:00:41 2003
From: william at knowmad.com (William McKee)
Date: Thu Sep  4 15:00:46 2003
Subject: [Petal] Looping through a hash
Message-ID: <20030904140041.GF7811@knowmad.com>

Hi all,

Although the docs do not indicate that loops can only be done on arrays,
my testing shows that Petal will die if you try to perform a loop over
a hash (e.g., "Error: Not an ARRAY reference at (eval 10) line 94.").

Is there a way to have Petal loop over the keys of a hash? or must I
convert the hash into an array?

In order to loop through the following list, I'm guessing that I'd want
each key-value pair to be an anonymous array:

环贩hash_ref => {
环贩环贩key1 => 'value1',
环贩环贩key2 => 'value2',
环贩环贩key3 => 'value3',
环贩}

Any suggestions for easily doing this with a one-liner? What's the
possibility of getting Petal to loop over a hash? or is this infeasible?


Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From spurkis at mkdoc.com  Thu Sep  4 18:10:20 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Thu Sep  4 17:10:25 2003
Subject: [Petal] Looping through a hash
In-Reply-To: <20030904140041.GF7811@knowmad.com>
Message-ID: <48326C09-DEF2-11D7-9F59-003065968BC2@mkdoc.com>

On Thursday, September 4, 2003, at 03:00  pm, William McKee wrote:

> Hi all,
>
> Although the docs do not indicate that loops can only be done on 
> arrays,
> my testing shows that Petal will die if you try to perform a loop over
> a hash (e.g., "Error: Not an ARRAY reference at (eval 10) line 94.").
>
> Is there a way to have Petal loop over the keys of a hash? or must I
> convert the hash into an array?

You could write a modifier, and use it with petal:repeat:

	package Petal::Hash::Keys;
	use strict;
	use warnings;
	sub process {
	    my ($self, $hash, $args) = @_;
	    my $result = $hash->fetch( $args );
	    die "$args is not a hash!" unless ref($result) eq 'HASH';
	    return [ keys %$result ];
	}
	1;

And then:
	<span petal:repeat="key keys: $some_hash">
		do something with $key ...
	    will this get the value: ${some_hash/$key} ?
	</span>

If you want both a list of key/value pairs, you could write 
Petal::Hash::Each to do something like:

	    return [ map { { key => $_, val => $result->{$_} } } keys %$result 
];

And then:
	<span petal:repeat="item each: $some_hash">
	    key: $item/key
	    val: $item/val
	</span>

I've got a few little plugins like this that might be good candidates 
for a Petal::Utils package at some stage.

hth,
-Steve

From william at knowmad.com  Fri Sep  5 04:58:31 2003
From: william at knowmad.com (William McKee)
Date: Fri Sep  5 08:58:36 2003
Subject: [Petal] Looping through a hash
In-Reply-To: <48326C09-DEF2-11D7-9F59-003065968BC2@mkdoc.com>
References: <20030904140041.GF7811@knowmad.com>
	<48326C09-DEF2-11D7-9F59-003065968BC2@mkdoc.com>
Message-ID: <20030905075831.GI600@knowmad.com>

On Thu, Sep 04, 2003 at 05:10:20PM +0100, Steve Purkis wrote:
> You could write a modifier, and use it with petal:repeat:

Thanks Steve! That's what I needed.


> And then:
> 	<span petal:repeat="key keys: $some_hash">
> 		do something with $key ...
> 	    will this get the value: ${some_hash/$key} ?
> 	</span>

Nice try but Petal isn't getting the value. I tried various
modifications but Petal doesn't want to allow the dynamic key. Could one
of the Petal engine experts comment on this?

While we are on the topic of the Petal engine, I'm trying to pass a
string value in as a parameter to one of my modifiers. Is this allowed?
What I'm trying to do is allow an arbitrary string to be the date
separator. So my proposed modifier would be called as follows:
	<p tal:content="us_date: $date -">date</p>

This gives me several interesting errors. I tried putting the - in
single quotes and prefixing it with string: but neither worked. I also
tried defining a variable but apparently I can't set a variable to a
string (or I'm not doing it right). Am I missing something or is this
just not possible?


> If you want both a list of key/value pairs, you could write 
> Petal::Hash::Each to do something like:

Ahh, another approach! And this one works for retreiving the values.


> I've got a few little plugins like this that might be good candidates 
> for a Petal::Utils package at some stage.

Building a utils package has been on my to do list for several months
now, so I used this opportunity to actually build it and combine several
of my modifiers. Since you had the idea first, would you like to create
it and put it onto CPAN?

I have attached a tarfile of my initial version since it's less than 4K.
Comments appreciated. The broken tests have been commented out in the
01.t file.


Many thanks!
William

-- 
Knowmad Services Inc.
http://www.knowmad.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Petal-Hash-Utils-0.01.tar.gz
Type: application/octet-stream
Size: 3739 bytes
Desc: not available
Url : http://lists.webarch.co.uk/pipermail/petal/attachments/20030905/f2df2bf6/Petal-Hash-Utils-0.01.tar.obj
From jhiver at mkdoc.com  Fri Sep  5 13:08:10 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Fri Sep  5 12:08:18 2003
Subject: [Petal] Looping through a hash
In-Reply-To: <20030905075831.GI600@knowmad.com>
References: <20030904140041.GF7811@knowmad.com>
	<48326C09-DEF2-11D7-9F59-003065968BC2@mkdoc.com>
	<20030905075831.GI600@knowmad.com>
Message-ID: <20030905110810.GA8226@mkdoc.com>

> > 	<span petal:repeat="key keys: $some_hash">
> > 		do something with $key ...
> > 	    will this get the value: ${some_hash/$key} ?
> > 	</span>
> 
> Nice try but Petal isn't getting the value. I tried various
> modifications but Petal doesn't want to allow the dynamic key. Could one
> of the Petal engine experts comment on this?

Petal doesn't support that kind of recursive stuff. Fergal's CodePerl
might do.

So you need to write not only a hash_keys: modifier, but also a
hash_value: modifier. I've attached an example.


> While we are on the topic of the Petal engine, I'm trying to pass a
> string value in as a parameter to one of my modifiers. Is this allowed?
> What I'm trying to do is allow an arbitrary string to be the date
> separator. So my proposed modifier would be called as follows:
> 	<p tal:content="us_date: $date -">date</p>

This is fine. You just have to realize that your modifier will deal with
a string ' $date -'. It's up to your modifier to parse this string to
separate 'date' and '-'.

I suggest you take a look at how the 'string:' modifier is working and
adapt it to your case.


> > I've got a few little plugins like this that might be good candidates 
> > for a Petal::Utils package at some stage.
> 
> Building a utils package has been on my to do list for several months
> now, so I used this opportunity to actually build it and combine several
> of my modifiers. Since you had the idea first, would you like to create
> it and put it onto CPAN?
> 
> I have attached a tarfile of my initial version since it's less than 4K.
> Comments appreciated. The broken tests have been commented out in the
> 01.t file.

It would be cool to see some Petal contributions on CPAN -
Great stuff :)


Cheers,
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From jhiver at mkdoc.com  Fri Sep  5 13:12:03 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Fri Sep  5 12:12:09 2003
Subject: [Petal] Looping through a hash - EXAMPLES
In-Reply-To: <20030905075831.GI600@knowmad.com>
References: <20030904140041.GF7811@knowmad.com>
	<48326C09-DEF2-11D7-9F59-003065968BC2@mkdoc.com>
	<20030905075831.GI600@knowmad.com>
Message-ID: <20030905111203.GA8441@mkdoc.com>

Forgot to attach the promessed example...

-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.pl
Type: application/x-perl
Size: 806 bytes
Desc: not available
Url : http://lists.webarch.co.uk/pipermail/petal/attachments/20030905/f2d8db48/example.bin
-------------- next part --------------
<example>
  <pair petal:repeat="key hash_keys: hash">
     <key petal:content="key" />
     <val petal:content="hash_value: hash key" />
  </pair>
</example>
From spurkis at mkdoc.com  Fri Sep  5 20:27:44 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Fri Sep  5 19:31:43 2003
Subject: Petal::Utils (was Re: [Petal] Looping through a hash)
In-Reply-To: <20030905075831.GI600@knowmad.com>
Message-ID: <A44C57BE-DFCE-11D7-AF1B-003065968BC2@mkdoc.com>

On Friday, September 5, 2003, at 08:58  am, William McKee wrote:

>> I've got a few little plugins like this that might be good candidates
>> for a Petal::Utils package at some stage.
>
> Building a utils package has been on my to do list for several months
> now, so I used this opportunity to actually build it and combine 
> several
> of my modifiers. Since you had the idea first, would you like to create
> it and put it onto CPAN?

I can do, but if you'd like to take it on you're more than welcome.


> I have attached a tarfile of my initial version since it's less than 
> 4K.
> Comments appreciated. The broken tests have been commented out in the
> 01.t file.

Thanks for getting the ball rolling...  I've spent some time today 
adding my 2?.  It's a bit more than 4K now, so I've put it up here:

	http://staging.quiup.com/perl/Petal-Utils-0.02.tar.gz

A lot of things have changed, mostly with the idea of expanding the 
module.  This design won't force plugins on a user that doesn't need 
them.  Things are loaded as needed now, which means the user isn't 
forced to load plugins they won't need - this should avoid NS pollution 
& decrease load time.

Here's a summary of the work done:

   *	Renamed to Petal::Utils so Petal doesn't think the Utils package
	is a Petal Hash modifier. [Steve Purkis]
   *	Moved to Module::Build. [Steve Purkis]
   +	Added modifiers: Date Dump Equal(eq) And Like Sort [Steve Purkis]
   +	Added import() functionality to specify modifier sets. [Steve 
Purkis]
   *	Split up modifiers into individual Petal::Utils::<modifier> modules
	that are loaded as needed. [Steve Purkis]
   *	Restructured test directory, using File::Spec and more verbose file
	names. [Steve Purkis]
   *	Added error handling code to existing modifiers. [Steve Purkis]

Jean-Michel: you might like to move Petal::Utils::Base into Petal 
itself (Petal::Plugin?).  This could result in more people writing 
plugins in a standard way for Petal (which would be a good thing, 
IMHO).  Moreover, parsing tools for $args could go in here.  At the 
moment, you've got to know a lot about Petal to parse $args properly 
(which incidently, Petal::Utils does *not* do).

-Steve

From spurkis at mkdoc.com  Fri Sep  5 20:37:35 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Fri Sep  5 19:37:47 2003
Subject: [Petal] [IDEA] Hash with params
Message-ID: <049F5842-DFD0-11D7-AF1B-003065968BC2@mkdoc.com>

Hi,

It's just occurred to me - we've been having problems with using 
variables to look up values in a hash through Petal.  A solution might 
be to allow:

	$key => <span petal:replace="some/hash $key">hash key</span>

A similar argument would apply to Arrays:

	list[$idx] = <span petal:replace="some/list $idx">hash key</span>

Currently these cause Petal to croak - would changing this behaviour be 
a problem?

-Steve

From william at knowmad.com  Fri Sep  5 16:40:31 2003
From: william at knowmad.com (William McKee)
Date: Fri Sep  5 20:40:36 2003
Subject: Petal::Utils (was Re: [Petal] Looping through a hash)
In-Reply-To: <A44C57BE-DFCE-11D7-AF1B-003065968BC2@mkdoc.com>
References: <20030905075831.GI600@knowmad.com>
	<A44C57BE-DFCE-11D7-AF1B-003065968BC2@mkdoc.com>
Message-ID: <20030905194031.GP600@knowmad.com>

On Fri, Sep 05, 2003 at 07:27:44PM +0100, Steve Purkis wrote:
> I can do, but if you'd like to take it on you're more than welcome.

Wow! Nice work. You definitely have more background with Perl and
modules than I do, so I'm going to let you adopt this one. Maybe I'll
get registered as a developer and upload a few new modifiers in the
future.

I should be able to create CPAN projects within the Petal::Util::* path,
right? I think it's important to allow anyone to be able to glob on to
the existing pattern without needing someone's approval to include the
package with the Petal::Util modules. However, looking at Util.pm, it
seems to me that it would mean that we need to dynamically build the
%PLUGIN_SET hash. Or will the user simply have to explicity request the
module (e.g., use Petal::Utils qw(NewMod))?


> Thanks for getting the ball rolling...  I've spent some time today 
> adding my 2?.  It's a bit more than 4K now, so I've put it up here:

It was worth the effort looking at what has come out of it!

I notice that you are using a function from Date::Format called time2str
in Date.pm now. I am getting a test failure as follows:

> t/02__default....NOK 4#     Failed test (t/02__default.t at line 84)
> #     doesn't match '(?-xism:date = Jan\s+1 1970 01:00:01)'

The pertinent output line is:
> date = Dec 31 1969 19:00:01

It looks like the time has been offset by my localtime (GMT -4). We need
to tell Date::Format to assume that localtime is being passed in to the
time2str function.


Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From evan at 4-am.com  Fri Sep  5 15:44:21 2003
From: evan at 4-am.com (Evan Simpson)
Date: Fri Sep  5 20:44:26 2003
Subject: [Petal] [IDEA] Hash with params
In-Reply-To: <049F5842-DFD0-11D7-AF1B-003065968BC2@mkdoc.com>
References: <049F5842-DFD0-11D7-AF1B-003065968BC2@mkdoc.com>
Message-ID: <3F58E795.2090003@4-am.com>

Steve Purkis wrote:
>     $key => <span petal:replace="some/hash $key">hash key</span>
> 
> A similar argument would apply to Arrays:
> 
>     list[$idx] = <span petal:replace="some/list $idx">hash key</span>

I'm not sure how well this would apply to Petal, but ZPTs are now 
officially growing a path syntax extension that specifically deals with 
these cases.  Examples of prefixed path segment usage are 
"some/hash/key:keystring" and "some/list/item:0".  Apart from a set of 
built-in prefixes, they are defined with tal:define="prefix <prefix> 
<expression>".  Generally, a prefix acts as either a function with two 
arguments or a namespace of single-argument functions.  The examples 
above are of the first sort -- they take the current traversal object 
and a key or integer argument.  An example of the second sort is the 
'standard' prefix, which in ZPTs is a namespace of standard formatting 
functions, as in "some/number/standard:thousands_commas".

Cheers,

Evan @ 4-am

From william at knowmad.com  Sun Sep  7 21:29:02 2003
From: william at knowmad.com (William McKee)
Date: Mon Sep  8 01:29:33 2003
Subject: [Petal] [Off topic] UTF8 errors
Message-ID: <20030908002902.GB600@knowmad.com>

Hi all,

This evening I tried to upgrade my Apache/mod_perl server to Perl 5.8.0.
Upon doing so I received the following error in my logs:

-------------------------
[Sun Sep  7 17:29:15 2003] Error occurred in
/usr/local/lib/perl5/site_perl/5.8.0/Petal.pm at line 386: Error
executing run mode 'display_form': [PETAL ERROR] Undefined subroutine
&Encode::_utf8_on called at (eval 79) line 11.
-------------------------

My searches of Google seem to indicate the 5.8.0 is defaulting into UTF8
mode and that my scripts will require some scrubbing before working
correctly in 5.8.0. 

It sounds like some of the folks on this list have an understanding of
UTF8 in Perl. Could you enlighten me as to why I would receive the above
error and what would need to be modified in my scripts to prevent this
should I decide to upgrade to 5.8.0 in the future?


Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From spurkis at mkdoc.com  Mon Sep  8 12:55:30 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Mon Sep  8 11:55:33 2003
Subject: Petal::Utils (was Re: [Petal] Looping through a hash)
In-Reply-To: <20030905194031.GP600@knowmad.com>
Message-ID: <F67D6398-E1EA-11D7-9666-003065968BC2@mkdoc.com>

On Friday, September 5, 2003, at 08:40  pm, William McKee wrote:

> On Fri, Sep 05, 2003 at 07:27:44PM +0100, Steve Purkis wrote:
>> I can do, but if you'd like to take it on you're more than welcome.
>
> Wow! Nice work. You definitely have more background with Perl and
> modules than I do, so I'm going to let you adopt this one. Maybe I'll
> get registered as a developer and upload a few new modifiers in the
> future.

Thanks for the feedback -- I'll whack it up on CPAN in a few moments 
then.  Hopefully it won't require too much work though; I'm getting 
swamped with maintenance woes as it is ;-).  Maybe when you get your 
CPAN account you can take over this module?

Also, if its alright with everyone I'll put the Petal List down as the 
place for this to be discussed.  And if other people want to contribute 
to the project, we should bung this up onto a public CVS server 
somewhere -- I'll host it locally until I hear otherwise.


> I should be able to create CPAN projects within the Petal::Util::* 
> path,
> right? I think it's important to allow anyone to be able to glob on to
> the existing pattern without needing someone's approval to include the
> package with the Petal::Util modules. However, looking at Util.pm, it
> seems to me that it would mean that we need to dynamically build the
> %PLUGIN_SET hash. Or will the user simply have to explicity request the
> module (e.g., use Petal::Utils qw(NewMod))?

Well..  I'm not 100% sure if writing additional modules outside of the 
Petal-Utils distro is a good idea.  If you do, why not just set 
%Petal::Hash::MODIFIER directly?  But to answer your question, yes 
users would have to explicitly request a module that Petal::Utils 
doesn't know about:

	use Petal::Utils qw( NewMod );

Dynamically building %PLUGIN_SET is, well, difficult.  You're basically 
asking for a plugin manager for Petal, which is not what Petal::Utils 
was meant to be.

My first reaction is to say that %PLUGIN_SET is private for a reason.  
It's hard-coded and was meant to be populated by hand.  Having said 
that, with a few small changes you could update it dynamically from 
another module, which you'd still have to use:

	use Petal::Utils::MyUtil; # add MyUtil to %PLUGIN_SET
	use Petal::Utils qw( MyUtil :default );

This would be a bit pointless for individual modules, but might be 
useful for distros containing more than one.  Still, I'd argue that you 
could just inherit from Petal::Utils and have your own %PLUGIN_SET:

	use Petal::Utils::MyUtils qw( MyUtil :my_foo ); # inherit from P:Utils
	use Petal::Utils qw( :default :foo );
	
A different way of approaching this might be to update the %PLUGIN_SET 
every time a new Petal::Utils module was installed.  This would require 
some fancy installation code, but could be done.  Though if it happens 
I'd recommend calling it something other than Petal::Utils...  
Petal::PluginManager perhaps.  And if you go to that lenght, you might 
as well look inyo integrating it with Petal.

Yet another possibility is to search @INC for plugins, just like Petal 
does.  But that seems so close to what Petal already does that it 
doesn't really make sense to duplicate the effort.

Personally, I think the plugin manager is a neat idea, but I don't see 
enough reason to write it at the moment.  I'm tempted to keep things as 
is for now.


>> Thanks for getting the ball rolling...  I've spent some time today
>> adding my 2?.  It's a bit more than 4K now, so I've put it up here:
>
> It was worth the effort looking at what has come out of it!

Glad you like it.


> I notice that you are using a function from Date::Format called 
> time2str
> in Date.pm now. I am getting a test failure as follows:
>
>> t/02__default....NOK 4#     Failed test (t/02__default.t at line 84)
>> #     doesn't match '(?-xism:date = Jan\s+1 1970 01:00:01)'
>
> The pertinent output line is:
>> date = Dec 31 1969 19:00:01
>
> It looks like the time has been offset by my localtime (GMT -4). We 
> need
> to tell Date::Format to assume that localtime is being passed in to the
> time2str function.

Quite right, but I think it's a problem with the tests more than 
anything else.  I get GMT +1, which is the standard behaviour of 
Date::Format.  We could stick in an optional $TIMEZONE class var if 
this is a problem in the templates, but for now I'll just make that 
test more generic.

-Steve

From william at knowmad.com  Mon Sep  8 14:44:25 2003
From: william at knowmad.com (William McKee)
Date: Mon Sep  8 18:44:30 2003
Subject: [Petal] [IDEA] Hash with params
In-Reply-To: <3F58E795.2090003@4-am.com>
References: <049F5842-DFD0-11D7-AF1B-003065968BC2@mkdoc.com>
	<3F58E795.2090003@4-am.com>
Message-ID: <20030908174425.GN600@knowmad.com>

Jean-Michel,

Since this ability to reference a value in a hash using a dynamic key is
being added into the ZPT standard, can you add it as a TODO item to
Petal? (I hope you appreciate my sense of diplomacy here in not asking
you to write the code ;->).

William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From william at knowmad.com  Mon Sep  8 15:02:05 2003
From: william at knowmad.com (William McKee)
Date: Mon Sep  8 19:02:08 2003
Subject: Petal::Utils (was Re: [Petal] Looping through a hash)
In-Reply-To: <F67D6398-E1EA-11D7-9666-003065968BC2@mkdoc.com>
References: <20030905194031.GP600@knowmad.com>
	<F67D6398-E1EA-11D7-9666-003065968BC2@mkdoc.com>
Message-ID: <20030908180205.GQ600@knowmad.com>

On Mon, Sep 08, 2003 at 11:55:30AM +0100, Steve Purkis wrote:
> Thanks for the feedback -- I'll whack it up on CPAN in a few moments 
> then.  Hopefully it won't require too much work though; I'm getting 
> swamped with maintenance woes as it is ;-).  Maybe when you get your 
> CPAN account you can take over this module?

I'd be glad to take over. I'll work on getting that setup later this
month (I'll be out of town for a week starting on Thursday).


> Dynamically building %PLUGIN_SET is, well, difficult.  You're basically 
> asking for a plugin manager for Petal, which is not what Petal::Utils 
> was meant to be.

Yes, I see what you mean.


> Still, I'd argue that you could just inherit from Petal::Utils and
> have your own %PLUGIN_SET:

That seems like a good middle-ground solution!


> Personally, I think the plugin manager is a neat idea, but I don't see 
> enough reason to write it at the moment.  I'm tempted to keep things as 
> is for now.

Definitely agreed. Thanks for taking the time to run through all the
possibilities of extending Petal::Utils. You've given me some good food
for thought. I think that inheriting from P::Utils is the best solution
for now if, for whatever reason, the modifier is not included in
P::Utils.


> Quite right, but I think it's a problem with the tests more than 
> anything else.  I get GMT +1, which is the standard behaviour of 
> Date::Format.  We could stick in an optional $TIMEZONE class var if 
> this is a problem in the templates, but for now I'll just make that 
> test more generic.

After sending that first email, another possible reason came to mind to
explain why I had the test fail. On the system that I was doing the test
on, I dual-boot into both Windows and Unix. However, I did an install
onto my Linux-only server this morning and got the same test error. I
think making the test generic is a good start. Makes sense to see what
happens in the wild before fixing the subroutine itself.


Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From spurkis at mkdoc.com  Mon Sep  8 20:27:38 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Mon Sep  8 19:27:42 2003
Subject: [Petal] [IDEA] Hash with params
In-Reply-To: <3F58E795.2090003@4-am.com>
Message-ID: <1FE8CFDA-E22A-11D7-9666-003065968BC2@mkdoc.com>

On Friday, September 5, 2003, at 08:44  pm, Evan Simpson wrote:

> Steve Purkis wrote:
>>     $key => <span petal:replace="some/hash $key">hash key</span>
>> A similar argument would apply to Arrays:
>>     list[$idx] = <span petal:replace="some/list $idx">hash key</span>
>
> I'm not sure how well this would apply to Petal, but ZPTs are now 
> officially growing a path syntax extension that specifically deals 
> with these cases.  Examples of prefixed path segment usage are 
> "some/hash/key:keystring" and "some/list/item:0".  Apart from a set of 
> built-in prefixes, they are defined with tal:define="prefix <prefix> 
> <expression>".  Generally, a prefix acts as either a function with two 
> arguments or a namespace of single-argument functions.  The examples 
> above are of the first sort -- they take the current traversal object 
> and a key or integer argument.  An example of the second sort is the 
> 'standard' prefix, which in ZPTs is a namespace of standard formatting 
> functions, as in "some/number/standard:thousands_commas".

Interesting idea -- don't know what it would take to implement though.  
And I assume it would be possible to define prefixes that variables as 
arguments so that it would be possible to say "some/hash/key:somevar" 
and "some/list/item:someindex"?

-Steve

From spurkis at mkdoc.com  Mon Sep  8 20:38:14 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Mon Sep  8 19:38:17 2003
Subject: Petal::Utils (was Re: [Petal] Looping through a hash)
In-Reply-To: <20030908180205.GQ600@knowmad.com>
Message-ID: <9B319666-E22B-11D7-9666-003065968BC2@mkdoc.com>

On Monday, September 8, 2003, at 07:02  pm, William McKee wrote:

> On Mon, Sep 08, 2003 at 11:55:30AM +0100, Steve Purkis wrote:
>> Thanks for the feedback -- I'll whack it up on CPAN in a few moments
>> then.  Hopefully it won't require too much work though; I'm getting
>> swamped with maintenance woes as it is ;-).  Maybe when you get your
>> CPAN account you can take over this module?
>
> I'd be glad to take over. I'll work on getting that setup later this
> month (I'll be out of town for a week starting on Thursday).

Sounds good.  Let me know when you're ready.


>> Personally, I think the plugin manager is a neat idea, but I don't see
>> enough reason to write it at the moment.  I'm tempted to keep things 
>> as
>> is for now.
>
> Definitely agreed. Thanks for taking the time to run through all the
> possibilities of extending Petal::Utils. You've given me some good food
> for thought. I think that inheriting from P::Utils is the best solution
> for now if, for whatever reason, the modifier is not included in
> P::Utils.

Yeah, but hopefully inclusion in P::Utils should be as easy as 
submitting a patch to the maintainer.

-Steve

PS: it's up on CPAN now - http://search.cpan.org/dist/Petal-Utils

From william at knowmad.com  Mon Sep  8 16:16:31 2003
From: william at knowmad.com (William McKee)
Date: Mon Sep  8 20:16:36 2003
Subject: [Petal] [Utils] Error log messages
Message-ID: <20030908191631.GS600@knowmad.com>

Hi Steve,

I just installed Petal::Utils onto my webserver and am noticing that the
first run causes loads of error messages to get written to my logs. Any
ideas why this would be happening? I'm running Apache 1.3.28 with
mod_perl and Perl 5.6.1. I am using Apache::Registry to run the scripts.
Here's the beginning of one of the error messages:

installing Petal plugin: 'UpperCase' at /updater/lib/Knowmad/Application/Updater.pm line 59
	Knowmad::Application::Updater::BEGIN() called at /usr/local/lib/perl5/site_perl/5.6.1/Petal/Utils.pm line 59

This occurs for each plugin being installed and includes the output of
my script that is being loaded by A::R. It looks like P::Utils is
causing the BEGIN block to get called each time a new plugin is loaded.
I'm going to start investigating it myself but wanted to post this to
see if you or anyone else could provide some insight.

Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From evan at 4-am.com  Mon Sep  8 15:35:55 2003
From: evan at 4-am.com (Evan Simpson)
Date: Mon Sep  8 20:35:59 2003
Subject: [Petal] [IDEA] Hash with params
In-Reply-To: <1FE8CFDA-E22A-11D7-9666-003065968BC2@mkdoc.com>
References: <1FE8CFDA-E22A-11D7-9666-003065968BC2@mkdoc.com>
Message-ID: <3F5CDA1B.3040009@4-am.com>

Steve Purkis wrote:
> And I assume it would be possible to define prefixes that variables as 
> arguments so that it would be possible to say "some/hash/key:somevar" 
> and "some/list/item:someindex"?

Sure!  The prefix implementation can do whatever it likes with the 
argument, including treat it as a variable name, convert it to a number, 
or ignore it entirely.

In ZPTs, prefixes are implemented by a pair of functions dubbed the 
compiler and the handler.  At least one of the two must be provided.

If a compiler is provided, the prefix and argument strings are passed to 
it (a single compiler could be used for multiple prefixes) and its 
return value replaces the argument string in further processing.  This 
allows for argument parsing, error checking, and other preprocessing 
that doesn't depend on context.

If a handler is provided, then it is called during path traversal.  The 
prefix string, argument value, current traversal object, remaining 
traversal path segments, and the execution context (variable namespaces) 
are passed to it.  The returned object is used for the next traversal step.

As an optimization the compiler is called lazily, the first time the 
path is traversed, and the argument value is cached.

Here's the Python code that defines the builtin 'var' prefix:

# 'var:x' is replaced with the value of variable 'x'
def var_compiler(prefix, arg):
     arg = arg.strip()
     if not _valid_name(arg):
         raise CompilerError, ('"%s" is not a valid variable name'
                               % arg)
     return arg
def var_handler(prefix, arg, object, path, econtext):
     path.append(econtext.vars[arg])
     return object
builtins['var'] = PathPrefix(var_compiler, var_handler)


Cheers,

Evan @ 4-am

From spurkis at mkdoc.com  Tue Sep  9 10:55:20 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Tue Sep  9 09:55:23 2003
Subject: [Petal] [Utils] Error log messages
In-Reply-To: <20030908191631.GS600@knowmad.com>
Message-ID: <5796382A-E2A3-11D7-84C1-003065968BC2@mkdoc.com>

On Monday, September 8, 2003, at 08:16  pm, William McKee wrote:

> Hi Steve,
>
> I just installed Petal::Utils onto my webserver and am noticing that 
> the
> first run causes loads of error messages to get written to my logs. Any
> ideas why this would be happening? I'm running Apache 1.3.28 with
> mod_perl and Perl 5.6.1. I am using Apache::Registry to run the 
> scripts.
> Here's the beginning of one of the error messages:
>
> installing Petal plugin: 'UpperCase' at 
> /updater/lib/Knowmad/Application/Updater.pm line 59

That's because you have warnings turned on, and this line in Utils.pm:

	88: warnings::warn( "installing Petal plugin: '$name'" )
	      if warnings::enabled;

You can turn off warnings for Petal::Utils like so:

	no warnings 'Petal::Utils';

If you still have troubles let me know and I'll change this code.

-Steve

From william at knowmad.com  Tue Sep  9 06:50:05 2003
From: william at knowmad.com (William McKee)
Date: Tue Sep  9 10:50:10 2003
Subject: [Petal] [Utils] Error log messages
In-Reply-To: <5796382A-E2A3-11D7-84C1-003065968BC2@mkdoc.com>
References: <20030908191631.GS600@knowmad.com>
	<5796382A-E2A3-11D7-84C1-003065968BC2@mkdoc.com>
Message-ID: <20030909095005.GL600@knowmad.com>

On Tue, Sep 09, 2003 at 09:55:20AM +0100, Steve Purkis wrote:
> That's because you have warnings turned on, and this line in Utils.pm:
> 
> 	88: warnings::warn( "installing Petal plugin: '$name'" )
> 	      if warnings::enabled;
> 
> You can turn off warnings for Petal::Utils like so:
> 
> 	no warnings 'Petal::Utils';

But I'm in a catch-22 because Perl returns an error message if I try to
put that line before calling Petal::Utils:

[Tue Sep  9 03:46:55 2003] [error] unknown warnings category
'Petal::Utils' at /usr/local/apache/conf/startup.pl line 55

I simply commented out line 88 in my version of Petal::Utils. I think
that's the best long-term solution unless you are debugging the module.
Or, perhaps we could add a DEBUG flag that would be checked before
emitting the warning message.

Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From spurkis at mkdoc.com  Tue Sep  9 13:38:35 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Tue Sep  9 12:38:52 2003
Subject: [Petal] [Utils] Error log messages
In-Reply-To: <20030909095005.GL600@knowmad.com>
Message-ID: <25925206-E2BA-11D7-84C1-003065968BC2@mkdoc.com>

On Tuesday, September 9, 2003, at 10:50  am, William McKee wrote:

> On Tue, Sep 09, 2003 at 09:55:20AM +0100, Steve Purkis wrote:
>> That's because you have warnings turned on, and this line in Utils.pm:
>>
>> 	88: warnings::warn( "installing Petal plugin: '$name'" )
>> 	      if warnings::enabled;
>>
>> You can turn off warnings for Petal::Utils like so:
>>
>> 	no warnings 'Petal::Utils';
>
> But I'm in a catch-22 because Perl returns an error message if I try to
> put that line before calling Petal::Utils:
>
> [Tue Sep  9 03:46:55 2003] [error] unknown warnings category
> 'Petal::Utils' at /usr/local/apache/conf/startup.pl line 55
>
> I simply commented out line 88 in my version of Petal::Utils. I think
> that's the best long-term solution unless you are debugging the module.

Fair enough - I'll suppress the warning in the next release.


> Or, perhaps we could add a DEBUG flag that would be checked before
> emitting the warning message.

A debug flag is an excellent idea, but for consitency across the Petal 
project it would ideally be added to Petal and used by Petal::Utils.  
There are plenty of ways to do this, if anyone's interested let me know.

-Steve

From spurkis at mkdoc.com  Tue Sep  9 13:45:20 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Tue Sep  9 12:45:25 2003
Subject: [Petal] [IDEA] Hash with params
In-Reply-To: <3F5CDA1B.3040009@4-am.com>
Message-ID: <1712F731-E2BB-11D7-84C1-003065968BC2@mkdoc.com>

On Monday, September 8, 2003, at 08:35  pm, Evan Simpson wrote:

> Steve Purkis wrote:
>> And I assume it would be possible to define prefixes that variables 
>> as arguments so that it would be possible to say 
>> "some/hash/key:somevar" and "some/list/item:someindex"?
>
> Sure!  The prefix implementation can do whatever it likes with the 
> argument, including treat it as a variable name, convert it to a 
> number, or ignore it entirely.

Cool - thanks for the example.  That's much more flexible than 
re-tasking the hash/list with params (though I think that's still a 
good idea for the case I outlined :).

It would be nice to see user-defined prefixes implemented in Petal, 
though it could potentially be a lot of work (I'm not that familiar 
with the core).  Unfortunately I don't have time to do it, but I'd 
second William's vote to add it to the Todo list.

Ta,
-Steve

From william at knowmad.com  Tue Sep  9 09:04:10 2003
From: william at knowmad.com (William McKee)
Date: Tue Sep  9 13:04:15 2003
Subject: [Petal] [Utils] Error log messages
In-Reply-To: <25925206-E2BA-11D7-84C1-003065968BC2@mkdoc.com>
References: <20030909095005.GL600@knowmad.com>
	<25925206-E2BA-11D7-84C1-003065968BC2@mkdoc.com>
Message-ID: <20030909120410.GN600@knowmad.com>

On Tue, Sep 09, 2003 at 12:38:35PM +0100, Steve Purkis wrote:
> A debug flag is an excellent idea, but for consitency across the Petal 
> project it would ideally be added to Petal and used by Petal::Utils.  
> There are plenty of ways to do this, if anyone's interested let me know.

Seems like the best solution would be to set it as an option when the
Petal object is created (or as a global)?

William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From spurkis at mkdoc.com  Tue Sep  9 15:58:23 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Tue Sep  9 14:58:35 2003
Subject: [Petal] [Utils] Error log messages
In-Reply-To: <20030909120410.GN600@knowmad.com>
Message-ID: <AD55D6E8-E2CD-11D7-84C1-003065968BC2@mkdoc.com>

On Tuesday, September 9, 2003, at 01:04  pm, William McKee wrote:

> On Tue, Sep 09, 2003 at 12:38:35PM +0100, Steve Purkis wrote:
>> A debug flag is an excellent idea, but for consitency across the Petal
>> project it would ideally be added to Petal and used by Petal::Utils.
>> There are plenty of ways to do this, if anyone's interested let me 
>> know.
>
> Seems like the best solution would be to set it as an option when the
> Petal object is created (or as a global)?

Ideally, both.  But at the very least, as a class var.  Here's yet 
another debugging algorithm (what I currently do in Pangloss):

	$Pangloss::DEBUG{'Class::Foo'} = 1; # class-level debugging
	$Pangloss::DEBUG{ ALL }        = 1; # debug all classes
	$foo->emit( 'a message' );

And in Pangloss::Object you have:

	sub emit {
	    my $self  = shift;
	    my $mesg  = shift;
	    my $class = $self->class;
	    my ($package, $filename, $line, $subroutine, $hasargs,
		$wantarray, $evaltext, $is_require, $hints, $bitmask) = caller( 1 );
	    $subroutine =~ s/.*:://;
	    if ($Pangloss::DEBUG{ ALL } || $Pangloss::DEBUG{ $class }) {
		my $warn_str = "[$class\::$subroutine] $mesg";
	        $warn_str   .= "\n" unless $mesg =~ /\n/;
	        warn( $warn_str );
	    }
	    return $self;
	}

	sub class {
	    my $thing = shift;
	    return ref($thing) || $thing;
	}

Adding per-object debugging wouldn't be difficult.  Heck, you could 
even do trees by sticking a grep in there...

food for thought,
-Steve

From william at knowmad.com  Tue Sep  9 23:10:26 2003
From: william at knowmad.com (William McKee)
Date: Wed Sep 10 03:12:15 2003
Subject: [Petal] [Utils] Install errors
Message-ID: <20030910021026.GD600@knowmad.com>

Hi Steve,

Just tried to install Petal::Utils onto one of my production servers
(Perl 5.6.1, CPAN 1.76). Got the following warning but installation
continued which resulted in error messages during tests:

---------------------------
WARNING: Date::Format: Prerequisite Date::Format isn't installed
ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the
versions
 of the modules indicated above before proceeding with this
installation.
---------------------------

Is this a problem with Module::Build? CPAN usu. follows prereq's
automatically for me.

Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From spurkis at mkdoc.com  Wed Sep 10 12:49:55 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Wed Sep 10 11:49:58 2003
Subject: [Petal] [Utils] Install errors
In-Reply-To: <20030910021026.GD600@knowmad.com>
Message-ID: <83D25FDE-E37C-11D7-9D1E-003065968BC2@mkdoc.com>

I can honestly say: it's not a bug, it's a feature :-)

Amongst other things, Module::Build lets you specify 'required' 
modules, and 'recommended' modules separately.

Date::Format is recommended, not required.  Only P::Utils::Date uses 
it, so if you never use the date: modifier, you're not forced to 
install a module you may never use.

-Steve


On Wednesday, September 10, 2003, at 03:10  am, William McKee wrote:

> Hi Steve,
>
> Just tried to install Petal::Utils onto one of my production servers
> (Perl 5.6.1, CPAN 1.76). Got the following warning but installation
> continued which resulted in error messages during tests:
>
> ---------------------------
> WARNING: Date::Format: Prerequisite Date::Format isn't installed
> ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the
> versions
>  of the modules indicated above before proceeding with this
> installation.
> ---------------------------
>
> Is this a problem with Module::Build? CPAN usu. follows prereq's
> automatically for me.
>
> Thanks,
> William
>
> -- 
> Knowmad Services Inc.
> http://www.knowmad.com

From jhiver at mkdoc.com  Wed Sep 10 12:57:32 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Wed Sep 10 11:57:40 2003
Subject: [Petal] [IDEA] Hash with params
In-Reply-To: <3F58E795.2090003@4-am.com>
References: <049F5842-DFD0-11D7-AF1B-003065968BC2@mkdoc.com>
	<3F58E795.2090003@4-am.com>
Message-ID: <20030910105732.GA23981@mkdoc.com>

Hey Evan,


I'm not really sure I really understand what this is all about. I
remember a ZPT undocumented feature which allowed paths as follows:

  /path/with/?variable

How does it relates to prefixes?


I've also been thinking about how to implement METAL. Ideally I would
like to do this incrementally, on top of Petal's existing include
mechanism.

So I need to figure out a one to one mapping between METAL macros and
Petal include mechanism.

As far as I understand, if a file (let's call it foo.xml) contained a
METAL define-macro="bar" instruction then Petal would have to look at
this XML fragment as a virtual file called 'foo/bar'. Or should it be
'foo.xml/bar' ?

Reversely, would metal:use-macro="somemacro" map to Petal's
<?include file="somemacro.xml" ?>

How about metal:slot and metal:fill-slot? In which way would I need to
extend Petal's include mechanism to provide equivalent functionality?


Cheers,
Jean-Michel.
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From jhiver at mkdoc.com  Wed Sep 10 13:19:11 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Wed Sep 10 12:19:15 2003
Subject: [Petal] Petal to depend on MKDoc::XML at some point
Message-ID: <20030910111911.GB23981@mkdoc.com>

Hi List,

Sorry for not being too active on Petal these days.

I have been busy refactoring MKDoc XML package and making it a CPAN
module (called MKDoc::XML). This is a very time consuming process since
it needs tests, docs, makefiles and all that.

Once I am happy with MKDoc::XML I indent to write a Petal parser using
MKDoc::XML library. I will then remove XML::Parser and HTML::TreeBuilder
dependencies and make them optional modules which can be installed
separately.

The reason for this is:

a/ Petal will be able to run on top of MKDoc::XML set of tools, which
are written in pure perl. The reason for which Petal isn't in
ActiveState repository is because HTML::TreeBuilder isn't, hopefully
it'll fix that.

b/ We plan to open-source more MKDoc code in the future. Both Petal and
MKDoc::XML are part of this will. For consistency it makes sense for
Petal to depend on MKDoc::XML since I think that's doable.

That being said, everything should be backwards compatible.
For those interested there is a MKDoc-XML 0.1 pre-version on CPAN.

Cheers,
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From spurkis at mkdoc.com  Wed Sep 10 13:45:05 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Wed Sep 10 12:45:10 2003
Subject: [Petal] Petal-Utils-0.03 released
Message-ID: <38711A62-E384-11D7-9D1E-003065968BC2@mkdoc.com>

Hi all,

Petal-Utils-0.03 was just uploaded to CPAN and is also available here:

	http://staging.quiup.com/perl/Petal-Utils-0.03.tar.gz

This is a bugfix release, with the following changes:

0.03
   *	Suppressed warnings when loading plugins, introduced $DEBUG flag
	[reported by William McKee, patched by Steve Purkis]
   +	Wrote get_plugin_class() to make inheriting easier. [Steve Purkis]
   *	Date::Format moved to required list of modules as Date plugin is in
	:default set [Steve Purkis]

Thanks to William for spurring me to test the last point.

-Steve

From william at knowmad.com  Wed Sep 10 09:25:49 2003
From: william at knowmad.com (William McKee)
Date: Wed Sep 10 13:25:53 2003
Subject: [Petal] [Utils] Install errors
In-Reply-To: <83D25FDE-E37C-11D7-9D1E-003065968BC2@mkdoc.com>
References: <20030910021026.GD600@knowmad.com>
	<83D25FDE-E37C-11D7-9D1E-003065968BC2@mkdoc.com>
Message-ID: <20030910122549.GG600@knowmad.com>

On Wed, Sep 10, 2003 at 11:49:55AM +0100, Steve Purkis wrote:
> I can honestly say: it's not a bug, it's a feature :-)
> 
> Amongst other things, Module::Build lets you specify 'required' 
> modules, and 'recommended' modules separately.
> 
> Date::Format is recommended, not required.  Only P::Utils::Date uses 
> it, so if you never use the date: modifier, you're not forced to 
> install a module you may never use.

This makes sense but it'd be nice if the CPAN interface would stop and
let me know that P::Utils recommends a module rather than just blasting
past it and failing the tests! In the meantime, it seems like we need to
rewrite the tests to allow for a missing Date::Format module. Is there a
way to check if a module is available and skip the test if not?

William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From william at knowmad.com  Wed Sep 10 09:38:41 2003
From: william at knowmad.com (William McKee)
Date: Wed Sep 10 13:38:45 2003
Subject: [Petal] Petal to depend on MKDoc::XML at some point
In-Reply-To: <20030910111911.GB23981@mkdoc.com>
References: <20030910111911.GB23981@mkdoc.com>
Message-ID: <20030910123841.GI600@knowmad.com>

On Wed, Sep 10, 2003 at 12:19:11PM +0100, Jean-Michel Hiver wrote:
> Sorry for not being too active on Petal these days.

Greetings! I saw the new module in the daily listing but haven't had
time to look into it. Glad to hear you're making headway and will be
returning to Petal again once that project is underway. Hopefully when
you're rebuilding the parser, you can work in some of the TO DO list
items <g>.

I look forward to seeing how MKDoc::XML will be made to parse XML and
HTML template files. I know you've been wanting to move from XML::Parser
to a another method for reading input files. Are you using an existing
library or rolling your own?

Cheers,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From spurkis at mkdoc.com  Wed Sep 10 14:47:37 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Wed Sep 10 13:47:42 2003
Subject: [Petal] [Utils] Install errors
In-Reply-To: <20030910122549.GG600@knowmad.com>
Message-ID: <F4EDD30F-E38C-11D7-9D1E-003065968BC2@mkdoc.com>

On Wednesday, September 10, 2003, at 01:25  pm, William McKee wrote:

> On Wed, Sep 10, 2003 at 11:49:55AM +0100, Steve Purkis wrote:
>> I can honestly say: it's not a bug, it's a feature :-)
>>
>> Amongst other things, Module::Build lets you specify 'required'
>> modules, and 'recommended' modules separately.
>>
>> Date::Format is recommended, not required.  Only P::Utils::Date uses
>> it, so if you never use the date: modifier, you're not forced to
>> install a module you may never use.
>
> This makes sense but it'd be nice if the CPAN interface would stop and
> let me know that P::Utils recommends a module rather than just blasting
> past it and failing the tests! In the meantime, it seems like we need 
> to
> rewrite the tests to allow for a missing Date::Format module. Is there 
> a
> way to check if a module is available and skip the test if not?

Yes, but it looked like too much effort, so now it's required.  Patches 
welcome :)

-Steve

From william at knowmad.com  Wed Sep 10 10:08:15 2003
From: william at knowmad.com (William McKee)
Date: Wed Sep 10 14:08:21 2003
Subject: [Petal] [Utils] Install errors
In-Reply-To: <F4EDD30F-E38C-11D7-9D1E-003065968BC2@mkdoc.com>
References: <20030910122549.GG600@knowmad.com>
	<F4EDD30F-E38C-11D7-9D1E-003065968BC2@mkdoc.com>
Message-ID: <20030910130815.GL600@knowmad.com>

On Wed, Sep 10, 2003 at 01:47:37PM +0100, Steve Purkis wrote:
> Yes, but it looked like too much effort, so now it's required.  Patches 
> welcome :)

I'm all for the path of least resistance in this matter!

William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From evan at 4-am.com  Wed Sep 10 11:54:27 2003
From: evan at 4-am.com (Evan Simpson)
Date: Wed Sep 10 16:54:35 2003
Subject: [Petal] [IDEA] Hash with params
In-Reply-To: <20030910105732.GA23981@mkdoc.com>
References: <049F5842-DFD0-11D7-AF1B-003065968BC2@mkdoc.com>
	<3F58E795.2090003@4-am.com> <20030910105732.GA23981@mkdoc.com>
Message-ID: <3F5F4933.7070502@4-am.com>

Jean-Michel Hiver wrote:
> I'm not really sure I really understand what this is all about. I
> remember a ZPT undocumented feature which allowed paths as follows:
> 
>   /path/with/?variable
> 
> How does it relates to prefixes?

It was a rather half-assed way of doing a specific thing that prefixes 
nicely generalize.  With prefixes, the above can be written as 
"/path/with/var:variable".  I'm not sure how useful the current set of 
builtin prefixes would be in Petal, since they mostly deal with explicit 
control of traversal (as hash key, list index, object attribute, etc), 
and Petal does paths a bit differently.  Using non-builtin prefixes by 
writing 'tal:define="prefix myprefixname ext:a_prefix"', on the other 
hand, allows you to perform arbitrary transformations while traversing a 
path.

> As far as I understand, if a file (let's call it foo.xml) contained a
> METAL define-macro="bar" instruction then Petal would have to look at
> this XML fragment as a virtual file called 'foo/bar'. Or should it be
> 'foo.xml/bar' ?

In the ZPT implementation, all macros defined by a template are accessed 
through a 'macros' collection, so the address would be 
'foo.xml/macros/bar'.  Of course, a ZPT template is an object with 
methods, not just a file, so we have to worry about name clashes.

> Reversely, would metal:use-macro="somemacro" map to Petal's
> <?include file="somemacro.xml" ?>

The argument of metal:use-macro is just a TALES expression, so you would 
need a variable that maps names to files (or file proxy objects) for a 
path expression, or a new TALES expression type that takes a filename 
and a macro name.  Then you could write either 
'metal:use-macro="files/somemacro.xml/macros/bar"' or 
'metal:use-macro="file:somemacro.xml bar"'.

> How about metal:slot and metal:fill-slot? In which way would I need to
> extend Petal's include mechanism to provide equivalent functionality?

Those are tricky.  A metal:define-slot essentially creates a named 
parameter for its macro, along with a default value.  A metal:fill-slot 
passes its statement element to the used macro as an argument for the 
named parameter.  Perhaps you need a new directive like this:

<?include-slots file="somemacro.xml" macro="bar" ?>
<?fill-slot slot="s1" ?><p>some text</p><?/fill-slot ?>
<?/include-slots ?>

Cheers,

Evan @ 4-am

From jhiver at mkdoc.com  Wed Sep 10 23:00:45 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Wed Sep 10 23:00:46 2003
Subject: [Petal] [IDEA] Hash with params
In-Reply-To: <3F5F4933.7070502@4-am.com>
References: <049F5842-DFD0-11D7-AF1B-003065968BC2@mkdoc.com>
	<3F58E795.2090003@4-am.com> <20030910105732.GA23981@mkdoc.com>
	<3F5F4933.7070502@4-am.com>
Message-ID: <1063231452.5978.59.camel@future.webmatrix.net>

> It was a rather half-assed way of doing a specific thing that prefixes 
> nicely generalize.  With prefixes, the above can be written as 
> "/path/with/var:variable".

Gotcha! Brilliant idea. Now that I understand what it is about, I think
it'll be rather easy to implement with Petal. You'll be able to stack
prefixes too, which is a Petal feature suggested by William some time
ago.

It would be nice if this prefix business allowed parameters to be passed
to methods, functionality which I find very useful. I would really like
some kind of formal syntax allowing this kind of stuff in TALES. I guess
prefixes in paths is a nice step in the right direction!


Now some stuff about METAL. I'm still super-confused I am afraid :)

Am I right in seeing METAL as some kind of 'meta-template'?

As far as I can see, define-slot is only really some sort of
'tal:define_variable_with_current_xml_node' while fill-slot boils down
to a 'tal:replace_structure_unless_not_defined'.

define-macro serves as an indentifier. Which makes me think: Why not use
a more standard syntax for XML / HTML fragments in URLs when you do
includes? (i.e. use-macro="my/file.xml#mymacro").

and use-macro is just an include statement, except that it defines all
the fill-slot variables before doing the includes.

Have I got it right?


If / When this is implemented with Petal, the following macro should be
possible:

<ul tal:define="child self/root">
  <li metal:define-macro="sitemap_li">
    <a
      href="#"
      hreflang="en"
      lang="en"
      xml:lang="en"
      tal:attributes="href child/Full_Path;
                      hreflang child/Lang;
                      lang child/Lang;
                      xml:lang child/Lang"
      tal:content="child/Title"
    >Child Document Title</a>
    <ul
      petal:define="children child/Children"
      petal:condition="children"
      petal:repeat="child children"
    >
      <li metal:use-macro="#sitemap_li" />
    </ul>
  </li>
</ul>


Cheers,
Jean-Michel.
From jhiver at mkdoc.com  Wed Sep 10 23:07:40 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Wed Sep 10 23:07:40 2003
Subject: [Petal] Petal to depend on MKDoc::XML at some point
In-Reply-To: <20030910123841.GI600@knowmad.com>
References: <20030910111911.GB23981@mkdoc.com>
	<20030910123841.GI600@knowmad.com>
Message-ID: <1063231873.5978.66.camel@future.webmatrix.net>

> I look forward to seeing how MKDoc::XML will be made to parse XML and
> HTML template files. I know you've been wanting to move from XML::Parser
> to a another method for reading input files. Are you using an existing
> library or rolling your own?

MKDoc::XML requires no dependencies. If you wish to discuss this module
further I invite you to read the CPAN docs, there is an address pointing
to the mkdoc-modules mailing list :)

Cheers,
Jean-Michel.
From evan at 4-am.com  Wed Sep 10 22:01:32 2003
From: evan at 4-am.com (Evan Simpson)
Date: Thu Sep 11 03:01:37 2003
Subject: [Petal] [IDEA] Hash with params
In-Reply-To: <1063231452.5978.59.camel@future.webmatrix.net>
References: <049F5842-DFD0-11D7-AF1B-003065968BC2@mkdoc.com>	
	<3F58E795.2090003@4-am.com> <20030910105732.GA23981@mkdoc.com>	
	<3F5F4933.7070502@4-am.com>
	<1063231452.5978.59.camel@future.webmatrix.net>
Message-ID: <3F5FD77C.9030406@4-am.com>

Jean-Michel Hiver wrote:
> Gotcha! Brilliant idea. Now that I understand what it is about, I think
> it'll be rather easy to implement with Petal. You'll be able to stack
> prefixes too, which is a Petal feature suggested by William some time
> ago.

Thanks, but I'm not sure what you mean by "stacking".  It's certainly 
valid to write something like "x/var:y/item:0/key:fred", if that's what 
you're getting at.

> It would be nice if this prefix business allowed parameters to be passed
> to methods, functionality which I find very useful. I would really like
> some kind of formal syntax allowing this kind of stuff in TALES. I guess
> prefixes in paths is a nice step in the right direction!

There's a builtin 'call' prefix in the ZPT implementation.  It accepts a 
list of variable names to pass as positional arguments to the current 
object, like so: "mymethod/call:x, y, z".  This doesn't allow for named 
arguments or expressions, but parsing is easy.

> Am I right in seeing METAL as some kind of 'meta-template'?

Well, the name is Macro Expansion TAL, which shows how I see it :-)

> As far as I can see, define-slot is only really some sort of
> 'tal:define_variable_with_current_xml_node' while fill-slot boils down
> to a 'tal:replace_structure_unless_not_defined'.

Except that macro names live in their own namespaces, completely 
separate from variables, and slot names are merely markers for nodes. 
The abstract idea is that the template and macros are combined into a 
notional intermedate template, which is then executed.  That's not how 
we implement it, of course.

> define-macro serves as an indentifier. Which makes me think: Why not use
> a more standard syntax for XML / HTML fragments in URLs when you do
> includes? (i.e. use-macro="my/file.xml#mymacro").

Because we tried to use as little syntax as possible, and 
".../macros/mymacro" is very natural in a Zope context.  YMMV, of course.

> and use-macro is just an include statement, except that it defines all
> the fill-slot variables before doing the includes.
> 
> Have I got it right?

Given a loose definition of "variables", yes.

> If / When this is implemented with Petal, the following macro should be
> possible:
> 
> <ul tal:define="child self/root">
>   <li metal:define-macro="sitemap_li">
>     <a
>       href="#"
>       hreflang="en"
>       lang="en"
>       xml:lang="en"
>       tal:attributes="href child/Full_Path;
>                       hreflang child/Lang;
>                       lang child/Lang;
>                       xml:lang child/Lang"
>       tal:content="child/Title"
>     >Child Document Title</a>
>     <ul
>       petal:define="children child/Children"
>       petal:condition="children"
>       petal:repeat="child children"
>     >
>       <li metal:use-macro="#sitemap_li" />
>     </ul>
>   </li>
> </ul>

Yipe!  That looks infinitely recursive to me.  Did you really mean to 
use the macro inside its own definition?

Cheers,

Evan @ 4-am

From jhiver at mkdoc.com  Thu Sep 11 10:08:00 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Thu Sep 11 10:08:01 2003
Subject: [Petal] [IDEA] Hash with params
In-Reply-To: <3F5FD77C.9030406@4-am.com>
References: <049F5842-DFD0-11D7-AF1B-003065968BC2@mkdoc.com>
	<3F58E795.2090003@4-am.com> <20030910105732.GA23981@mkdoc.com>
	<3F5F4933.7070502@4-am.com>
	<1063231452.5978.59.camel@future.webmatrix.net>
	<3F5FD77C.9030406@4-am.com>
Message-ID: <1063271493.7880.10.camel@future.webmatrix.net>

On Thu, 2003-09-11 at 03:01, Evan Simpson wrote:
> Jean-Michel Hiver wrote:
> > Gotcha! Brilliant idea. Now that I understand what it is about, I think
> > it'll be rather easy to implement with Petal. You'll be able to stack
> > prefixes too, which is a Petal feature suggested by William some time
> > ago.
> 
> Thanks, but I'm not sure what you mean by "stacking".  It's certainly 
> valid to write something like "x/var:y/item:0/key:fred", if that's what 
> you're getting at.

I was meaning for example x/prefix1:prefix2:stuff


> Except that macro names live in their own namespaces, completely 
> separate from variables, and slot names are merely markers for nodes. 
> The abstract idea is that the template and macros are combined into a 
> notional intermedate template, which is then executed.

OK.


> That's not how we implement it, of course.

?


> > define-macro serves as an indentifier. Which makes me think: Why not use
> > a more standard syntax for XML / HTML fragments in URLs when you do
> > includes? (i.e. use-macro="my/file.xml#mymacro").
> 
> Because we tried to use as little syntax as possible, and 
> ".../macros/mymacro" is very natural in a Zope context.  YMMV, of course.

Mhhh. I don't know about this. When I implement METAL I might break the
specification regarding this syntax. Mind you it wouldn't be the first
time :)


> > If / When this is implemented with Petal, the following macro should be
> > possible:
> > 
> > <ul tal:define="child self/root">
> >   <li metal:define-macro="sitemap_li">
> >     <a
> >       href="#"
> >       hreflang="en"
> >       lang="en"
> >       xml:lang="en"
> >       tal:attributes="href child/Full_Path;
> >                       hreflang child/Lang;
> >                       lang child/Lang;
> >                       xml:lang child/Lang"
> >       tal:content="child/Title"
> >     >Child Document Title</a>
> >     <ul
> >       petal:define="children child/Children"
> >       petal:condition="children"
> >       petal:repeat="child children"
> >     >
> >       <li metal:use-macro="#sitemap_li" />
> >     </ul>
> >   </li>
> > </ul>
> 
> Yipe!  That looks infinitely recursive to me.  Did you really mean to 
> use the macro inside its own definition?

Well, when building any kind of include mechanism you have two options:

a/ Expand all the includes and then run the template
b/ Expand the includes at run-time

Petal uses the latter. So if METAL was built upon Petal includes, this
example above would work.

Cheers,
Jean-Michel.
From spurkis at mkdoc.com  Thu Sep 11 13:18:44 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Thu Sep 11 12:18:47 2003
Subject: [Petal] [rfc] if: ... then: ... else: ... modifier
Message-ID: <B4A15766-E449-11D7-8D99-003065968BC2@mkdoc.com>

Hi all,

If there are no objections, I'll add an 'if:' modifier to the 
Petal-Utils packages.  Here's an example of its use:

	<div petal:set="search_page like: request/uri ^/search.html"
	     petal:set="editor_page like: request/uri ^/edit/">

		<a petal:attributes="class if: search_page then: string: nav-selected 
else: string: nav-unselected"
		   href="/search.html" class="nav">Search</a>
		<a petal:attributes="class if: editor_page then: string: nav-selected 
else: string: nav-unselected"
		   href="/edit/index.html" class="nav">Search</a>

	</div>

The code for this is below.

-Steve

BEGIN{
package Petal::Utils::If;

use Carp;

use base qw( Petal::Utils::Base );
use constant name    => 'if';
use constant aliases => qw();

use Petal::Utils qw();
$Petal::Utils::DEBUG = 1;
push @{$Petal::Utils::PLUGIN_SET{':logic'}}, 'If';

sub process {
     my $class = shift;
     my $hash  = shift;
     my $args  = shift || confess( "'if' expects args of the form 'if: 
... then: ... [else: ...]' (got nothing)!" );

     my @args = $args =~ /\A(.+?)\sthen:\s+(.+?)(?:\s+else:\s+(.+?))?\z/;
     confess( "'if' expects arguments of the form: 'if: ... then: ... 
[else: ...]', not 'if: $args'!" ) unless @args;
     $args[0] || confess( "1st arg to 'if' should be an expression (got 
nothing)!" );
     $args[1] || confess( "2nd arg to 'if' (after then:) should be an 
expression (got nothing)!" );

     return $hash->fetch($args[1]) if $hash->fetch($args[0]);
     return $hash->fetch($args[2]) if $args[2];
     return '';
}

}

From jhiver at mkdoc.com  Thu Sep 11 13:28:12 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Thu Sep 11 12:28:18 2003
Subject: [Petal] [rfc] if: ... then: ... else: ... modifier
In-Reply-To: <B4A15766-E449-11D7-8D99-003065968BC2@mkdoc.com>
References: <B4A15766-E449-11D7-8D99-003065968BC2@mkdoc.com>
Message-ID: <20030911112812.GA26291@mkdoc.com>

> <a
>   petal:attributes="class if: search_page then: string: nav-selected else: string: nav-unselected"
>   href="/search.html" class="nav">Search</a>

Why not :)

Note that you could do the same as above as follows:

<a petal:condition="true:search_page"
   href="/search.html"
   class="nav-selected">Search</a>

<a petal:condition="false:search_page"
   href="/search.html"
   class="nav-unselected">Search</a>

Which achieves the same thing albeit in a less WYSIWYG-friendly way.
Cheers,
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From william at knowmad.com  Thu Sep 11 08:59:49 2003
From: william at knowmad.com (William McKee)
Date: Thu Sep 11 12:59:53 2003
Subject: [Petal] [rfc] if: ... then: ... else: ... modifier
In-Reply-To: <B4A15766-E449-11D7-8D99-003065968BC2@mkdoc.com>
References: <B4A15766-E449-11D7-8D99-003065968BC2@mkdoc.com>
Message-ID: <20030911115949.GG600@knowmad.com>

Hi Steve,

I have no objections but would like to discuss some design ideas to get
input from the list. I can see where there is some benefit to doing an
if..else statement using modifiers if you are working with designers that
use GUI's. The current method of using petal:if statements causes you to
create two separate navbar Search objects to achieve the desired results.

e.g.,
	<a petal:if="search_page" petal:attributes="class nav-selected"
		href="/search.html" class="nav">Search</a>
	<a petal:if="false: search_page" petal:attributes="class nav-unselected"
		href="/search.html" class="nav">Search</a>

BTW, in your example and thus in mine above, did you mean to include
class in the petal:attr as well as a separate attribute? Will Petal
replace the attribute with the dynamic version?

However, the examples you provide are making TAL start to look
complicated. What if you created a modifier that takes three parameters
and returns the value of the 2nd or 3rd parameter based on the trueness
of the 1st? This is kind of like the ?: if form (what's the name of that
function?).

e.g.,
	<a petal:attributes="if: search_page 'nav-selected'
'nav-unselected'">Search</a>

However, this example brings up a problem I had with the date: modifier
where I was trying to pass in a string to be used as the separator.
Jean-Michel claims I should be able to do it, but I did not have any
luck.

I'm out of town for a week so I'll talk to you on my return.


William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From spurkis at mkdoc.com  Thu Sep 11 15:53:28 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Thu Sep 11 14:53:32 2003
Subject: [Petal] [rfc] if: ... then: ... else: ... modifier
In-Reply-To: <20030911112812.GA26291@mkdoc.com>
Message-ID: <52311F3A-E45F-11D7-8D99-003065968BC2@mkdoc.com>

On Thursday, September 11, 2003, at 12:28  pm, Jean-Michel Hiver wrote:

>> <a
>>   petal:attributes="class if: search_page then: string: nav-selected 
>> else: string: nav-unselected"
>>   href="/search.html" class="nav">Search</a>
>
> Why not :)
>
> Note that you could do the same as above as follows:
>
> <a petal:condition="true:search_page"
>    href="/search.html"
>    class="nav-selected">Search</a>
>
> <a petal:condition="false:search_page"
>    href="/search.html"
>    class="nav-unselected">Search</a>

That's what I had originally, except the html is a lot longer that this 
example.  And then times it by 10, and you find you have to do *loads* 
more work.

Code duplication is a bad thing.

-Steve

From evan at 4-am.com  Thu Sep 11 11:52:48 2003
From: evan at 4-am.com (Evan Simpson)
Date: Thu Sep 11 16:52:53 2003
Subject: [Petal] [IDEA] Hash with params
In-Reply-To: <1063271493.7880.10.camel@future.webmatrix.net>
References: <049F5842-DFD0-11D7-AF1B-003065968BC2@mkdoc.com>	<3F58E795.2090003@4-am.com>
	<20030910105732.GA23981@mkdoc.com>	<3F5F4933.7070502@4-am.com>	<1063231452.5978.59.camel@future.webmatrix.net>	<3F5FD77C.9030406@4-am.com>
	<1063271493.7880.10.camel@future.webmatrix.net>
Message-ID: <3F609A50.7020306@4-am.com>

Jean-Michel Hiver wrote:
> I was meaning for example x/prefix1:prefix2:stuff

That would depend on the implementation of 'prefix1', since it is 
completely responsible for parsing its argument.  If it wants to look 
for '<name>:' and treat it as a sub-prefix, that's fine.  I suppose that 
in Petal it would be less of a problem to allow the path expression 
parser handle stacked prefixes, since you can escape the second colon if 
you want everything after the first colon passed to 'prefix1'.

>>That's not how we implement it, of course.
> 
> ?

ZPTs compile all templates into a sort of bytecode, and create a 
dictionary of defined macros and their slot names at compilation time. 
When 'use-macro' is executed, the bytecode of the macro is called with 
any 'fill-slot' bytecode for matching slot names as parameters.  It's 
all irrelevent to the model, though.

> b/ Expand the includes at run-time

So, you don't plan to support the use of macros inside of macros?  We 
use that all of the time.

Cheers,

Evan @ 4-am

From spurkis at mkdoc.com  Fri Sep 12 15:58:39 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Fri Sep 12 15:05:57 2003
Subject: [Petal] [rfc] if: ... then: ... else: ... modifier
In-Reply-To: <20030911115949.GG600@knowmad.com>
Message-ID: <36593CCC-E529-11D7-8D99-003065968BC2@mkdoc.com>

On Thursday, September 11, 2003, at 12:59  pm, William McKee wrote:

> Hi Steve,
>
> I have no objections but would like to discuss some design ideas to get
> input from the list. I can see where there is some benefit to doing an
> if..else statement using modifiers if you are working with designers 
> that
> use GUI's. The current method of using petal:if statements causes you 
> to
> create two separate navbar Search objects to achieve the desired 
> results.

That's a good point I hadn't thought of.


> e.g.,
> 	<a petal:if="search_page" petal:attributes="class nav-selected"
> 		href="/search.html" class="nav">Search</a>
> 	<a petal:if="false: search_page" petal:attributes="class 
> nav-unselected"
> 		href="/search.html" class="nav">Search</a>
>
> BTW, in your example and thus in mine above, did you mean to include
> class in the petal:attr as well as a separate attribute? Will Petal
> replace the attribute with the dynamic version?

No, that was a typo.  No idea what Petal would do, but I wouldn't rely 
on it anyways.


> However, the examples you provide are making TAL start to look
> complicated. What if you created a modifier that takes three parameters
> and returns the value of the 2nd or 3rd parameter based on the trueness
> of the 1st? This is kind of like the ?: if form (what's the name of 
> that
> function?).

'?:' is the conditional operator...

I agree that 'then:' and 'else:' make the syntax look a bit more 
complex, but it's something I think most people can live with.  The 
main reason for its existence is one of parsing - how do you figure out 
that the first two arguments of this expression:

	<p petal:replace="if: foo/some_method arg1 arg2 then_value 
else_value"/>

should be passed to $foo/some_method ?  Tricky.  If you put arguments 
in quotes as you suggested:

	<p petal:replace="if: 'foo/some_method arg1 arg2' 'then_value' 
'else_value'"/>

you might find yourself breaking other expressions like:

	<p petal:replace="if: 'foo/some_method string: 'literal quotes'' 
'then_value' 'else_value'"/>

and using '?' and ':' is out because ':' is a special char in Petal.  
You could also require the use of '${expr}':

	<p petal:replace="if: ${foo/some_method string: 'literal quotes'} 
${then_value} ${else_value}"/>

which is a valid option I turned down as I thought it was ugly and 
harder to write a regexp for.  So better to just reserve the 'then:' 
and 'else:' modifiers -- come to think of it, they could prolly be 
written as separate modifiers and installed in %Petal::Hash::MODIFIERS. 
  Don't know if you'd gain anything by doing that, though...

If Petal had an expression parser then it would be easier to write 
cleaner extensions.  But that's potentially a lot of work, so I doubt 
it will happen anytime soon. :)


> e.g.,
> 	<a petal:attributes="if: search_page 'nav-selected'
> 'nav-unselected'">Search</a>
>
> However, this example brings up a problem I had with the date: modifier
> where I was trying to pass in a string to be used as the separator.
> Jean-Michel claims I should be able to do it, but I did not have any
> luck.

You should be able to do it with 'string: foo', no?


> I'm out of town for a week so I'll talk to you on my return.

'till then,
-Steve

From spurkis at mkdoc.com  Fri Sep 12 16:53:57 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Fri Sep 12 15:53:59 2003
Subject: [Petal] Petal::Utils-0.04 released
Message-ID: <EF8106AC-E530-11D7-B048-003065968BC2@mkdoc.com>

Hi all,

Petal-Utils-0.04 has just been uploaded to CPAN with the following 
changelog:

     +	Wrote If modifier.
     +	Added TODO file.
     *	Updated INSTALL file.
     +	Added 'use Carp;' to modules that needed it.
     +	Added $VERSION to all modules.

-Steve

From jhiver at mkdoc.com  Fri Sep 19 11:59:09 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Fri Sep 19 10:59:16 2003
Subject: [Petal] Some news
Message-ID: <20030919095909.GA26596@mkdoc.com>

Hey list,

I'm almost done switching Petal parser to MKDoc::XML::TreeBuilder.

I will release the XML::Parser backend and the HTML::TreeBuilder backend
as separate distributions, probably Petal::Parser::HTML_TreeBuilder and
Petal::Parser::XML_Parser.

I am also tempted to upgrade the minimal version of Perl to 5.8.0. This
will allow me to remove a few horrible hacks. If anybody is still using
perl 5.6.x they'll have to stick with Petal 1.06 for a while.

I'll also try to implement path prefixes in this release.

Is this OK with everybody?
Cheers,
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From william at knowmad.com  Fri Sep 19 09:54:45 2003
From: william at knowmad.com (William McKee)
Date: Fri Sep 19 13:54:49 2003
Subject: [Petal] Vote: What version of Perl are you using?
Message-ID: <20030919125445.GI579@knowmad.com>

This is a quick straw poll to find out what version of Perl everyone on
the list is using.

Perl 5.6.1

William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From spurkis at mkdoc.com  Fri Sep 19 15:00:53 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Fri Sep 19 14:00:58 2003
Subject: [Petal] Vote: What version of Perl are you using?
In-Reply-To: <20030919125445.GI579@knowmad.com>
Message-ID: <4D000121-EAA1-11D7-8D0A-003065968BC2@mkdoc.com>

On Friday, September 19, 2003, at 01:54  pm, William McKee wrote:

> This is a quick straw poll to find out what version of Perl everyone on
> the list is using.
>
> Perl 5.6.1

5.8.0, but I think dropping 5.6.1 support in Petal is a *bad* idea.  I 
reckon a lot of companies will think about upgrading to 5.8.1 once it's 
released, but even then I feel Petal should work under 5.6 for as long 
as possible.

-Steve

From william at knowmad.com  Fri Sep 19 10:20:18 2003
From: william at knowmad.com (William McKee)
Date: Fri Sep 19 14:20:29 2003
Subject: [Petal] [rfc] if: ... then: ... else: ... modifier
In-Reply-To: <36593CCC-E529-11D7-8D99-003065968BC2@mkdoc.com>
References: <20030911115949.GG600@knowmad.com>
	<36593CCC-E529-11D7-8D99-003065968BC2@mkdoc.com>
Message-ID: <20030919132018.GL579@knowmad.com>

On Fri, Sep 12, 2003 at 02:58:39PM +0100, Steve Purkis wrote:
> I agree that 'then:' and 'else:' make the syntax look a bit more 
> complex, but it's something I think most people can live with.  The 
> main reason for its existence is one of parsing - how do you figure out 
> that the first two arguments of this expression:

Ok, I can see your logic and agree that it's better to live with the
extra syntax.


> >However, this example brings up a problem I had with the date: modifier
> >where I was trying to pass in a string to be used as the separator.
> >Jean-Michel claims I should be able to do it, but I did not have any
> >luck.
> 
> You should be able to do it with 'string: foo', no?

I get the following parsing error:

Error: Cannot access hash at '' with parameters (near $date3 string:-)
at /usr/local/share/perl/5.6.1/Petal/Hash/Var.pm line 101


You can try it yourself by modifying line 14 in t/data/basic.html and
uncommenting line 89 in t/02__default.t.


William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From spurkis at mkdoc.com  Fri Sep 19 15:27:59 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Fri Sep 19 14:28:04 2003
Subject: [Petal] [rfc] if: ... then: ... else: ... modifier
In-Reply-To: <20030919132018.GL579@knowmad.com>
Message-ID: <161CA79C-EAA5-11D7-8D0A-003065968BC2@mkdoc.com>

On Friday, September 19, 2003, at 02:20  pm, William McKee wrote:

> On Fri, Sep 12, 2003 at 02:58:39PM +0100, Steve Purkis wrote:
>>> However, this example brings up a problem I had with the date: 
>>> modifier
>>> where I was trying to pass in a string to be used as the separator.
>>> Jean-Michel claims I should be able to do it, but I did not have any
>>> luck.
>>
>> You should be able to do it with 'string: foo', no?
>
> I get the following parsing error:
>
> Error: Cannot access hash at '' with parameters (near $date3 string:-)
> at /usr/local/share/perl/5.6.1/Petal/Hash/Var.pm line 101
>
>
> You can try it yourself by modifying line 14 in t/data/basic.html and
> uncommenting line 89 in t/02__default.t.

Hmm..  at a glance I'm not sure why this is happening, and I won't have 
time to look into it today unfortunately.  Have you run it through the 
debugger?

-Steve

From jhiver at mkdoc.com  Fri Sep 19 18:02:58 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Fri Sep 19 17:03:03 2003
Subject: [Petal] Petal 1.10_01 released
Message-ID: <20030919160258.GA3292@mkdoc.com>

Hi List,

I have released Petal 1.10_01.

This is an experimental version. It'll work with Perl 5.8.0 but if too
many people think it should work with Perl 5.6.x series I'll take some
time to get that to work.

It uses the MKDoc::XML backend, so Petal now relies on NO C libraries.
It should be entirely backwards compatible but since I don't want to
break anything I need some volunteers for beta testing before I release
it as Petal 1.10.

Also, I have introduced prefixes in pathes. However this is still a bit
limited since you cannot have spaces or slashes within path expressions,
so:


/path/var:something will work.

However
  /path/var:something/foo

means
  path THEN var:something THEN foo

and not
  path THEN var:something/foo


Again some testing is needed. I have worked hard to bring you this
release, so I hope you enjoy it :)

Cheers,
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From fergal at pop.esatclear.ie  Fri Sep 19 13:05:39 2003
From: fergal at pop.esatclear.ie (fergal@pop.esatclear.ie)
Date: Fri Sep 19 17:05:44 2003
Subject: [Petal] Petal 1.10_01 released
Message-ID: <184670-22003951916539945@M2W053.mail2web.com>

What features of 5.8 are you using that aren't in 5.6? Is it Unicode stuff
or something else?

F


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .


From william at knowmad.com  Fri Sep 19 16:50:46 2003
From: william at knowmad.com (William McKee)
Date: Fri Sep 19 20:50:49 2003
Subject: [Petal] Class::DBI and Petal
Message-ID: <20030919195046.GA579@knowmad.com>

Hi All,

Here's an interesting side effect of the TAL syntax used by Petal that I
thought you might appreciate.

I have just started using Class::DBI in one of my projects. For those
unfamiliar with this module, it's a thin glue over the DBI. I've tried
another package called DBIx::RecordSet and have rolled my own module for
simple database reads and updates in the past. Class::DBI seems to be a
nice compromise between these two options.

Anyhow, I have a loop in one of my templates like so:

<option petal:repeat="rate rates" petal:content="rate/country"
petal:attr="value rate/country">Country</option>

Using my module, I was passing in a list of hash references that looked
like the following:

	{
		'country' => 'AFGHANISTAN'
	},
	{
		'country' => 'ALBANIA'
	},
	....

When I replaced my function that generated the list of countries by a
Class::DBI object, the same template code shown earlier continued to work
without modification even though the list was now populated by objects
instead of hashrefs. This feature appears to be due to the fact that
Class::DBI creates accessors for each fieldname.

You've got to appreciate it when your software "does the right thing."


William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From grant at mclean.net.nz  Sat Sep 20 18:17:44 2003
From: grant at mclean.net.nz (Grant McLean)
Date: Sat Sep 20 06:17:58 2003
Subject: [Petal] Vote: What version of Perl are you using?
In-Reply-To: <20030919125445.GI579@knowmad.com>
References: <20030919125445.GI579@knowmad.com>
Message-ID: <3F6BE2F8.6050806@mclean.net.nz>

William McKee wrote:
> This is a quick straw poll to find out what version of Perl everyone on
> the list is using.
> 
> Perl 5.6.1
> 
> William
> 
Most systems I work with are on 5.6.1

I think bumping the required Perl version to 5.8.0 would be a
significant barrier for many people.

I would guess that Debian 'stable' and RedHat 7.X will be common for
production servers for some time to come and they don't come with Perl 5.8.

I would also guess that many people would use mod_perl to deploy
solutions based around Petal.  For these  people, upgrading Perl would
also require upgrading mod_perl and rebuilding Apache - not 'rocket
surgery' perhaps but also not trivial if you've never done it before.

Grant




From jhiver at mkdoc.com  Mon Sep 22 17:14:34 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Mon Sep 22 16:14:37 2003
Subject: [Petal] [BUG] $self->{base_dir} to absolute paths is not portable
Message-ID: <20030922151434.GA22653@mkdoc.com>

In Petal.pm

  $BASE_DIR = File::Spec->rel2abs ($BASE_DIR)
     if (defined $BASE_DIR and substr ($BASE_DIR, 0, 1) ne '/');
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                               use File::Spec here?

Cheers,
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From william at knowmad.com  Mon Sep 22 13:10:18 2003
From: william at knowmad.com (William McKee)
Date: Mon Sep 22 17:10:23 2003
Subject: [Petal] [BUG] $self->{base_dir} to absolute paths is not portable
In-Reply-To: <20030922151434.GA22653@mkdoc.com>
References: <20030922151434.GA22653@mkdoc.com>
Message-ID: <20030922161018.GF29254@knowmad.com>

On Mon, Sep 22, 2003 at 04:14:34PM +0100, Jean-Michel Hiver wrote:
>   $BASE_DIR = File::Spec->rel2abs ($BASE_DIR)
>      if (defined $BASE_DIR and substr ($BASE_DIR, 0, 1) ne '/');
>                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                                use File::Spec here?

There's also File::Basename which is bundled with Perl (and has been for
several versions I think).

What are you trying to check for in the code snippet? Remember, there is
also Mac to deal with which, I think, can have volume names, not just
drive names as in Win/DOS.

William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From jhiver at mkdoc.com  Wed Sep 24 15:47:47 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Wed Sep 24 14:47:51 2003
Subject: [Petal] 1.10_02 Released
Message-ID: <20030924134747.GA11633@mkdoc.com>

Hi List,

New test release... I've removed the dependency on Encode, although it
might use it if you're running 5.8.x

So... please test! Let me know if anything is wrong. If things are OK
I'll release it as a stable version.

I also released two modules for backwards compatibility:

Petal::Parser::XP  - For XML::Parser
Petal::Parser::HTB - For HTML::TreeBuilder

If for some reason you don't like the default MKDoc::XML parsing, you
can use these modules - they have the same parsing code as in Petal
1.06.

Cheers,
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From spurkis at mkdoc.com  Wed Sep 24 18:16:10 2003
From: spurkis at mkdoc.com (Steve Purkis)
Date: Wed Sep 24 17:20:45 2003
Subject: [Petal] 1.10_02 Released
In-Reply-To: <20030924134747.GA11633@mkdoc.com>
Message-ID: <69389BCA-EEAA-11D7-8473-003065968BC2@mkdoc.com>

On Wednesday, September 24, 2003, at 02:47  pm, Jean-Michel Hiver wrote:

> Hi List,
>
> New test release... I've removed the dependency on Encode, although it
> might use it if you're running 5.8.x

Does that mean it's now compatible with 5.6?


> So... please test! Let me know if anything is wrong. If things are OK
> I'll release it as a stable version.

Hmm.. it might be a better idea to defer that until more people have 
had a chance to test it.  I know I won't get a chance for a couple of 
days at least.


> I also released two modules for backwards compatibility:
>
> Petal::Parser::XP  - For XML::Parser
> Petal::Parser::HTB - For HTML::TreeBuilder
>
> If for some reason you don't like the default MKDoc::XML parsing, you
> can use these modules - they have the same parsing code as in Petal
> 1.06.

Good idea,
-Steve

From william at knowmad.com  Wed Sep 24 19:34:18 2003
From: william at knowmad.com (William McKee)
Date: Wed Sep 24 23:34:24 2003
Subject: [Petal] 1.10_02 Released
In-Reply-To: <69389BCA-EEAA-11D7-8473-003065968BC2@mkdoc.com>
References: <20030924134747.GA11633@mkdoc.com>
	<69389BCA-EEAA-11D7-8473-003065968BC2@mkdoc.com>
Message-ID: <20030924223418.GC29254@knowmad.com>

On Wed, Sep 24, 2003 at 05:16:10PM +0100, Steve Purkis wrote:
> Does that mean it's now compatible with 5.6?

Appears to be. Besides several warning messages and one failed test due
to no test case being run (041_Entities; see below for details), I had
no trouble testing and installing the module on my Linux workstation
with Perl 5.6.1. I haven't put it into use yet; just tested. Need a few
more days to put it onto a test server.

William


Test results (for tests that returned errors or warnings):
--------------
t/026_Broken_Loop...........Use of uninitialized value in pattern match
(m//) at /usr/share/perl/5.6.1/File/Spec/Unix.pm line 215.
Use of uninitialized value in pattern match (m//) at
/usr/share/perl/5.6.1/File/Spec/Unix.pm line 215.
Use of uninitialized value in string eq at
/usr/share/perl/5.6.1/File/Spec/Unix.pm line 77.
  <snip>
t/041_Entities..............# No tests run!
t/041_Entities..............dubious                                          
	Test returned status 255 (wstat 65280, 0xff00)
t/042_Path_Prefix...........ok                                               
t/043_Basic.................ok                                               
t/050_Opt_base_dir..........ok 1/16Use of uninitialized value in pattern
match (m//) at /usr/share/perl/5.6.1/File/Spec/Unix.pm line 215.
Use of uninitialized value in pattern match (m//) at
/usr/share/perl/5.6.1/File/Spec/Unix.pm line 215.
Use of uninitialized value in string eq at
/usr/share/perl/5.6.1/File/Spec/Unix.pm line 77.
t/050_Opt_base_dir..........ok                                               
t/051_Opt_in_out............ok 1/5Use of uninitialized value in pattern
match (m//) at /usr/share/perl/5.6.1/File/Spec/Unix.pm line 215.
Use of uninitialized value in pattern match (m//) at
/usr/share/perl/5.6.1/File/Spec/Unix.pm line 215.
Use of uninitialized value in string eq at
/usr/share/perl/5.6.1/File/Spec/Unix.pm line 77.
t/051_Opt_in_out............ok                                               
t/052_Opt_language..........ok 1/9Use of uninitialized value in pattern
match (m//) at /usr/share/perl/5.6.1/File/Spec/Unix.pm line 215.
Use of uninitialized value in pattern match (m//) at
/usr/share/perl/5.6.1/File/Spec/Unix.pm line 215.
Use of uninitialized value in string eq at
/usr/share/perl/5.6.1/File/Spec/Unix.pm line 77.
t/052_Opt_language..........ok                                               
t/053_Opt_taint.............ok                                               
t/054_Opt_cache.............ok                                               
t/055_Opt_maxinc............ok 4/10Use of uninitialized value in pattern
match (m//) at /usr/share/perl/5.6.1/File/Spec/Unix.pm line 215.
Use of uninitialized value in pattern match (m//) at
/usr/share/perl/5.6.1/File/Spec/Unix.pm line 215.
Use of uninitialized value in string eq at
/usr/share/perl/5.6.1/File/Spec/Unix.pm line 77.


-- 
Knowmad Services Inc.
http://www.knowmad.com
From jhiver at mkdoc.com  Thu Sep 25 13:04:35 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Thu Sep 25 12:04:39 2003
Subject: [Petal] 1.10_03 Released
Message-ID: <20030925110435.GA17547@mkdoc.com>

Fixed test errors raised by William. Let me know how it goes :)

-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From william at knowmad.com  Thu Sep 25 12:32:10 2003
From: william at knowmad.com (William McKee)
Date: Thu Sep 25 16:32:15 2003
Subject: [Petal] 1.10_02 Released
In-Reply-To: <20030924134747.GA11633@mkdoc.com>
References: <20030924134747.GA11633@mkdoc.com>
Message-ID: <20030925153210.GN29254@knowmad.com>

On Wed, Sep 24, 2003 at 02:47:47PM +0100, Jean-Michel Hiver wrote:
> I also released two modules for backwards compatibility:
> 
> Petal::Parser::XP  - For XML::Parser
> Petal::Parser::HTB - For HTML::TreeBuilder
> 
> If for some reason you don't like the default MKDoc::XML parsing, you
> can use these modules - they have the same parsing code as in Petal
> 1.06.

I'm glad these are available since my HTML templates are not XML
well-formed and are thus failing. Since I have lots of existing
templates that are most likely invalid XML I'll need to fall back to
using HTML::TreeBuilder for these projects. What do I need to do to
enable my projects to use these alternate parsers? I don't see any info
in the docs on doing this.

Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com
From bug-Petal-Parser-HTB at rt.cpan.org  Fri Sep 26 15:36:59 2003
From: bug-Petal-Parser-HTB at rt.cpan.org (Guest via RT)
Date: Tue Sep 30 13:14:18 2003
Subject: [Petal] [cpan #3880] make test errors 
In-Reply-To: <rt-3880@cpan>
Message-ID: <rt-3880-11223.9.88039160881321@cpan.org>


This message about Petal-Parser-HTB was sent to you by guest <> via rt.cpan.org

Full context and any attached attachments can be found at:
<URL: https://rt.cpan.org/Ticket/Display.html?id=3880 >

Jean-Michel,

While installing Petal::Parser::HTB on my system (Linux with Perl 5.6.1), I received the following errors which looks similar to those I received when installing MKDoc:

t/041_Entities..............# No tests run!
t/041_Entities..............dubious                                          
	Test returned status 255 (wstat 65280, 0xff00)
t/042_Path_Prefix...........NOK 1#     Failed test (t/042_Path_Prefix.t at line 17)
#                   '<hello></hello>'
#     doesn't match '(?-xism:success)'
# Looks like you failed 1 tests of 1.
t/042_Path_Prefix...........dubious                                          
	Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
	Failed 1/1 tests, 0.00% okay


Thanks,
William
From jhiver at mkdoc.com  Tue Sep 30 14:22:12 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Tue Sep 30 13:22:15 2003
Subject: [Petal] New releases
Message-ID: <20030930122212.GA11293@mkdoc.com>

Please note that the following modules should be on CPAN shortly:

Petal-1.10_05
Petal-Parser-XP-1.02
Petal-Parser-HTB-1.02

These should fix the Perl 5.6.1 issues which have been raised by
William.

Also, because of the experimental 'prefix in paths' feature, there was
an infinite recursion when using non-existent modifiers, which has been
fixed.

Enjoy,
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/