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: http://www.w3.org/TR/xhtml1/#h-4.8 However Petal does not support this, the above is munged into this: 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 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: And comments in the Petal style should be removed: 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 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: do something with $key ... will this get the value: ${some_hash/$key} ? 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: key: $item/key val: $item/val 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: > > do something with $key ... > will this get the value: ${some_hash/$key} ? > 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:

date

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> > > > > do something with $key ... > > will this get the value: ${some_hash/$key} ? > > > > 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: >

date

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 -------------- 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: 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:: 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 => hash key A similar argument would apply to Arrays: list[$idx] = hash key 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: References: <20030905075831.GI600@knowmad.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 => hash key > > A similar argument would apply to Arrays: > > list[$idx] = hash key 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 ". 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: 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: References: <20030905194031.GP600@knowmad.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 => hash key >> A similar argument would apply to Arrays: >> list[$idx] = hash key > > 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 > ". 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: 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 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 . 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: 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: References: <20030910122549.GG600@knowmad.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 > 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:

some text

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: 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: > > 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: > > > > > > 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: 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: 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: References: Message-ID: <20030911112812.GA26291@mkdoc.com> > petal:attributes="class if: search_page then: string: nav-selected else: string: nav-unselected" > href="/search.html" class="nav">Search Why not :) Note that you could do the same as above as follows: Search Search 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: References: 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., Search Search 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., Search 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: >> > petal:attributes="class if: search_page then: string: nav-selected >> else: string: nav-unselected" >> href="/search.html" class="nav">Search > > Why not :) > > Note that you could do the same as above as follows: > > href="/search.html" > class="nav-selected">Search > > href="/search.html" > class="nav-unselected">Search 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 ':' 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., > href="/search.html" class="nav">Search > href="/search.html" class="nav">Search > > 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:

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

you might find yourself breaking other expressions like:

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

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., > Search > > 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: 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: 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. 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: Message-ID: 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: 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) # '' # 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/