html-template-users — Discussion of HTML::Template and related modules

Re: [htmltmpl] A valid reason for template support for select lists?

[Sam T. <sa...@tr...>]

On Sun, 19 Oct 2003, Mark Fuller wrote:

> Do you know of any tutorials, books or how-tos explaining the use of gettext
> in CGIs? For example, are the different locale headings determined
> automatically by the server (from something the browser sends reflecting the
> user's settings?) Or, is it customary to ask the user and do gettext based
> upon their answer?

Sorry, I don't.  Here's what I'd do if I needed to find out:

  1) Search on search.cpan.org.  Possible terms: gettext, i18n, locale.

  2) Post on perlmonks.org.  It's a great place for just about any
     Perl question and I'm sure there's a few i18n gurus hanging
     around.

-sam

Re: [htmltmpl] A valid reason for template support for select lists?

[simran <sim...@re...>]

Have a look at the HTML::FillInForm module as well, i use it quite a lot
in conjunction with HTML::Template to have the right "select fields"
selected - works like a charm.


On Mon, 2003-10-20 at 07:31, Mark Fuller wrote:
> > From: "Sam Tregar" <sa...@tr...>
> > Are you saying you can't do this now?  I've produced <select> boxes
> > with HTML::Template.  It requires a nasty pile of <tmpl_if> logic but
> > it's doable.
> 
> Hi Sam. Yes, I think "tmpl_if" will work. The problem I have is that my
> templates will be organized by spoken language. The english ones in a "en"
> directory. Spanish in "es" directory. My script will determine which
> templates to access depending on the visitor's language preference.
> 
> Now, in a template I might have an option box for "male or female". In
> Spanish, "hombre or mujer." This language difference is kept in the
> template, and an ordinal is used to communicate to the scripts what the
> choice was. Regardless of language, "1" is a male, and "2" is a female. So,
> in this case, it would defeat the strength of templates to call some other
> device to emit the option box. I'd have to store the language text in a
> MySQL table and pass it to the device that will create the option box. I'd
> rather not do that since the text logically belongs in the template instance
> for that language.
> 
> So, yes, I could set a param name for "one" and "two" and "three". Which
> ever is set to boolean true, that would be the option line to get the
> "selected" attribute. But, that seems like a difficult way to do it. The
> conditional test for string value (in template::expression) would be easier.
> I could set a single param to "two" and in the template test for "one" or
> "two" or "three". One param name with different values. It just seemed like
> template::expression gave me *a lot* more things which, at this point, I
> agree are undesireable.
> 
> Now that I think about it, I believe I could set a param name for "one" and
> "two" and "three" but instead of making them true and false (and using an if
> statement) I could set the correct one to "selected" and just let each
> variable be replaced by its value. Only one would have "selected" and it
> would be emitted at the correct option line.
> 
> Do you know if it would be more efficient to set one var and use a
> conditional to determine which option select line to treat differently. Or,
> set many vars and let them all be replaced (to null except one).
> 
> Thanks,
> Mark
> 
> 
> 
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> Linux in the Boardroom; in the Front Office; & in the Server Room 
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

Re: [htmltmpl] A valid reason for template support for select lists?

[Mark F. <mar...@ea...>]

>From: "Sam Tregar" <sa...@tr...>
>
> ... or you need to go to some kind of gettext-style
> i18n database.  You might need that anyway, for error messages and
> other generated text.

I wasn't familiar with that. I've been out reading anything I can find in
search results and I think you're right. I thought templates would be an
efficient way to maintain different languages served by CGIs.

I'm sorry if I'm straying from the charter of this mailing list. But,

Do you know of any tutorials, books or how-tos explaining the use of gettext
in CGIs? For example, are the different locale headings determined
automatically by the server (from something the browser sends reflecting the
user's settings?) Or, is it customary to ask the user and do gettext based
upon their answer?

Thanks!
Mark

Re: [htmltmpl] Phalanx and HTML::Template

[Sam T. <sa...@tr...>]

On Mon, 20 Oct 2003, Gabor Szabo wrote:

> > > 2) use Test::More for these new tests.
> >
> > Why?  That would add a new dependency for the module.  I got enough
> > flak when I started using Test.pm!
>
> That's true and I was a bit worried about it but Test::More is already in
> 5.8.0 and based on a presentation of Schwern and chromatic I understand
> that nearly all the important modules already require it so it is quite
> likely that any user of H:T will already have it in older Perls as well.

I don't want to make existing users of HTML::Template install a new
module just to upgrade HTML::Template.  I did it once when I switched
to Test.pm and I got enough trouble from that!

> The part which is difficult to test is to emulate errors. That's what I
> meant but let's put the above on hold till I get my tests out as I also
> think that most likely it won't be necessary.

It's not difficult to test for errors.  Just feed a bad template and
trap the die() with eval{}.

> - a couple of new files under t/ and tmpl/

Can we have a t/ and still use the existing test.pl?  I have a dim
memory that the two are exclusive...

-sam

Re: [htmltmpl] A valid reason for template support for select lists?

[Sam T. <sa...@tr...>]

On Sun, 19 Oct 2003, Mark Fuller wrote:

> Now, in a template I might have an option box for "male or female". In
> Spanish, "hombre or mujer." This language difference is kept in the
> template, and an ordinal is used to communicate to the scripts what the
> choice was. Regardless of language, "1" is a male, and "2" is a female. So,
> in this case, it would defeat the strength of templates to call some other
> device to emit the option box. I'd have to store the language text in a
> MySQL table and pass it to the device that will create the option box. I'd
> rather not do that since the text logically belongs in the template instance
> for that language.

Sounds like a compelling case for building the <select> in the
template.  Either that or you need to go to some kind of gettext-style
i18n database.  You might need that anyway, for error messages and
other generated text.

> Now that I think about it, I believe I could set a param name for "one" and
> "two" and "three" but instead of making them true and false (and using an if
> statement) I could set the correct one to "selected" and just let each
> variable be replaced by its value. Only one would have "selected" and it
> would be emitted at the correct option line.

That works.  Something like:

  <option value="foo" <tmpl_if foo_selected>selected</tmpl_if>>Foo</option>
  <option value="bar" <tmpl_if bar_selected>selected</tmpl_if>>Bar</option>

Then you just set one "${name}_selected" to 1.

> Do you know if it would be more efficient to set one var and use a
> conditional to determine which option select line to treat differently. Or,
> set many vars and let them all be replaced (to null except one).

If you can avoid using HTML::Template::Expr then you should.  It's
much slower than HTML::Template and uses more memory.  But if you have
to use it anyway then it won't matter much which path you choose.

If you're worried, try both and let Benchmark.pm decide!

-sam

Re: [htmltmpl] A valid reason for template support for select lists?

[Mark F. <mar...@ea...>]

> From: "Sam Tregar" <sa...@tr...>
> Are you saying you can't do this now?  I've produced <select> boxes
> with HTML::Template.  It requires a nasty pile of <tmpl_if> logic but
> it's doable.

Hi Sam. Yes, I think "tmpl_if" will work. The problem I have is that my
templates will be organized by spoken language. The english ones in a "en"
directory. Spanish in "es" directory. My script will determine which
templates to access depending on the visitor's language preference.

Now, in a template I might have an option box for "male or female". In
Spanish, "hombre or mujer." This language difference is kept in the
template, and an ordinal is used to communicate to the scripts what the
choice was. Regardless of language, "1" is a male, and "2" is a female. So,
in this case, it would defeat the strength of templates to call some other
device to emit the option box. I'd have to store the language text in a
MySQL table and pass it to the device that will create the option box. I'd
rather not do that since the text logically belongs in the template instance
for that language.

So, yes, I could set a param name for "one" and "two" and "three". Which
ever is set to boolean true, that would be the option line to get the
"selected" attribute. But, that seems like a difficult way to do it. The
conditional test for string value (in template::expression) would be easier.
I could set a single param to "two" and in the template test for "one" or
"two" or "three". One param name with different values. It just seemed like
template::expression gave me *a lot* more things which, at this point, I
agree are undesireable.

Now that I think about it, I believe I could set a param name for "one" and
"two" and "three" but instead of making them true and false (and using an if
statement) I could set the correct one to "selected" and just let each
variable be replaced by its value. Only one would have "selected" and it
would be emitted at the correct option line.

Do you know if it would be more efficient to set one var and use a
conditional to determine which option select line to treat differently. Or,
set many vars and let them all be replaced (to null except one).

Thanks,
Mark

Re: [htmltmpl] A valid reason for template support for select lists?

[Roger B. W. <ro...@fi...>]

On Sun, Oct 19, 2003 at 12:53:24PM -0700, Mark Fuller wrote:
>I just found html::template and it's exactly what I was looking for. The
>only thing that is a minor shortcoming for me is the inability to do option
>select lists. I understand the emphasis on keeping a template a template
>(and languages separate). But, here's an example of why I believe it is
>justifiable to provide for an "if" inside the variable loop that would emit
>an option list.

You know, you can do it quite easily without extending HTML::Template.

Here's how I do it. Say I have modes "a", "b" and "c", each of which
will produce different text. (Never mind different languages - I use
this trick for whole different pages in a multiscreen application.) Then
I just turn off die_on_bad_params, and set:

$tmpl->param(mode => $mode,
             "mode.$mode" => 1);

Then the template has:

<tmpl_if name=mode.a>
text for mode A
</tmpl_if>
<tmpl_if name=mode.b>
text for mode B
</tmpl_if>

...and so on. You get the idea...

Roger

Re: [htmltmpl] A valid reason for template support for select lists?

[Sam T. <sa...@tr...>]

On Sun, 19 Oct 2003, Mark Fuller wrote:

> I just found html::template and it's exactly what I was looking for. The
> only thing that is a minor shortcoming for me is the inability to do option
> select lists. I understand the emphasis on keeping a template a template
> (and languages separate). But, here's an example of why I believe it is
> justifiable to provide for an "if" inside the variable loop that would emit
> an option list.

Are you saying you can't do this now?  I've produced <select> boxes
with HTML::Template.  It requires a nasty pile of <tmpl_if> logic but
it's doable.

My prefered method is to just use CGI.pm's popup_menu() and use it to
fill a single <tmpl_var>.  I find this results in easily maintainable
code with the minor caveat that the HTML designer won't be able to
easily modify the contents of the <select>.  In practice this isn't
much of a problem; the contents of form controls are usually my job.

> Am I on the right track if I use template::expr inside an options list and
> test at each option to know if I should emit the selected attribute?

Sure, that's another way to do it.

-sam

Re: [htmltmpl] Phalanx and HTML::Template

[Sam T. <sa...@tr...>]

On Fri, 17 Oct 2003, Gabor Szabo wrote:

> Current status v2.6
> -------------------
> There are 57 (actually 60 but the script reports 57) tests.
> Based on the report of Devel::Cover the tests provide a 67.95% code
> coverage.

That seems pretty low.  Is that meant to suggest that 33% of lines of
Perl code aren't executed during the test run?  Maybe you ran the
tests without TEST_SHARED_MEMORY and TEST_FILE_CACHE set?

> 1) Start from the documentation and write tests based
>    on the documentation. (but keep the old tests)

Cool.

> 2) use Test::More for these new tests.

Why?  That would add a new dependency for the module.  I got enough
flak when I started using Test.pm!

> 3) Fix documentation based on your input.

Cool.

> 4) Change the code if necessary to make it easier (or possible)
>    to test.

I'd be surprised if this was necessary.  HTML::Template presents a
nice black box and it's usually pretty easy to feed it a set of inputs
and examine the output.

> I have packaged the changes so far and it is available here:
> http://www.pti.co.il/download/HTML-Template-2.61_01.tar.gz

Could you make this available as a patch with 'diff -Naur'?  That
would make it easier to evaluate the changes at a glance.

-sam

[htmltmpl] A valid reason for template support for select lists?

[Mark F. <mar...@ea...>]

I just found html::template and it's exactly what I was looking for. The
only thing that is a minor shortcoming for me is the inability to do option
select lists. I understand the emphasis on keeping a template a template
(and languages separate). But, here's an example of why I believe it is
justifiable to provide for an "if" inside the variable loop that would emit
an option list.

The reason I like template is that I would like to serve relatively static
pages, many with forms, localized to languages. I'd like to have an "en"
directory for English pages, "es" for Spanish, etc. Static content can be
translated and maintained in those directories. A script can display the
correct language depending on a visitor's language preference. I don't see
any other tools that make it as *easy* to do this as template does.

But, let's say a page will have a form and in that form will be a select
list. Let's say the list is "sex" and the choice is male or female. Across
all the localized pages I intend to use value "1" and "2", but I want the
displayed text to localized (example: "Hombre" or "Mujer" if the templates
in the "es" directory are being processed.)

I believe, to accomplish this I must create a MySQL table named "sexes" and
maintain the relationship between "1" and "2", the language codes, and the
values for the language. Then, in my script I would select the words to
display in the select list and output the entire select list as a variable
to be replaced in the template.

That's not a showstopper for me. It's a valid way to do it too. My only
point is, I don't believe I should have to go through the overhead of
selecting static language-dependent values from a table when I'd be
perfectly happy hard-coding them in the language-specific instances of the
template. They aren't going to change. But, I have to have some way to set
"selected" depending on whether the value is "1" or "2" (my language
independent enumeration).

I believe this is a valid case where the absense of an if requires me to
move template-type information (static) somewhere else. The only thing that
changes is the choice value.

Am I on the right track if I use template::expr inside an options list and
test at each option to know if I should emit the selected attribute?

Anyway, it's a terrific tool. I just wanted to say that it seems like
there's valid uses for some logic in the template and it shouldn't be
disparaged the way a lot of the documentation seems to. (Just my 2-cents. I
love the tool, really!).

Thanks,
Mark

[htmltmpl] Phalanx and HTML::Template

[Gabor S. <ga...@pe...>]

A couple of weeks ago the QA team of perl http://qa.perl.org/
have announce the Phalanx project
http://use.perl.org/article.pl?sid=03/09/26/1829237

They picked 100 modules considered the most important CPAN modules
so these modules will be the starting test suite of Ponie.
For this to be useful they want to increase the test coverage
of these modules as much as possible. (See details at
http://qa.perl.org/phalanx/ ).

The idea is that we want to make sure these modules will be fully
functional on Ponie/Parrot as well. Having large test suits of
important CPAN modules helps the Ponie/Parrot team find their bugs.


As I use it quite a lot, I have volunteered to be the hoplite for
HTML::Template.[1]  Sam has agreed to take in patches if they
are reasonable. Of course this work is not for one person only
so I'd appreciate your participation and help as well.

As Sam probably won't have too much time to work on this I'll
try to make things as simple for him as possible and to ask
to implement the patches only once there is a substantial value in
them.


Current status v2.6
-------------------
There are 57 (actually 60 but the script reports 57) tests.
Based on the report of Devel::Cover the tests provide a 67.95% code
coverage.


My Plans:
1) Start from the documentation and write tests based
   on the documentation. (but keep the old tests)
2) use Test::More for these new tests.
3) Fix documentation based on your input.
4) Change the code if necessary to make it easier (or possible)
   to test.


To make things clear I appreciate the great job done by Sam with
this module and I don't want to take over the module nor want I fork
it. (Though if Sam wants I'll be glad to start to maintain it.)


I have packaged the changes so far and it is available here:
http://www.pti.co.il/download/HTML-Template-2.61_01.tar.gz

I have added a couple of tests, the code and the documentation
has not been changed. I'd appreciate if you downloaded it and
tested it on your system.

Warning: This is not an official Sam Tregar release !

I'd also appreciate further input to this work.

regards
   Gabor Szabo


[1] Actually I am doing similar work for CGI::Application too.

RE: [htmltmpl] using HTML::Template to generate static web pages

[Offer K. <of...@ne...>]

Hi all,
Just wanted to say thanks to everybody who answered. After using H::T
for less than a week I can already say - it is great, I love it! :-)

Thanks again for all your answers,
Offer Kaye

[htmltmpl] Perl CGI authentication and session management

[David C. <dpc...@ho...>]

cg...@li...:

Thilo Planz wrote:
> Everything you send or receive via https is encryted.
> This even includes the HTTP headers, which is why name-based virtual
> hosting does not work with https.

Thanks for your reply. :-)

Okay.


> Depending on how paranoid you are you can also set the "secure
> connection" flag on the cookie, so the cookie will only be send via
> encrypted connections.

Does this work using http?  (A given session may go back and forth
between http and https.)


David

Re: [htmltmpl] producing plain text reports with H::T

[Pete P. <pet...@cy...>]

Kenneth Gonsalves wrote:
> hi,
> i've been playing with H::T to produce formatted plain text reports in an 
> Xwindows based application. Seems to be much more flexible than using perl 
> Formats. So i dont go reinventing the wheel can anyone point me to some tips 
> and tricks to achieve things like centering, right or left justification of 
> fields, line and form feeds etc ?


Hmmm, are you using sprintf already to deal with spacing issues?


Pete

Re: [htmltmpl] Perl CGI authentication and session management

[Puneet K. <pk...@ei...>]

On Wednesday, October 15, 2003, at 02:49  AM, David Christensen wrote:

> ..
>
>
>> 1.) Establish an SSL connection
>> 2.) Require the user to indentify himself (username and password)
>> 3.) Check against some kind of user database
>> 4.) Create a unique session ID number which can not easily guessed
>>     by others
>> 5.) Store the ID on the users machine (cookie) or send it as part
>>     of the HTTP request ("foo.bar.org/myscript?SID=a3cc69...")
>
> As I thought.
>
>
> Question: are the HTTP requests (with CGI fields and values, including
> session_id) encrypted when using https?

yes.

..
>
>> I use CGI:Session in combination with HTML::Template and they
>> cooperate well.  Nicest feature is that you can redisplay pages filled
>> with session data with a few lines of code (e.g. if you want a user to
>> correct input made earlier in the session).
>
> Good.  I've been able to get CGI::Application, HTML::Template, and
> CGI::FormBuilder working together, but it took careful reading of the
> documents, a fair amount of thinking, and a bit of experimentation.
> ..

I just got done creating a framework for a secure application (well, 
not so secure because I don't use https... more like a "personalized 
weak security" application). I used CGI-Session. Very nicely done 
application. I wish CGI-Session had a driver for my favorite dsn, 
SQLite, but hopefully that will arrive eventually (CGI-Session author 
provides instructions on creating ones own driver, but such things are 
beyond me as I am mortal). Most personalized/security applications 
depend on the "server," and as such, would work better with 
Apache+mod_perl, but even with plain Apache the mileage is pretty good.

Re: [htmltmpl] producing plain text reports with H::T

[Roger B. W. <ro...@fi...>]

On Wed, Oct 15, 2003 at 05:44:17PM +0530, Kenneth Gonsalves wrote:

>i've been playing with H::T to produce formatted plain text reports in an 
>Xwindows based application. Seems to be much more flexible than using perl 
>Formats. So i dont go reinventing the wheel can anyone point me to some tips 
>and tricks to achieve things like centering, right or left justification of 
>fields, line and form feeds etc ?

Line and form feeds will be as they literally appear in the code - make
sure you're careful about where you put them relative to <tmpl_if>s.

Canonical centreing is done with

' ' x (($field_width - length($text))/2) . $text

i.e. in the script, not in the template.

Roger

[htmltmpl] producing plain text reports with H::T

[Kenneth G. <la...@th...>]

hi,
i've been playing with H::T to produce formatted plain text reports in an 
Xwindows based application. Seems to be much more flexible than using perl 
Formats. So i dont go reinventing the wheel can anyone point me to some tips 
and tricks to achieve things like centering, right or left justification of 
fields, line and form feeds etc ?
kg 

Re: [htmltmpl] Perl CGI authentication and session management

[David C. <dpc...@ho...>]

htm...@li...:

Bär, Sebastian wrote:
> Most session tracking software use the same approach:

Thanks for the reply.  :-)


> 1.) Establish an SSL connection
> 2.) Require the user to indentify himself (username and password)
> 3.) Check against some kind of user database
> 4.) Create a unique session ID number which can not easily guessed
>     by others
> 5.) Store the ID on the users machine (cookie) or send it as part
>     of the HTTP request ("foo.bar.org/myscript?SID=a3cc69...")

As I thought.


Question: are the HTTP requests (with CGI fields and values, including
session_id) encrypted when using https?


> The biggest security issue is the session ID itself. If you write
> your application carefully no other session data will ever leave
> your server.

I should be able to do that.


> Cookies are a bit more insecure because they are stored on the
> client machine in uncrypted format.

Okay.


> If someone gets a copy of the ID (and the session has not exipred
> yet) then he or she might be able to intercept the connection.
> Most session mechanisms use some kind of IP address matching to
> ensure each session ID is used from only one machine but this
> has to be considered as a weak obstacle for crackers since IP
> addresses may be spoofed easily.
> Of course this is mainly a client side issue but one your users
> should be aware of. If you choose the cookie approach then make
> sure the cookie expires when the browser is closed.

I suspected as much.  The only solution I could think of was digital
signatures on both the client and the server.


> I use CGI:Session in combination with HTML::Template and they
> cooperate well.  Nicest feature is that you can redisplay pages filled
> with session data with a few lines of code (e.g. if you want a user to
> correct input made earlier in the session).

Good.  I've been able to get CGI::Application, HTML::Template, and
CGI::FormBuilder working together, but it took careful reading of the
documents, a fair amount of thinking, and a bit of experimentation.
Thankfully, the various module authors anticipated the other modules and
provided hooks.  It has been satisfying to see OO code reuse actually
work in a real-world application!


David

Re: [htmltmpl] Perl CGI authentication and session management

[<Seb...@3S...>]

Hi David.

Most session tracking software use the same approach:

1.) Establish an SSL connection
2.) Require the user to indentify himself (username and password)
3.) Check against some kind of user database
4.) Create a unique session ID number which can not easily guessed
    by others
5.) Store the ID on the users machine (cookie) or send it as part
    of the HTTP request ("foo.bar.org/myscript?SID=3Da3cc69...")

The biggest security issue is the session ID itself. If you write
your application carefully no other session data will ever leave
your server.
Cookies are a bit more insecure because they are stored on the
client machine in uncrypted format.
If someone gets a copy of the ID (and the session has not exipred
yet) then he or she might be able to intercept the connection.
Most session mechanisms use some kind of IP address matching to
ensure each session ID is used from only one machine but this
has to be considered as a weak obstacle for crackers since IP
addresses may be spoofed easily.
Of course this is mainly a client side issue but one your users
should be aware of. If you choose the cookie approach then make
sure the cookie expires when the browser is closed.
I use CGI:Session in combination with HTML::Template and they
cooperate well. Nicest feature is that you can redisplay pages
filled with session data with a few lines of code (e.g. if
you want a user to correct input made earlier in the session).

Regards,
Sebastian

> hello, world!
>=20
> I'm working on an e-commerce site using Apache 1.3.26, Perl 5.6,
> CGI::Application, HTML::Template, and CGI::FormBuilder.  I need to
> provide secure user login/logout, profiles, financial pages,=20
> etc..  For
> starters, I plan to use https for sensitive pages.  After=20
> that, I'm not
> sure which way to go.  I would prefer using a standard CPAN=20
> module, such
> as CGI::Session and/or CGI::Session::Auth.
>=20
>=20
> What experiences, recommendations, comments, criticisms, and/or
> suggestions do the list readers have in the areas of user=20
> authentication
> and session management using Perl and CGI?  Does anyone have URL's for
> some good articles, tutorials, etc.?
>=20
>=20
> TIA,
>=20
> David

[htmltmpl] Perl CGI authentication and session management

[David C. <dpc...@ho...>]

hello, world!

I'm working on an e-commerce site using Apache 1.3.26, Perl 5.6,
CGI::Application, HTML::Template, and CGI::FormBuilder.  I need to
provide secure user login/logout, profiles, financial pages, etc..  For
starters, I plan to use https for sensitive pages.  After that, I'm not
sure which way to go.  I would prefer using a standard CPAN module, such
as CGI::Session and/or CGI::Session::Auth.


What experiences, recommendations, comments, criticisms, and/or
suggestions do the list readers have in the areas of user authentication
and session management using Perl and CGI?  Does anyone have URL's for
some good articles, tutorials, etc.?


TIA,

David

Re: [htmltmpl] using HTML::Template to generate static web pages

[Gerke, D. M. <Ge...@hi...>]

Roger Burton West <ro...@fi...> wrote:
>I've used it for:
>
>PostScript (mostly for parameter insertion)
>.ini files
>plain text (that gets fiddly with line breaks)
>source code formatting
>...oh, and HTML.


Sometime I use H:T for static or dynamic HTML too.=20

But my first usage was and is the generation of C++ classes for dialogs,
DB connection ... under MSVC and MFC (ugly environment, but that's the
job). H:T:E connected with some XML is a great tool for this.

Regards
Michael

Re: [htmltmpl] using HTML::Template to generate static web pages

[Pete P. <pet...@cy...>]

Offer Kaye wrote:
> The documentation for HTML::Template talks about using it as a CGI
> script, to generate the HTML code "on-the-fly".
> However, I would like to use it as a regular Perl script, to generate
> static HTML pages. 

To me, a templating system at it's base does one thing, provides a way 
to combine data and presentation together, into a single output. Whether 
that output goes to a file, a database, an email, a web browser, 
whatever... it doesn't matter.

I use H::T for both cgi type apps, and to create static HTML pages, and 
it does an excellent job at both of them.

Pete

Re: [htmltmpl] using HTML::Template to generate static web pages

[Karen J. C. <si...@ph...>]

On Sun, 12 Oct 2003, Douglas Kirkland wrote:

DK>I thought H::T was designed to make dynamic and static pages.  The only
DK>difference I found is where the output is sent.

Not just pages, either... I use it to generate autoresponder emails and
other fun things.

-- 
Karen J. Cravens  si...@ph...

Re: [htmltmpl] using HTML::Template to generate static web pages

[Douglas K. <do...@sl...>]

On Saturday 11 October 2003 13:30, Offer Kaye wrote:
> I'm an HTML::Template newbie, and I was wondering whether the veterans
> on this list could help me.
> 
> The documentation for HTML::Template talks about using it as a CGI
> script, to generate the HTML code "on-the-fly".
> However, I would like to use it as a regular Perl script, to generate
> static HTML pages. I know this *can* be done, since I tried it on the
> example provided in the documentation. But I'm wondering whether
> HTML::Template is really suitable for this kind of use, or if I'm
> "abusing" it.

I thought H::T was designed to make dynamic and static pages.  The only 
difference I found is where the output is sent.

Douglas

RE: [htmltmpl] using HTML::Template to generate static web pages

[Charles K. C. <ccl...@ht...>]

Roger Burton West <ro...@fi...> wrote:

: I've used it for:
: 
: PostScript (mostly for parameter insertion)
: .ini files
: plain text (that gets fiddly with line breaks)
: source code formatting
: ...oh, and HTML.

    I use it to create Promissory Notes when selling
used mobile homes.


Charles K. Clarkson
-- 
Head Bottle Washer,
Clarkson Energy Homes, Inc.
Mobile Home Specialists
254 968-8328