Thread: [htmltmpl] Patches for HTML-Template-2.5.tar.gz
Brought to you by:
samtregar
Menu
▾
▴
html-template-users
|
From: Yunliang Yu <yu...@ma...> - 2002-07-24 20:31:48
|
Hi,
Thanks for the wonderful HTML::Template module. I made a few changes while
using it for my projects, hoping these changes will be useful for others:
1. add extended expression support without impact on speed
<TMPL_IF NAME="item ne 'pizza' && price != 0.99">
I got <TMPL_VAR NAME="item"> for
<TMPL_VAR "price * count + 0.5"> dollars.
<TMPL_ELSE>
gee, free pizza!
</TMPL_IF>
2. clean up global_vars implementation
3. add a new way to access outside variables without global_vars
This is a normal variable: <TMPL_VAR NORMAL>.<P>
<TMPL_LOOP NAME=FROOT_LOOP>
Use it inside the loop: <TMPL_VAR __NORMAL><P>
</TMPL_LOOP>
4. TMPL_VAR can now have a default value
<TMPL_VAR NAME="PARAMETER_NAME" VALUE="default value">
5. add TMPL_DEF tag for defining new parameters
<TMPL_DEF NAME="NAME" VALUE="value">
6. add __count__ to loops
<TMPL_VAR NAME="__count__">-th record in the loop.
The patches are available at http://www.math.duke.edu/~yu/Template/
Thanks.
-yu
|
|
From: Sam T. <sa...@tr...> - 2002-07-24 21:24:00
|
On Wed, 24 Jul 2002, Yunliang Yu wrote: > Thanks for the wonderful HTML::Template module. I made a few changes > while using it for my projects, hoping these changes will be useful for > others: Thanks! I hope you don't mind, but I have some mixed feedback for you. Please don't take it the wrong way - your work looks to be of excellent quality. > 1. add extended expression support without impact on speed How did you test the speed of your changes? Did you also check the memory impact? Changing VAR objects from scalars to hashes will probably greatly expand the memory usage of large templates. Also, you're using string eval() to execute expressions. Are you really sure that's faster than HTML::Template::Expr? I wouldn't expect it to be, but I could be wrong. Also, do your changes pass the HTML::Template::Expr test suite? > <TMPL_IF NAME="item ne 'pizza' && price != 0.99"> I really don't like putting expressions into the NAME attribute. I think EXPR, as used in HTML::Template::Expr, is a better choice. > 2. clean up global_vars implementation Why did you force global_vars on for associate? What does explicit_global_vars do exactly? It's not documented. I think I'll need to read your patch a couple more times before I understand exactly how your changes work. Maybe you could give me a summary? > 3. add a new way to access outside variables without global_vars > > This is a normal variable: <TMPL_VAR NORMAL>.<P> > <TMPL_LOOP NAME=FROOT_LOOP> > Use it inside the loop: <TMPL_VAR __NORMAL><P> > </TMPL_LOOP> I really don't like this. How is an HTML designer supposed to understand this bizarre syntax? > 4. TMPL_VAR can now have a default value > > <TMPL_VAR NAME="PARAMETER_NAME" VALUE="default value"> Some people will like this, I imagine. Maybe call it "DEFAULT"? I think I might take this as a separate patch. What do others think? > 5. add TMPL_DEF tag for defining new parameters > > <TMPL_DEF NAME="NAME" VALUE="value"> I don't like this. Mixing display logic with setup of variables is a very dangerous thing. > 6. add __count__ to loops > > <TMPL_VAR NAME="__count__">-th record in the loop. Well, this something people are perpetually asking for, so I suppose I should add it at some point. It's just so easy to do when you need it that I never considered it a priority. Can you send me this one as a separate patch too? Thanks, -sam |
|
From: Kenny S. <ke...@jo...> - 2002-07-24 21:57:42
|
Hi Sam, I don't know if you wanted external feedback on all of the bits, or just the one you explicitly asked for... but, I generally overshare, so here ya go... > > <TMPL_IF NAME="item ne 'pizza' && price != 0.99"> > I really don't like putting expressions into the NAME attribute. I think > EXPR, as used in HTML::Template::Expr, is a better choice. I'd have to agree, there shouldn't be a need to make the name of a variable into a variable. >> 3. add a new way to access outside variables without global_vars >> >> This is a normal variable: <TMPL_VAR NORMAL>.<P> >> <TMPL_LOOP NAME=FROOT_LOOP> >> Use it inside the loop: <TMPL_VAR __NORMAL><P> >> </TMPL_LOOP> > I really don't like this. How is an HTML designer supposed to understand > this bizarre syntax? I have to agree with that. Teaching an HTML designer the concept of variable scope is a dangerous proposition. > Some people will like this, I imagine. Maybe call it "DEFAULT"? I think > I might take this as a separate patch. What do others think? I think a DEFAULT="" is a great idea. >> 5. add TMPL_DEF tag for defining new parameters >> >> <TMPL_DEF NAME="NAME" VALUE="value"> >I don't like this. Mixing display logic with setup of variables is a very >dangerous thing. I don't even know what this is really useful for? If you are hard coding the definition of a variable in your template, why can't you just hard code that variable where you use it? Kenny Smith JournalScape.com |
|
From: Cees H. <ce...@si...> - 2002-07-24 23:21:44
|
Quoting Kenny Smith <ke...@jo...>: > >> 5. add TMPL_DEF tag for defining new parameters > >> > >> <TMPL_DEF NAME="NAME" VALUE="value"> > > >I don't like this. Mixing display logic with setup of variables is a very > >dangerous thing. > > I don't even know what this is really useful for? If you are hard coding > the > definition of a variable in your template, why can't you just hard code > that > variable where you use it? You can simulate most of this functionality already with the TMPL_INCLUDE directive. Just create a new file with just the value of your template variable, and then TMPL_INCLUDE it wherever you want it. This has the added speed benefit of being done before Caching takes place. This would get messy if you have a lot of these constructs though, and they wouldn't be available for use in TMPL_IF or TMPL_LOOP statements. On that note, I would not recommend adding this feature in... Cees |
|
From: Andrew Ho <an...@te...> - 2002-07-30 07:02:36
|
Hello, YY><TMPL_DEF NAME="NAME" VALUE="value"> ST>I don't like this. Mixing display logic with setup of variables is a ST>very dangerous thing. KS>I don't even know what this is really useful for? If you are hard coding KS>the definition of a variable in your template, why can't you just hard KS>code that variable where you use it? I hacked in support for exactly this functionality using a filter, so let me explain why you can't do that. Pretend you have a header.tmpl that has several different tabs on it, where one is highlighted and the others are not highlighted. It is easiest to write this as a single HTML::Template template and have a bunch of <TMPL_IF>s based on a <TMPL_VAR>. That <TMPL_VAR>, say it's called "where", says where you are (like "aboutus" or "companynews" or whatever) in the site. Now, many templates include header.tmpl. The HTML::Template model encourages HTML designers to be separate from coders. Say the site layout changes, like, the tabs get changed around. About us and company news go under the same tab which is called "Company Buzz" or something. A whole lot of HTML needs to be rewritten, but all the backend scripts are the same. Without being able to set a value in a template, you have to change backend scripts to enact this change, even though nothing in those templates needs to change. If there is a customer feedback script called feedback.cgi, your CGI programmer needs to care about the site layout and design to pass in a variable. You will run into similar problems all the time if you design your app using an MVC style. Does this help shed some light on why this functionality is desireable? Humbly, Andrew ---------------------------------------------------------------------- Andrew Ho http://www.tellme.com/ an...@te... Engineer in...@te... Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELL Fax 650-930-9101 ---------------------------------------------------------------------- |
|
From: Kenny P. <py...@ve...> - 2002-07-30 18:50:53
|
Andrew,
Without being able to set a value in a template, you have to change
backend scripts to enact this change, even though nothing in those
templates needs to change. If there is a customer feedback script called
feedback.cgi, your CGI programmer needs to care about the site layout and
design to pass in a variable.
You will run into similar problems all the time if you design your app
using an MVC style.
Does this help shed some light on why this functionality is desireable?
It sounds like you are changing the functionality of the
application when you make a change to the feedback template.
A simple mail-form script would not need changed when you update
the html form template if it is written correctly. If you are using a
mail-form script and you have to update your "backend" then I suggest
you re-write your mail script to be dynamic based on what is in the CGI
object. If you are familiar with the associate feature in
HTML::Template you will not have to worry about the way the form data is
passed from form to form unless you have to act on the input. In that
case, of course you would need to change the backend to work in the new
way.
Do you use CGI::Application? You do not need to worry about the
layout of the template nor do you want to set values in the template.
You have to break your paradigm. I highly suggest looking into
CGI::App. It is a great way to use HTML::Template and would help you
gain more control over your apps.
Humbly,
Andrew
----------------------------------------------------------------------
Andrew Ho http://www.tellme.com/ an...@te...
Engineer in...@te... Voice 650-930-9062
Tellme Networks, Inc. 1-800-555-TELL Fax 650-930-9101
----------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
Html-template-users mailing list
Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users
Thanks,
Kenny Pyatt
President
Venzia
www.venzia.com
|
|
From: simran <sim...@le...> - 2002-07-24 23:40:25
|
On Thu, 2002-07-25 at 05:20, Sam Tregar wrote:
> On Wed, 24 Jul 2002, Yunliang Yu wrote:
>
> > 4. TMPL_VAR can now have a default value
> >
> > <TMPL_VAR NAME="PARAMETER_NAME" VALUE="default value">
>
> Some people will like this, I imagine. Maybe call it "DEFAULT"? I think
> I might take this as a separate patch. What do others think?
This one sounds like a brilliant idea.
Its looks like a short form for:
<tmpl_unless name="param_name">my_default</tmpl_unless>
changes to:
<tmpl_var name="param_name" value="my_default">
It would certainly make some templates a lot cleaner.
> > 6. add __count__ to loops
> >
> > <TMPL_VAR NAME="__count__">-th record in the loop.
>
> Well, this something people are perpetually asking for, so I suppose I
> should add it at some point. It's just so easy to do when you need it
> that I never considered it a priority. Can you send me this one as a
> separate patch too?
>
woohooo :-)
Here is a patch i submitted a whlie ago that does nothing but a
'__counter__' variable if loop_context_vars is set.
*** Template.pm.orig Thu Apr 18 09:25:07 2002
--- Template.pm Thu Apr 18 09:30:56 2002
***************
*** 617,629 ****
default) four loop context variables are made available inside a loop:
__FIRST__, __LAST__, __INNER__, __ODD__. They can be used with
<TMPL_IF>, <TMPL_UNLESS> and <TMPL_ELSE> to control how a loop is
! output. Example:
<TMPL_LOOP NAME="FOO">
<TMPL_IF NAME="__FIRST__">
This only outputs on the first pass.
</TMPL_IF>
<TMPL_IF NAME="__ODD__">
This outputs every other pass, on the odd passes.
</TMPL_IF>
--- 617,636 ----
default) four loop context variables are made available inside a loop:
__FIRST__, __LAST__, __INNER__, __ODD__. They can be used with
<TMPL_IF>, <TMPL_UNLESS> and <TMPL_ELSE> to control how a loop is
! output.
!
! In addition to the above, a __COUNTER__ VAR is also made available
! when loop context variables are turned on.
!
! Examples:
<TMPL_LOOP NAME="FOO">
<TMPL_IF NAME="__FIRST__">
This only outputs on the first pass.
</TMPL_IF>
+ <TMPL_VAR NAME="__COUNTER__">
+
<TMPL_IF NAME="__ODD__">
This outputs every other pass, on the odd passes.
</TMPL_IF>
***************
*** 1860,1869 ****
# die_on_bad_params set output() will might cause errors
# when it tries to set them.
if ($options->{loop_context_vars}) {
! $pmap{__first__} = HTML::Template::VAR->new();
! $pmap{__inner__} = HTML::Template::VAR->new();
! $pmap{__last__} = HTML::Template::VAR->new();
! $pmap{__odd__} = HTML::Template::VAR->new();
}
} elsif ($which eq '/TMPL_LOOP') {
--- 1867,1877 ----
# die_on_bad_params set output() will might cause errors
# when it tries to set them.
if ($options->{loop_context_vars}) {
! $pmap{__first__} = HTML::Template::VAR->new();
! $pmap{__inner__} = HTML::Template::VAR->new();
! $pmap{__last__} = HTML::Template::VAR->new();
! $pmap{__odd__} = HTML::Template::VAR->new();
! $pmap{__counter__} = HTML::Template::VAR->new();
}
} elsif ($which eq '/TMPL_LOOP') {
***************
*** 2731,2741 ****
@{$value_set}{qw(__first__ __inner__ __last__)} = (0,1,0);
}
$odd = $value_set->{__odd__} = not $odd;
}
$template->param($value_set);
$result .= $template->output;
$template->clear_params;
! @{$value_set}{qw(__first__ __last__ __inner__ __odd__)} =
(0,0,0,0)
if ($loop_context_vars);
$count++;
}
--- 2739,2750 ----
@{$value_set}{qw(__first__ __inner__ __last__)} = (0,1,0);
}
$odd = $value_set->{__odd__} = not $odd;
+ $value_set->{__counter__} = $count + 1;
}
$template->param($value_set);
$result .= $template->output;
$template->clear_params;
! @{$value_set}{qw(__first__ __last__ __inner__ __odd__
__counter__)} = (0,0,0,0,0)
if ($loop_context_vars);
$count++;
}
|
|
From: Philip S T. <phi...@gm...> - 2002-07-25 05:07:58
|
On Wed, 24 Jul 2002, Sam Tregar wrote: > > <TMPL_VAR NAME="PARAMETER_NAME" VALUE="default value"> > > Some people will like this, I imagine. Maybe call it "DEFAULT"? I think > I might take this as a separate patch. What do others think? I'd agree with this. the default="" parameter would be quite useful to me. > > 6. add __count__ to loops > > > > <TMPL_VAR NAME="__count__">-th record in the loop. Count is useful in many cases, but would really only be convenience. Not sure if it should be called __COUNT__ or __INDEX__ though. Then of course, we could have __INDEX__ be the record number, and __COUNT__ be the total number of records. Heh. Ok, just kidding. What I would really like to see though is a <tmpl_elseif> and <tmpl_elseunless>. That would really clean up some of my templates that have too many nested ifs. It would specially make sense with multi state scripts that need to show a different body after every step of a form processing, but a lot of common stuff. (Is this what CGI::Application does?) Philip |
|
From: Sam T. <sa...@tr...> - 2002-07-25 06:09:41
|
On Thu, 25 Jul 2002, Philip S Tellis wrote: > What I would really like to see though is a <tmpl_elseif> and > <tmpl_elseunless>. That would really clean up some of my templates that > have too many nested ifs. Mmm.. I've considered it at various points. Each time I decide it would only encourage more complicated logic in the templates. I'm still leaning in that direction although I will admit it's a close call. > It would specially make sense with multi state scripts that need to show > a different body after every step of a form processing, but a lot of > common stuff. I tend to use <tmpl_incldue> with a header.tmpl and a footer.tmpl to deal with that kind of a situation. > (Is this what CGI::Application does?) CGI::Application is a state-management system for CGI is mostly CGI::template-system agnostic. You could use it with a single template for all run-modes or with a template for each. -sam |
|
From: Brian M. <bm...@pa...> - 2002-07-25 16:31:17
|
On Thursday, July 25, 2002, Sam Tregar wrote: | On Thu, 25 Jul 2002, Philip S Tellis wrote: | | > What I would really like to see though is a <tmpl_elseif> and | > <tmpl_elseunless>. That would really clean up some of my templates that | > have too many nested ifs. | | Mmm.. I've considered it at various points. Each time I decide it would | only encourage more complicated logic in the templates. I'm still leaning | in that direction although I will admit it's a close call. [snip] Maybe in HTML::Template::Expr? Just a thought. |
|
From: Sam T. <sa...@tr...> - 2002-07-25 16:35:32
|
On Thu, 25 Jul 2002, Brian McCain wrote: > | On Thu, 25 Jul 2002, Philip S Tellis wrote: > | > | > What I would really like to see though is a <tmpl_elseif> and > | > <tmpl_elseunless>. That would really clean up some of my templates that > | > have too many nested ifs. > | > | Mmm.. I've considered it at various points. Each time I decide it would > | only encourage more complicated logic in the templates. I'm still leaning > | in that direction although I will admit it's a close call. > [snip] > > Maybe in HTML::Template::Expr? > Just a thought. I think that's unlikely to work out. Adding <tmpl_elseif> would require some fairly radical changes to the parser. HTML::Template::Expr just uses HTML::Template's parser and isn't really in the right place to implement something like that. -sam |
|
From: Yunliang Yu <yu...@ma...> - 2002-07-25 14:51:57
|
Hi Sam, thanks for your quick reply. Here I'll try to answer your
questions and clarify a few things.
> > 1. add extended expression support without impact on speed
>
> How did you test the speed of your changes? Did you also check the memory
> impact? Changing VAR objects from scalars to hashes will probably greatly
> expand the memory usage of large templates.
>
> Also, you're using string eval() to execute expressions. Are you really
> sure that's faster than HTML::Template::Expr? I wouldn't expect it to be,
> but I could be wrong. Also, do your changes pass the HTML::Template::Expr
> test suite?
>
> > <TMPL_IF NAME="item ne 'pizza' && price != 0.99">
>
> I really don't like putting expressions into the NAME attribute. I think
> EXPR, as used in HTML::Template::Expr, is a better choice.
I ran a test with a simple template with 2 nested loops last night. For
the first test, the template contains no extended expr, just a few
HTML::Template variables. Here are the results on my test
system (standalone readhat 7.3, timed with 'time wget ....' & averaged,
CGI, results should be similar for mod-perl):
Process with standard HTML::Template 1.52s
Process with my patched version 1.56s
Process with HTML::Template::Expr 2.39s
=> patched version has 2.4% overhead, ::Expr 57% overhead
For the 2nd test, insert <TMPL_VAR EXPR="test ne 'pizza'"> in the inner
loop, btw, the data was pulled from a local mysql server and the loops
returns 432 records.
Process with my patched version 1.88s
Process with HTML::Template::Expr 3.07s
=> HTML::Template::Expr is 63% slower than the patched version.
I didn't test memory usages, but changing "$value" to "->{value}=$value"
adds a hash with only one element and shouldn't have too much impact.
And, I may upload an optimized version today when I get some time.
>
> > 2. clean up global_vars implementation
>
> Why did you force global_vars on for associate? What does
> explicit_global_vars do exactly? It's not documented.
$global_vars and $options->{global_vars} are totally different. Turning on
$global_vars doesn't turn global_vars on. The main reason that I made the
changes is to avoid global_vars and have expr support.
>
> > 3. add a new way to access outside variables without global_vars
> >
> > This is a normal variable: <TMPL_VAR NORMAL>.<P>
> > <TMPL_LOOP NAME=FROOT_LOOP>
> > Use it inside the loop: <TMPL_VAR __NORMAL><P>
> > </TMPL_LOOP>
>
> I really don't like this. How is an HTML designer supposed to understand
> this bizarre syntax?
Our HTML designers seem to do fine. I used to use the ::name notation (as
in C++). The designers we have know zero about perl.
>
> > 4. TMPL_VAR can now have a default value
> >
> > <TMPL_VAR NAME="PARAMETER_NAME" VALUE="default value">
>
> Some people will like this, I imagine. Maybe call it "DEFAULT"? I think
> I might take this as a separate patch. What do others think?
'VALUE=' was chosen so it looks similar to:
<INPUT TEXT NAME="Name" VALUE="Department of Mathematics">
>
> > 5. add TMPL_DEF tag for defining new parameters
> >
> > <TMPL_DEF NAME="NAME" VALUE="value">
>
> I don't like this. Mixing display logic with setup of variables is a very
> dangerous thing.
In one project, every page is designed by users, the programmer can't tell
what data the page wants just by looking at the url. TMPL_DEF is the way
the user passes requests back to the programmer. This way the user can
create any url with any data, and the programmer only computes what's
needed from the backend database. TMPL_DEF was introduced since it has
not output.
>
> > 6. add __count__ to loops
> >
> > <TMPL_VAR NAME="__count__">-th record in the loop.
>
> Well, this something people are perpetually asking for, so I suppose I
> should add it at some point. It's just so easy to do when you need it
> that I never considered it a priority. Can you send me this one as a
> separate patch too?
Best Regards,
-yu
|
|
From: Sam T. <sa...@tr...> - 2002-07-25 16:30:46
|
On Thu, 25 Jul 2002, Yunliang Yu wrote:
> Process with standard HTML::Template 1.52s
> Process with my patched version 1.56s
> Process with HTML::Template::Expr 2.39s
>
> => patched version has 2.4% overhead, ::Expr 57% overhead
Did you enable any caching? I would expect HTML::Template::Expr to lose
with caching off since it has to run a rather expensive parse on every
call.
> I didn't test memory usages, but changing "$value" to "->{value}=$value"
> adds a hash with only one element and shouldn't have too much impact.
Hashes automatically make room for multiple elements on the assumption
that they won't be used to store just one. I think you'll be surprised
how much bigger a one-element hash is!
I think a better implementation of defaulting would put the default onto
the stack ahead of the variable. Then output can just look ahead and see
if the variable is defined to decide whether to output the value.
> > Why did you force global_vars on for associate? What does
> > explicit_global_vars do exactly? It's not documented.
>
> $global_vars and $options->{global_vars} are totally different. Turning on
> $global_vars doesn't turn global_vars on. The main reason that I made the
> changes is to avoid global_vars and have expr support.
I still don't understand.
> 'VALUE=' was chosen so it looks similar to:
> <INPUT TEXT NAME="Name" VALUE="Department of Mathematics">
Well, sure, but it doesn't do the same thing! To me <tmpl_var name=foo
value=bar> looks like the variable foo is being assigned a value of "bar".
Assuming that I would be very surprised to find the tag outputting "baz"
because there's a $template->param(foo => 'baz') in a Perl file somewhere!
To me, DEFAULT gets the provisional nature of the assignment across
better.
> In one project, every page is designed by users, the programmer can't tell
> what data the page wants just by looking at the url. TMPL_DEF is the way
> the user passes requests back to the programmer. This way the user can
> create any url with any data, and the programmer only computes what's
> needed from the backend database. TMPL_DEF was introduced since it has
> not output.
$template->query() can be used for this purpose instead. Just look at the
TMPL_VARs and TMPL_LOOPs that the user is requesting and you'll know what
to provide.
-sam
|
|
From: Yunliang Yu <yu...@ma...> - 2002-07-25 17:00:09
|
Hi Sam, That's a great idea & I'll get it in soon. -yu > > I think a better implementation of defaulting would put the default onto > the stack ahead of the variable. Then output can just look ahead and see > if the variable is defined to decide whether to output the value. > |
|
From: David K. <da...@po...> - 2002-07-25 13:31:53
|
"Sam Tregar" <sa...@tr...> wrote: > > > <TMPL_IF NAME="item ne 'pizza' && price != 0.99"> > > I really don't like putting expressions into the NAME attribute. I think > EXPR, as used in HTML::Template::Expr, is a better choice. i don't like having a complex expression in the value of an attribute called "name", either. if the patch really improves expression evaluation speed, maybe it should be resubmitted as a patch for HTML::Template::Expr? since we who don't use template expressions now can continue to simply not use HTML::Template::Expr, and get the best performance of all :-) > > 3. add a new way to access outside variables without global_vars > > > > This is a normal variable: <TMPL_VAR NORMAL>.<P> > > <TMPL_LOOP NAME=FROOT_LOOP> > > Use it inside the loop: <TMPL_VAR __NORMAL><P> > > </TMPL_LOOP> > > I really don't like this. How is an HTML designer supposed to understand > this bizarre syntax? i can understand the need for a scoping syntax, but i don't like that one. a naming convention is just not a syntax. it is a name restriction! > > 4. TMPL_VAR can now have a default value > > > > <TMPL_VAR NAME="PARAMETER_NAME" VALUE="default value"> > > Some people will like this, I imagine. Maybe call it "DEFAULT"? I think > I might take this as a separate patch. What do others think? i like this. i wouldnt use the attribute VALUE, though. value implies you're *assigning* a value, and you're not, necessarily. you're assigning a value if and only if none is set by perl. i think <TMPL_VAR NAME="PARAMETER_NAME" DEFAULT="default value"> would be more accurate and cause less user confusion. > > 5. add TMPL_DEF tag for defining new parameters > > > > <TMPL_DEF NAME="NAME" VALUE="value"> > > I don't like this. i like it. i've always wanted this. > ...Mixing display logic with setup of variables is a very > dangerous thing. dangerous!, Sam? :-) might it melt the browser or burn the users' fingers? heheh. seriously, though. systems evolve, and programs change. if an html editor who maintains templates can "hard-code" or "override" a variable value in a template in 30 seconds, to alter it in a way that would normally require calling in the original programmer to change perl code, the only "danger" i see is the danger that, by giving the "users" of a system more control over (and therefore more responsibility for) the system, the programmers (us!) might be given LESS control, responsibility, and thus, pay :-) then again, you're right. this is much too dangerous for mere mortals. dev/null the patch :-) > > 6. add __count__ to loops > > > > <TMPL_VAR NAME="__count__">-th record in the loop. > > Well, this something people are perpetually asking for, so I suppose I > should add it at some point. It's just so easy to do when you need it > that I never considered it a priority. Can you send me this one as a > separate patch too? you meant to say that conveniences like this are just so easy FOR A PROGRAMMER to do in perl, when the *programmer* needs it, that we programmers never consider giving lowly users this feature to be a priority. the fact is IMHO features such as this ARE trivial to add when the templates and program are being developed. but those of who define our users (and in many cases our customers) as HTML designers, giving non-programmers the flexibility and power to maintain templates is a large value-add. in many cases we programmers sell a system by saying that "any HTML designer can redesign the look and feel of the program output" by using our "powerful templates". by adding __count__ (and <tmpl default> and <tmpl_def>), i think we work toward making good on those claims, empowering HTML designers to do as much as possible without needing to re-hire us to alter the code. -dave (formerly <dkaufman at vm.com>) |
|
From: Sam T. <sa...@tr...> - 2002-07-25 17:00:34
|
On Thu, 25 Jul 2002, David Kaufman wrote: > i don't like having a complex expression in the value of an attribute called > "name", either. if the patch really improves expression evaluation speed, > maybe it should be resubmitted as a patch for HTML::Template::Expr? since > we who don't use template expressions now can continue to simply not use > HTML::Template::Expr, and get the best performance of all :-) That would be one way to go, but I'll admit I'm hesitent. I went a long way to avoid eval()ing Perl code in HTML::Template:Expr. Maybe that was a mistake but I think I had some good reasons (security, speed, memory usage). > dangerous!, Sam? :-) might it melt the browser or burn the users' fingers? > heheh. seriously, though. systems evolve, and programs change. if an html > editor who maintains templates can "hard-code" or "override" a variable > value in a template in 30 seconds, to alter it in a way that would normally > require calling in the original programmer to change perl code, the only > "danger" i see is the danger that, by giving the "users" of a system more > control over (and therefore more responsibility for) the system, the > programmers (us!) might be given LESS control, responsibility, and thus, pay > :-) You're right - I don't see HTML designers as "users" of the module in the same way that Perl programmers are. I see them as working in an entirely different way - providing formatting for data provided by the Perl programmer. The system, by design, doesn't allow the HTML designer to reconfigure the data structures coming from Perl. This is the price we pay for not having to work with HTML - we do have to work with the data! In my perfect fantasy world each side has its domain, Perl and HTML, and neither should be allowed undo influence on the other. > by adding __count__ (and <tmpl default> and <tmpl_def>), i think we work > toward making good on those claims, empowering HTML designers to do as > much as possible without needing to re-hire us to alter the code. I never made those claims. I see HTML::Template as delivering a collaborative environment between Perl coders and HTML designers. I never envisioned a system where either could "engineered out" at any stage of the development. -sam |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X