Thread: [htmltmpl] HTML::Template v2.7 is Coming!
Brought to you by:
samtregar
From: Sam T. <sa...@tr...> - 2004-06-17 19:18:20
|
Hello all. I'm sure it will come as a great shock, but I'm planning to make a new release of HTML::Template sometime next week. Here is what I have so far: - Bug Fix: Improved cache keying to be sensitive to options which alter the compilation of templates (path, search_path, loop_context_vars and global_vars). Calls to new() with different settings for any of these options will no longer pull incorrect cached objects. - Bug Fix: Added code to detect broken Perl 5.8.0 utf-8 during installation (i.e. Redhat 8 and 9). - Bug Fix: Fixed parsing of ESCAPE='URL' (Paul Baker) It's that first one that's stimulating this release. However, I know a number of you have pending bugs and (shudder) new features that you'd like to see addressed in the next release. Now is the time to get them in for 2.7. If you're submitting a bug report please include a complete test case that demonstrates the problem. For extra points make it a patch to test.pl in CVS. If you're submitting a patch, please make it against CVS if you can. If not then please make sure it was made against the 2.6 release. Thanks! -sam |
From: Gabor S. <ga...@pe...> - 2004-06-17 20:24:41
|
Hi Sam, if you don't mind to include a Test::More dependency then I'd be glad to send you an additional (or replacement) test suit using Test::More. It will fix a number of issues with the current test suit staring from the fact that the number of tests is not correct in test.pl till the capability to get test coverage using Devel::Cover. If you let me do this then I can actually add further tests to have better coverage of the whole distribution. regards Gabor |
From: Cees H. <ce...@si...> - 2004-06-17 21:47:27
|
Sam Tregar wrote: > Hello all. I'm sure it will come as a great shock, but I'm planning > to make a new release of HTML::Template sometime next week. Here is > what I have so far: > > - Bug Fix: Improved cache keying to be sensitive to options which > alter the compilation of templates (path, search_path, > loop_context_vars and global_vars). Calls to new() with > different settings for any of these options will no longer pull > incorrect cached objects. Hi Sam, It's 2 years late for me, but still a welcome addition ;) http://bluedot.net/mail/archive/read.php?f=9&i=2530&t=2514 I worked around my problem in a different way, so I never brought it up again. I am guessing that you pulled out the key generation code into a subroutine that can be overridden in a subclass? That will allow for added flexibility with the filter support and caching, which is what sparked the discussion I linked to above (ie filters that dynamically alter the template based on external parameters could not be cached since the filter is only applied the first time). Cheers, Cees |
From: Sam T. <sa...@tr...> - 2004-06-17 22:21:09
|
On Thu, 17 Jun 2004, Cees Hek wrote: > I am guessing that you pulled out the key generation code into a > subroutine that can be overridden in a subclass? That will allow for > added flexibility with the filter support and caching, which is what > sparked the discussion I linked to above (ie filters that dynamically > alter the template based on external parameters could not be cached > since the filter is only applied the first time). You're right, I did. There's a new method _cache_key() which could be overridden in a sub-class to manipulate the cache key. -sam |
From: Mathew R. <mat...@re...> - 2004-06-18 00:24:45
|
hmm... general perl-ism is to use a leading underscore to refer to the = method call as being private. Mathew ----- Original Message -----=20 From: "Sam Tregar" <sa...@tr...> To: "Cees Hek" <ce...@si...> Cc: <htm...@li...> Sent: Friday, June 18, 2004 8:21 AM Subject: Re: [htmltmpl] HTML::Template v2.7 is Coming! > On Thu, 17 Jun 2004, Cees Hek wrote: >=20 > > I am guessing that you pulled out the key generation code into a > > subroutine that can be overridden in a subclass? That will allow = for > > added flexibility with the filter support and caching, which is what > > sparked the discussion I linked to above (ie filters that = dynamically > > alter the template based on external parameters could not be cached > > since the filter is only applied the first time). >=20 > You're right, I did. There's a new method _cache_key() which could be > overridden in a sub-class to manipulate the cache key. >=20 > -sam >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, = CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code = NWMGYKND > _______________________________________________ > Html-template-users mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/html-template-users > |
From: Sam T. <sa...@tr...> - 2004-06-18 00:28:09
|
On Fri, 18 Jun 2004, Mathew Robertson wrote: > hmm... general perl-ism is to use a leading underscore to refer to > the method call as being private. Yup, that's right. It is private. But since when has that stopped Cees? -sam |
From: Sam T. <sa...@tr...> - 2004-06-17 22:19:37
|
On Thu, 17 Jun 2004, Gabor Szabo wrote: > if you don't mind to include a Test::More dependency then > I'd be glad to send you an additional (or replacement) > test suit using Test::More. I don't think so. It's not that I mind a Test::More dependency - lots of my modules use Test::More - but that I'm not interested in investing the time it would take a to be sure that the new test suite was as good as the old one. Since the tests don't have tests themselves it's very expensive (in terms of time) to refactor them. -sam |
From: Mathew R. <mat...@re...> - 2004-06-18 01:21:42
|
> > hmm... general perl-ism is to use a leading underscore to refer to > > the method call as being private. >=20 > Yup, that's right. It is private. But since when has that stopped = Cees? :-) ok - I was under the impression that the purpose of the _cache_key = method was to all a custom cache key capability - in which case the = method should be public. my $0.03 Mathew |
From: Sam T. <sa...@tr...> - 2004-06-18 01:52:02
|
On Fri, 18 Jun 2004, Mathew Robertson wrote: > > Yup, that's right. It is private. But since when has that stopped Cees? > > :-) > > ok - I was under the impression that the purpose of the _cache_key > method was to all a custom cache key capability - in which case the > method should be public. That's one possible use, but really it's just a natural result of my efforts to fix a flaw in the existing caching system. I didn't add the docs or tests that would be needed to make a real public feature out of it. Ultimately HTML::Template v2 doesn't offer much in terms of official support for sub-classes and extensions. That's a deficiency I intend to address in the perpetually-delayed v3. -sam |
From: Mathew R. <mat...@re...> - 2004-06-18 01:23:51
|
> It's that first one that's stimulating this release. However, I know > a number of you have pending bugs and (shudder) new features that > you'd like to see addressed in the next release. Now is the time to > get them in for 2.7. >=20 > If you're submitting a bug report please include a complete test case > that demonstrates the problem. For extra points make it a patch to > test.pl in CVS. >=20 > If you're submitting a patch, please make it against CVS if you can. > If not then please make sure it was made against the 2.6 release. Would you prefer: a) seperate patches per piece of functionality b) one whole patch c) the whole module - that way you can diff your own changes d) all of above ? Mathew |
From: Sam T. <sa...@tr...> - 2004-06-18 01:53:30
|
On Fri, 18 Jun 2004, Mathew Robertson wrote: > Would you prefer: > a) seperate patches per piece of functionality Yes. That's probably a lot of work though, so you might want to run them by me and let me save you the trouble of creating patches for the ones I won't take. ;) -sam |
From: Mathew R. <mat...@re...> - 2004-06-18 05:56:27
|
> > Would you prefer: > > a) seperate patches per piece of functionality >=20 > Yes. That's probably a lot of work though, so you might want to run > them by me and let me save you the trouble of creating patches for the > ones I won't take. ;) [snip] > Ultimately HTML::Template v2 doesn't offer much in terms of official > support for sub-classes and extensions. That's a deficiency I intend > to address in the perpetually-delayed v3. One of the changes that I made, was so as to support sub-classing. As = far as I can tell, the performance impact has been minimal. Would v2.7 = be a reasonable place to include this type of change (given that the = changes dont change H::T API)? Mathew |
From: Sam T. <sa...@tr...> - 2004-06-18 06:40:25
|
On Fri, 18 Jun 2004, Mathew Robertson wrote: > > Ultimately HTML::Template v2 doesn't offer much in terms of official > > support for sub-classes and extensions. That's a deficiency I intend > > to address in the perpetually-delayed v3. > > One of the changes that I made, was so as to support sub-classing. > As far as I can tell, the performance impact has been minimal. > Would v2.7 be a reasonable place to include this type of change > (given that the changes dont change H::T API)? Can you be more specific? I'm not sure I understand what you're talking about. -sam |
From: Gabor S. <ga...@pe...> - 2004-06-18 08:10:20
Attachments:
99-old.t
new_test_file.diff
|
On Thu, 17 Jun 2004, Sam Tregar wrote: > I don't think so. It's not that I mind a Test::More dependency - lots > of my modules use Test::More - but that I'm not interested in > investing the time it would take a to be sure that the new test suite > was as good as the old one. Since the tests don't have tests > themselves it's very expensive (in terms of time) to refactor them. I mean, keep the old test suit and add a new one covering both the old things and additional things. I am suggesting the following: copy the test.pl file in t/99-old.t or some similar name and change the minimum necessary to cleanly run. Then add further tests in t/01-blabla.t etc. This way you will keep the old test suit in test.pl, add an equal test suit in t/99-old.t and add even more tests in t/01.... Later, once an if you are confident with the new test suit you can remove the test.pl file but this is not necessary. I have already made this addition based on test.pl in the CVS and am I attaching the diff and the new test file for your convenience. There are only a few minor changes 1) the SKIP: label added and the block had to be turned around 2) in several places I got the following warning: "my" variable $template masks earlier declaration in same scope so I removed the my variables here. 3) replacing the plan from 57 to 68 4) replacing use Test by use Test::More After that I ran the whole thing through Devel::Cover and got the following reports: Default: ---------------------------- ------ ------ ------ ------ ------ ------ ------ File stmt branch cond sub pod time total ---------------------------- ------ ------ ------ ------ ------ ------ ------ blib/lib/HTML/Template.pm 84.9 62.8 49.4 84.3 72.2 100.0 73.4 Total 84.9 62.8 49.4 84.3 72.2 100.0 73.4 ---------------------------- ------ ------ ------ ------ ------ ------ ------ With TEST_SHARED_MEMORY=1 ---------------------------- ------ ------ ------ ------ ------ ------ ------ File stmt branch cond sub pod time total ---------------------------- ------ ------ ------ ------ ------ ------ ------ blib/lib/HTML/Template.pm 89.6 66.3 53.7 90.2 72.2 100.0 77.6 Total 89.6 66.3 53.7 90.2 72.2 100.0 77.6 ---------------------------- ------ ------ ------ ------ ------ ------ ------ If you accept this *addition* to the test, I'll be able to add eve more test to increase the coverage of the test suit. (among other things testing the error messages). regards Gabor ps. I know I am pushy. I was told so already. |
From: Sam T. <sa...@tr...> - 2004-06-18 17:01:50
|
On Fri, 18 Jun 2004, Gabor Szabo wrote: > I mean, keep the old test suit and add a new one covering both the old > things and additional things. > > I am suggesting the following: copy the test.pl file in t/99-old.t or > some similar name and change the minimum necessary to cleanly run. Alright, this sounds fine to me. I'm commiting this now. > 3) replacing the plan from 57 to 68 Now that we're using Test::More I'm just going to use no_plan. If you're wondering why, check this out: http://use.perl.org/~samtregar/journal/15751 > ps. I know I am pushy. I was told so already. Don't let it bother you. If you're going to get through to stubborn bastards like me you're going to have to be a little pushy! Thanks, -sam |
From: Gabor S. <ga...@pe...> - 2004-06-18 19:54:46
|
On Fri, 18 Jun 2004, Sam Tregar wrote: > Alright, this sounds fine to me. I'm commiting this now. Oh thanks .... Is this suposed to be the correct CVS ? http://cvs.sourceforge.net/viewcvs.py/html-template/HTML-Template/ I am asking as I have just checked it out again (which took me 30 minutes) and it does not contain the t/ directory yet. > > > 3) replacing the plan from 57 to 68 > > Now that we're using Test::More I'm just going to use no_plan. If > you're wondering why, check this out: > > http://use.perl.org/~samtregar/journal/15751 I remember that and also that I was not convinced back then that no_plan is a good thing. :) Reading it again.... Still not.:) The way I am using this is that during development of a certain area of the code, while I constantly change the test suit, I used no_plan and then when that area was finished and I expected not many changes in that part of the code I changed it to a planned number. I am using this as I had a number of cases when suddenly part of my tests did not run and I did not get any warning about this. Maybe there are better solutions for avoiding this, but I am not aware of them. So what do you say, would such thing work ? - no_plan during the main development of a test suit - plan after it. > > > ps. I know I am pushy. I was told so already. > > Don't let it bother you. If you're going to get through to stubborn > bastards like me you're going to have to be a little pushy! But I think of myself as a nice guy. Someone has to. Right ? Gabor |
From: Sam T. <sa...@tr...> - 2004-06-18 21:23:52
|
On Fri, 18 Jun 2004, Gabor Szabo wrote: > On Fri, 18 Jun 2004, Sam Tregar wrote: > > > Alright, this sounds fine to me. I'm commiting this now. > > Oh thanks .... > Is this suposed to be the correct CVS ? > http://cvs.sourceforge.net/viewcvs.py/html-template/HTML-Template/ > > I am asking as I have just checked it out again (which took me > 30 minutes) and it does not contain the t/ directory yet. That's right, but I think it runs on a delayed update from the real CVS source. > I remember that and also that I was not convinced back then that no_plan > is a good thing. :) > Reading it again.... > Still not.:) Oh well. > I am using this as I had a number of cases when suddenly part of my tests > did not run and I did not get any warning about this. That's very weird. Did your code die() or seg-fault or something? If so Test::Harness should notice and produce a 'dubious' result, not an 'ok'. > So what do you say, would such thing work ? > - no_plan during the main development of a test suit > - plan after it. How about no_plan all the time? I can't stand updating magic numbers. Computers are supposed to do my counting for me! -sam |
From: Gabor S. <ga...@pe...> - 2004-06-19 04:51:50
|
On Fri, 18 Jun 2004, Sam Tregar wrote: > > That's right, but I think it runs on a delayed update from the real > CVS source. yes, I got it a few hours later. > > I am using this as I had a number of cases when suddenly part of my tests > > did not run and I did not get any warning about this. > > That's very weird. Did your code die() or seg-fault or something? If > so Test::Harness should notice and produce a 'dubious' result, not an > 'ok'. I don't know any more but if I encounter the same code again, which I cannot avoid, that's work, I'll try to find it out again what was the issue. > How about no_plan all the time? I can't stand updating magic numbers. OK, I can't have it all my way after all :) > Computers are supposed to do my counting for me! Hmm, they do, but you better tell them up front how long to count :) (I know, you'll say something: till the end of the file) Gabor |