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

Re: [htmltmpl] securing an H::T site with username/password w/ses sion mgt1

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

Ragan, Steve wrote:

> Sorry, but I can't reply to the list from work.
> 
> Anyway, here's a link to a good explanation of it all -
> 
> http://hoohoo.ncsa.uiuc.edu/docs/tutorials/user.html
> 
> It's the server which senses that the request is for a 'protected' directory
> 
> and responds with an authentication challenge. Upon reciept of that
> challenge the browser 
> displays the familiar login prompt box.
> Once authenticated, the username is available in the REMOTE_USER environment
> variable.
> That's the name you can use to look up further info in the database.
> 
> Good luck,
> Steve


Thanks Steve, but that doesn't do what I need (as posted in my other 
emails), unless I haven't fully understood the flexibility and power of 
.htaccess.

I have read a fair amount of Apache docs and tutorials, as well as docs 
for various CPAN modules... the closest "tutorial" for doing what I want 
was on CGI::Session::Cookbook, but that calls for the security 
subroutine to be called at the top of every script in the directory. I 
would like this to be done automagically for every file in the directory 
and all the subdirectories, etc.

I guess what I am looking for is whether it is possible to call a perl 
script from within .htaccess (and whether that is even a correct way of 
doing this), and how I can protect my templates (.tmpl) files.

Thanks.

Re: [htmltmpl] securing an H::T site with username/password w/session mgt1

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

Puneet Kishor wrote:

> Karen J. Cravens wrote:
> 
>> On Wed, 3 Sep 2003, Puneet Kishor wrote:
>>
>> PK>I know this is asking for a basic course in creating a password
>> PK>protected website -- if someone could provide a link to such an 
>> article
>> PK>(esp. if it deals with H::T-specific issues, if any -- for example,
>> PK>.tmpl files are not cgi scripts, so how could they be protected, etc.)
>> PK>that would be great.
>>
>> Most of this doesn't even need to be done at the script level, much less
>> H::T... just use the .htaccess file to secure the directory (or
>> directories) at the server level.  Scripts can retrieve the (already
>> verified) username from the environment variables if they need to look
>> things up in a database.
>>
> 
> Thanks Karen. The problems with .htaccess are --
> 
> 1. A separate file/db to store the username/password info. I want to 
> store all user-related info (username, password, and a boatload of 
> personalization info such as favorite color and firstname, etc.) in the 
> same database table that I can safely backup or move to another server, 
> etc.
> 
> 2. As I understand, using AuthType Basic with .htaccess allows you to 
> login but not logout (that's what I gathered from Apache docs, although 
> I might be confused over this).
> 
> 


oh... and another problem with .htaccess I forgot to mention --

once you are in, you are in for everything. So, as I mentioned in my 
original query -- "How do I prevent the user from going directly to 
mywebsite/foo.tmpl or whatever else? "

Re: [htmltmpl] securing an H::T site with username/password w/session mgt1

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

Karen J. Cravens wrote:

> On Wed, 3 Sep 2003, Puneet Kishor wrote:
> 
> PK>I know this is asking for a basic course in creating a password
> PK>protected website -- if someone could provide a link to such an article
> PK>(esp. if it deals with H::T-specific issues, if any -- for example,
> PK>.tmpl files are not cgi scripts, so how could they be protected, etc.)
> PK>that would be great.
> 
> Most of this doesn't even need to be done at the script level, much less
> H::T... just use the .htaccess file to secure the directory (or
> directories) at the server level.  Scripts can retrieve the (already
> verified) username from the environment variables if they need to look
> things up in a database.
> 

Thanks Karen. The problems with .htaccess are --

1. A separate file/db to store the username/password info. I want to 
store all user-related info (username, password, and a boatload of 
personalization info such as favorite color and firstname, etc.) in the 
same database table that I can safely backup or move to another server, etc.

2. As I understand, using AuthType Basic with .htaccess allows you to 
login but not logout (that's what I gathered from Apache docs, although 
I might be confused over this).


> The only thing that's lacking is session-orientedness.
> 

3. Oh yes... that is important.

What I need is a way to run a specific security.pl (kinda script) on 
every request to the webserver... .htaccess seems to be a logical place 
to call something like that from. Is it? How? What are the alternatives?

On another note -- what is the preferred session module for H::T users? 
Apache::Session or CGI::Session or something else?

[htmltmpl] securing an H::T site with username/password w/session mgt1

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

Phew! that was mouthful.

Folks, I am running around in circles trying to comprehend what must be 
basics for most of you.

Having built a fine H::T based website and been singing praises of this 
fine module, I want to now put it all behind a username/password login 
with session mgt.

I have gotten my mind suitably confused reading docs on Apache security, 
CGI::Session, Apache::Session, and scores of articles on various 
websites. Needless to say, I haven't yet figured out the simplest, 
easiest way to accomplish the following --

on going to my website, the user should be presented with a login form. 
On successful login, the user's information should be retrieved from a 
database (let's assume MySQL here)... this could be a load of info such 
as preferences, various application settings, etc. These pieces of 
user-specific information should be stored in a session structure so I 
may use it throughout the user's session until the user logs out. On 
logging out, the last state should be saved back to the database and the 
session should be cleared.

I am assuming that the script that does the checking whether the user is 
logged in or not has to somehow be connected with .htaccess so that it 
may run everytime... I don't know how to do that. How do I prevent the 
user from going directly to mywebsite/foo.tmpl or whatever else?

I know this is asking for a basic course in creating a password 
protected website -- if someone could provide a link to such an article 
(esp. if it deals with H::T-specific issues, if any -- for example, 
.tmpl files are not cgi scripts, so how could they be protected, etc.) 
that would be great.

Many thanks.

[htmltmpl] A Calendar Template?

[Bill M. <wpm...@co...>]

Hey all,

I've been poking around CPAN and Sorceforge for an H::T calendar type
extension and haven't really found what I'm looking for. It needs to fit in
with CGI::Application and MySQL. I'm thinking this shouldn't be too
difficult a side project, but it would be just that: "a side project". So
... before I start rolling my own, maybe you wouldn't mind sharing with me,
experiences included?


Thanks,

Bill
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003

[htmltmpl] Re: WebGUI - an HTML::Template CMS/app-server?

[Mark S. <ma...@su...>]

In article <Pine.LNX.4.44.0308091701170.7157-100000@localhost.localdomain>, Sam Tregar wrote:
> 
> I'd previously thought that Bricolage was the only CMS supporting
> HTML::Template (not including blogging tools).  Are there more out
> there?

Cascade has been using HTML::Template since 2001:
http://www.summersault.com/software/cascade/

It was built to run http://www.skatepark.org/ ... and still does. :) 

	Mark
--
http://mark.stosberg.com/ 

RE: [htmltmpl] digest, Vol 1 #253 - Syntax Errors

[Jeff P. <jp...@gr...>]

Howdy Puneet,

Thank you for pointing that out.  I should also point out that I have
dyslexia, so sometimes my grammar and syntax don't jive with what I am
really trying to say.  Unfortunately, It looks right too me!

Thanx, Jeff.

-----Original Message-----
From: Puneet Kishor [mailto:pk...@ei...] 
Sent: Wednesday, August 20, 2003 6:51 PM
To: Jeff Pelkey
Cc: 'htm...@li...'
Subject: Re: [htmltmpl] RE: Html-template-users digest, Vol 1 #253 - 2 msgs


On Wednesday, August 20, 2003, at 09:07  AM, Jeff Pelkey wrote:

> Howdy Chisel,
>
> Thanks for the input!  The $$text_ref may have been too obvious.  I 
> have
> used $@text_ref and $%text_ref to dereference arrays and hashes before 
> but
> had never thought of using "$$text_ref".


I think you mean @$text_ref and %$text_ref to deref arrays and hashes 
respectively. By extrapolation, it would be $$text_ref to deref a 
scalar. Remember, a reference is always a scalar...
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information, the disclosure of which is governed by
applicable law.  If the reader of this e-mail is not the intended
recipient(s),  any unauthorized review, use, disclosure or distribution is
prohibited.  If you have received this message in error, please contact the
sender by reply e-mail and destroy all copies of the original message
immediately.

Re: [htmltmpl] RE: Html-template-users digest, Vol 1 #253 - 2 msgs

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

On Wednesday, August 20, 2003, at 09:07  AM, Jeff Pelkey wrote:

> Howdy Chisel,
>
> Thanks for the input!  The $$text_ref may have been too obvious.  I 
> have
> used $@text_ref and $%text_ref to dereference arrays and hashes before 
> but
> had never thought of using "$$text_ref".


I think you mean @$text_ref and %$text_ref to deref arrays and hashes 
respectively. By extrapolation, it would be $$text_ref to deref a 
scalar. Remember, a reference is always a scalar...

[htmltmpl] RE: Html-template-users digest, Vol 1 #253 - 2 msgs

[Jeff P. <jp...@gr...>]

Howdy Chisel,

Thanks for the input!  The $$text_ref may have been too obvious.  I have
used $@text_ref and $%text_ref to dereference arrays and hashes before but
had never thought of using "$$text_ref".

As it turns out, after I got back yesterday of several days off things
worked fine.  I apparently just needed to reboot; go figure and on a windows
box too! ;>/  I am going to reboot my development box every afternoon from
here on out.

Thanx Again, Jeff.

>> YA?: What does the "$$" mean in $$test_ref.

>$text_ref is a reference to a scalar, so to get the text itself you need
>to dereference it.
>It's proably easier to understand if you think of it as ${$text_ref}.
>It's the same as you'd do with hash an array references.

>> my $filter = sub {
>> 	my $text_ref = shift;
>> 	$text_ref =~ s/!!!ZAP_(.*?)!!!/<TMPL_$1>/g;
>> 	$$text_ref;
>> 	## Also Tried Adding "return $text_ref;" - No Difference.
>> };


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information, the disclosure of which is governed by
applicable law.  If the reader of this e-mail is not the intended
recipient(s),  any unauthorized review, use, disclosure or distribution is
prohibited.  If you have received this message in error, please contact the
sender by reply e-mail and destroy all copies of the original message
immediately.

Re: [htmltmpl] CCI::App/H::T fatal exception handler

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

On Mon, 18 Aug 2003, Bill Catlan wrote:

> Is there a way to output a Web page from within the CGI::App  framework 
> using H::T upon a fatal error? Doe it matter if the fatal exception called 
> die or generated an "Error" exception?

This is obviously a question for the CGI::Application mailing-list.
Once you choose a way to deal with errors from within CGI::App using
an error.tmpl to format them is no big deal.

-sam

[htmltmpl] CCI::App/H::T fatal exception handler

[Bill C. <wc...@ya...>]

Hello,

Is there a way to output a Web page from within the CGI::App  framework 
using H::T upon a fatal error? Doe it matter if the fatal exception called 
die or generated an "Error" exception?

When you return output from a runmode, I assume CGI::App puts the string 
onto the STDOUT filehandle linked to your request.  How can you get the 
socket from CGI::App in the event you want to write to the request handle 
yourself, rather than returning  a string from a runmode?

Can this be accomplished only after you enter a runmode, or can it be done 
if there is a fatal exception in cgiapp_init or cgiapp_prerun?

Thanks.

Bill Catlan

[htmltmpl] Bricolage in Linux Journal

[David W. <da...@ki...>]

Linux Journal has published the first in a series of articles about 
Bricolage in its September 2003 issue. Reuven Lerner, who wrote the 
article, says that he is "enthusiastic about Bricolage."

Reuven covers the installation of Bricolage, as well as a discussion of 
Bricolage's dependencies (Apache, mod_perl, PostgreSQL, etc.). He also 
examines Bricolage's data model and its application architecture. It's 
a good, technically-oriented introduction to Bricolage from someone who 
has spent a lot of time working with Web applications over the years. 
So go read it!

   http://www.linuxjournal.com/article.php?sid=6934

David

-- 
David Wheeler                                     AIM: dwTheory
da...@ki...                              ICQ: 15726394
http://www.kineticode.com/                     Yahoo!: dew7e
                                                Jabber: Th...@ja...
Kineticode. Setting knowledge in motion.[sm]

RE: [htmltmpl] CGI::App, H::T & javascript

[Bill M. <wpm...@co...>]

Puneet,


> > Here are the key parts:
> >
> > Some HTML template looks like this ...
> >
> > <form id=new_data_form name=new_data_form method=post
> > action=myapp.cgi?rm=new_data>
> > <input type=hidden name="rm" value="add_record">
> > <input type=hidden name="param1">
> > <input type=hidden name="param2">
> > </form>
> >
> > <form id=edit_data_form name=edit_data_form method=post
> > action=myapp.cgi?rm=edit_data>
> > <input type=hidden name="rm" value="edit_record">
> > <input type=hidden name="param1">
> > <input type=hidden name="param2">
> > </form>
> >
>
> in both instance above, you have a url variable (rm) on form action,
> and you also are passing the same variable as a hidden field. Why both?
> I see this commonly. Pass one or the other... in fact, in case of
> forms, don't use url variables at all... just use <input type="hidden"
> name="rm" value=whatever value> and make the action really simple such
> as <form ... action="myapp.cgi">. If, for some reason, you want to see
> the variables in the url, make method="get", but that is messy...

Yes, you're correct. I thought it was necessary in both places. It's better
to work with hidden parameter at all times if possible.

Thanks.

>
>
> > <form id=instant_update_form name=instant_update_form method=post
> > action=myapp.cgi>
> > <input type=hidden name="rm" value="display">
> > <input type=hidden name="param1">
> > <input type=hidden name="param2">
> > <input type=hidden name="param3">
> > </form>
> >
> > <form id=main_form name=main_form method=post action=myapp.cgi>
> >
> > 	SOME HTML::Template structure here
> >
> > 	with ...
> >
> > 	<input type=text name="param3">
> > 	onClick="javascript:add_record()"
> >
> > 	....
> >
> > 	and so on
> >
> > </form>
> >
> > And the Javascript ....
> >
> > function add_record()
> > {
> >   var my_form;
> >   var somevar;
> >
> >   my_form = this.document.forms['new_data_form'];
> >   somevar = this.document.forms['main'].param3.value;
> >
> >   my_form.param1.value = "add";
> >   my_form.param3.value = somevar; /* this is where it happens */
> >   my_form.submit();
> > }
> >
> > and so on for other main display form functions.
> >
> > Then in the next form, on submit, pass all the cgi params back to
> > myapp.cgi?rm=display and finally process.
>
> this is another common usage that puzzles me... form widgets were
> designed to submit forms... I often see folks using Javascript to
> submit forms. Unless there is something you are changing on the client
> side interactively, this is pointless... just overhead noise. My
> philosophy is to keep things as simple as possible and use them mostly
> for what they are designed -- less chance of breakage.
>
> Here is a simple way of doing this...
>
> in your template, for example, in the edit form...
>
> <form name="myform" action="myapp.cgi" method="post">
> 	blah blah blah
> 	<input type="submit" name="action" value="Edit">
> </form>
>
> and then in your script...
>
> my $action = param('action'); # assuming you are use-ing CGI.pm
> if ($action eq 'Edit') {
> 	... edit code ...
> } elsif ($action eq 'Delete') {
> 	... delete code ...
> } elsif ($action eq 'Add') {
> ...
> ...
> you get the idea

Hmm, maybe I don't. Or maybe you didn't completely get my idea. I'll be
graphical: my app looks like this:


			*USER SELECTIONS ON DISPLAY FORM
[display form] ------+--> *delete record ---+---> rm=process ------>
[display form]
(shows many records  |                      ^
 from variable       |                      |
 *like* db's.        |--> *new record       |
 this is the         |     rm=new           |
 KEY motivation!!!   |        |             |
                     |        \             |
                     |  [new record form]   |
                     |        |             |
                     |        \             |
                     |     *submit--->--->--+
                     |                      |
                     |                      |
                     |--> *edit record      |
                            rm=edit         |
                              |             |
                              \             |
                        [edit record form]  | here, this form may be
                              |             | different from the
new_record_form
                              \             | (i.e. completely different
template)
                           *submit--->--->--+


In the new record form, I need to a new record to what, it may change
depending on the display form. Same with edit record, I need to know which
record from where. Then I want to end back up at the display form to process
and display the changes, where I most certainly have code that looks like:

> my $action = param('action'); # assuming you are use-ing CGI.pm
> if ($action eq 'Edit') {
> 	... edit code ...
> } elsif ($action eq 'Delete') {
> 	... delete code ...
> } elsif ($action eq 'Add') {


>
> There can be many variations on the above... a simple way is to create
> separate templates for each of the actions, changing the value of
> <input type="submit" name="action" value=???> in each template
> appropriately.
>

Yes, of course.

So, am I still missing something here?


Bill
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.506 / Virus Database: 303 - Release Date: 8/1/2003

Re: [htmltmpl] CGI::App, H::T & javascript

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

thanks for sharing the code. Here's my take...

On Thursday, August 14, 2003, at 09:16  AM, Bill McCormick wrote:

> ..
>
> Here are the key parts:
>
> Some HTML template looks like this ...
>
> <form id=new_data_form name=new_data_form method=post
> action=myapp.cgi?rm=new_data>
> <input type=hidden name="rm" value="add_record">
> <input type=hidden name="param1">
> <input type=hidden name="param2">
> </form>
>
> <form id=edit_data_form name=edit_data_form method=post
> action=myapp.cgi?rm=edit_data>
> <input type=hidden name="rm" value="edit_record">
> <input type=hidden name="param1">
> <input type=hidden name="param2">
> </form>
>

in both instance above, you have a url variable (rm) on form action, 
and you also are passing the same variable as a hidden field. Why both? 
I see this commonly. Pass one or the other... in fact, in case of 
forms, don't use url variables at all... just use <input type="hidden" 
name="rm" value=whatever value> and make the action really simple such 
as <form ... action="myapp.cgi">. If, for some reason, you want to see 
the variables in the url, make method="get", but that is messy...


> <form id=instant_update_form name=instant_update_form method=post
> action=myapp.cgi>
> <input type=hidden name="rm" value="display">
> <input type=hidden name="param1">
> <input type=hidden name="param2">
> <input type=hidden name="param3">
> </form>
>
> <form id=main_form name=main_form method=post action=myapp.cgi>
>
> 	SOME HTML::Template structure here
>
> 	with ...
>
> 	<input type=text name="param3">
> 	onClick="javascript:add_record()"
>
> 	....
>
> 	and so on
>
> </form>
>
> And the Javascript ....
>
> function add_record()
> {
>   var my_form;
>   var somevar;
>
>   my_form = this.document.forms['new_data_form'];
>   somevar = this.document.forms['main'].param3.value;
>
>   my_form.param1.value = "add";
>   my_form.param3.value = somevar; /* this is where it happens */
>   my_form.submit();
> }
>
> and so on for other main display form functions.
>
> Then in the next form, on submit, pass all the cgi params back to
> myapp.cgi?rm=display and finally process.

this is another common usage that puzzles me... form widgets were 
designed to submit forms... I often see folks using Javascript to 
submit forms. Unless there is something you are changing on the client 
side interactively, this is pointless... just overhead noise. My 
philosophy is to keep things as simple as possible and use them mostly 
for what they are designed -- less chance of breakage.

Here is a simple way of doing this...

in your template, for example, in the edit form...

<form name="myform" action="myapp.cgi" method="post">
	blah blah blah
	<input type="submit" name="action" value="Edit">
</form>

and then in your script...

my $action = param('action'); # assuming you are use-ing CGI.pm
if ($action eq 'Edit') {
	... edit code ...
} elsif ($action eq 'Delete') {
	... delete code ...
} elsif ($action eq 'Add') {
...
...
you get the idea

There can be many variations on the above... a simple way is to create 
separate templates for each of the actions, changing the value of 
<input type="submit" name="action" value=???> in each template 
appropriately.

Anyway... thanks for sharing your ideas.

[htmltmpl] CGI::App, H::T & javascript

[Bill M. <wpm...@co...>]

Hello,

I'm a relative newbie to CGI::App, H::T and JavaScript. I'm working on a
project where I make heavy use of both CGI::App and H::T and limited use of
JavaScript (just event handlers.) Recently, I devised an idiom for passing
CGI parameters from one form to another form (without using any statefull
server mechanism) and I'd like to pass it along. Maybe this is useful and
you like it, maybe I've just devised something that everybody already knows
about, or maybe you do this another way you'd like to share. Or more
dreadfully, maybe there's a serious flaw in all this that I've overlooked!
I'd really appreciate knowing about that before I spread this like molasses
over my whole application.

Here are the key parts:

Some HTML template looks like this ...

<form id=new_data_form name=new_data_form method=post
action=myapp.cgi?rm=new_data>
<input type=hidden name="rm" value="add_record">
<input type=hidden name="param1">
<input type=hidden name="param2">
</form>

<form id=edit_data_form name=edit_data_form method=post
action=myapp.cgi?rm=edit_data>
<input type=hidden name="rm" value="edit_record">
<input type=hidden name="param1">
<input type=hidden name="param2">
</form>

<form id=instant_update_form name=instant_update_form method=post
action=myapp.cgi>
<input type=hidden name="rm" value="display">
<input type=hidden name="param1">
<input type=hidden name="param2">
<input type=hidden name="param3">
</form>

<form id=main_form name=main_form method=post action=myapp.cgi>

	SOME HTML::Template structure here

	with ...

	<input type=text name="param3">
	onClick="javascript:add_record()"

	....

	and so on

</form>

And the Javascript ....

function add_record()
{
  var my_form;
  var somevar;

  my_form = this.document.forms['new_data_form'];
  somevar = this.document.forms['main'].param3.value;

  my_form.param1.value = "add";
  my_form.param3.value = somevar; /* this is where it happens */
  my_form.submit();
}

and so on for other main display form functions.

Then in the next form, on submit, pass all the cgi params back to
myapp.cgi?rm=display and finally process.


That's it. Hope you find it useful or care to share something even better.

Cheers,

Bill

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.506 / Virus Database: 303 - Release Date: 8/1/2003

Re: [htmltmpl] Fun with Filters.

[Chisel W. <ch...@he...>]

On Wed, Aug 13, 2003 at 09:31:54AM -0500, Jeff Pelkey wrote:
> YA?: What does the "$$" mean in $$test_ref.

$text_ref is a reference to a scalar, so to get the text itself you need
to dereference it.
It's proably easier to understand if you think of it as ${$text_ref}.
It's the same as you'd do with hash an array references.

> my $filter = sub {
> 	my $text_ref = shift;
> 	$text_ref =~ s/!!!ZAP_(.*?)!!!/<TMPL_$1>/g;
> 	$$text_ref;
> 	## Also Tried Adding "return $text_ref;" - No Difference.
> };

I think that here you want:

  $$text_ref =~ s/!!!ZAP_(.*?)!!!/<TMPL_$1>/g;

(as per the example in the H::T documentation)

> sub test_function {
> 	##my $str1 = shift;
> 	my ($str1, $str2) = @_;
> 	my $strTest = qq~Hi this is some text: '$str1-$str2'.~;
> 	return $strTest;
> }

Do you get other arguments passed into a filter? I can't say I've ever
tried, but wouldn't expect more than $text_ref. However, you want to use
$$str1 to get the actual text held in str1, $str1 is a reference to a
scalar.

I think.

Chisel
-- 
e:   ch...@he...      |    I may contradict myself, but at least
w:   http://www.herlpacker.co.uk/ |          I don't contradict myself.
gpg: D167E7FE                     |

[htmltmpl] Fun with Filters.

[Jeff P. <jp...@gr...>]

Howdy!

I'm having a time using filters and not sure if what I am doing is wrong (if
anything).  I am just using the sample in the documentation.  I should also
mention the standard caveats: I searched the Archives first and the examples
looked like mine.  Also, I should mention that I am using Win2K and IIS 5.
I am not sure if this is the issue again or not. I receive a 200 header
status and no output from debug.

Another ?: Can you create a filter to deal with form/user input too?  Is
that what the "removing_spaces" filter in the documentation is meant to do?

YA?: What does the "$$" mean in $$test_ref.  I know that $$ is used to
retrieve the process number.  I looked in the documentation and several Perl
Books including "Programming Perl" but did not find a reference to this in
the book.

Thanx, Jeff.

PS - The function(s) work fine and I could just use them instead.  I just
wanted to see what a filter did and what you could do with them.
 
Anyway, here is the code:


my $filter = sub {
	my $text_ref = shift;
	$text_ref =~ s/!!!ZAP_(.*?)!!!/<TMPL_$1>/g;
	$$text_ref;
	## Also Tried Adding "return $text_ref;" - No Difference.
};

sub test_function {
	##my $str1 = shift;
	my ($str1, $str2) = @_;
	my $strTest = qq~Hi this is some text: '$str1-$str2'.~;
	return $strTest;
}

my $tmpl = HTML::Template::Expr->new(
filename => 'filter2.tmpl',
die_on_bad_params => 0,
			associate => $cgi,
filter => $filter,
functions => { 
						test_func => \&test_function
					}, 
			debug => 1
						);

		$tmpl->param( FOO => 'Try My Filter!~#$%');

Here is the Template portion:

       Howdy:&nbsp;!!!ZAP_VAR NAME="FOO" !!!.<BR>

Here is the result displayed by the browser:

Howdy: !!!ZAP_VAR NAME="FOO" !!!.

__END__
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information, the disclosure of which is governed by
applicable law.  If the reader of this e-mail is not the intended
recipient(s),  any unauthorized review, use, disclosure or distribution is
prohibited.  If you have received this message in error, please contact the
sender by reply e-mail and destroy all copies of the original message
immediately.

[htmltmpl] ANNOUNCE: Bricolage 1.6.4

[David W. <da...@wh...>]

I'm abashed to announce announce the release of Bricolage 1.6.4, mere
hours after the release of 1.6.3. This maintenance release addresses a
number issues discovered since the release of version 1.6.2, plus one
serious issue in version 1.6.3. Some of the more important changes since
1.6.2 include:

     * Preview works again (it was broken only during 1.6.3's brief
       life).

     * Document and contributor type field information (label, options)
       is no longer pushed through Locale::Maketext, thus preventing
       errors when element and contributor type administrators create
       field options with brackets in them.

     * Documents associated with categories that have been deleted will
       once again work properly. Even though a category may be
       deactivated, any documents previously put into that category
       should still work, and still treat the category as a working
       category. And so they do.

     * Permissions granted on the "All" groups work again.

     * Resize now works in super bulk edit.

     * When a template is deployed, Bricolage now checks to see if its
       file name has changed since it was last deployed, and if it has,
       it deletes the old file.

     * Optimized performance of Bric::Dist::Resource queries and wrote
       lots of tests for them.

     * When a story or media document is published, Bricolage now looks
       to see if any files distributed for previous versions of the
       document are no longer associated with the document, and expires
       them if they are. It does so on a per-output channel basis, so
       note that if output channel settings have changed since the
       document was last published, the expiration may miss some stale
       files. The same goes for when destinations are changed. But this
       should cover the vast majority of cases.

     * Text input fields no longer impose a default maximum field
       length. This is so that element fields that have their maximum
       length set to 0 can truly be unlimited in length.

     * Passing an undef via the "workflow__id" parameters to the "list()"
       method of Story, Media, or Template once again causes Bricolage to
       correctly return only those assets that are not in workflow.

     * Extra blank lines between subelement tags in super bulk edit no
       longer causes an error.

     * Searches no longer return unexpected results or all objects when
       pagination is enabled.

For a complete list of the changes, see the changes file at:

   http://sourceforge.net/project/shownotes.php?release_id=177713

ABOUT BRICOLAGE

Bricolage is a full-featured, enterprise-class content management and
publishing system. It offers a browser-based interface for ease-of use,
a full-fledged templating system with complete HTML::Mason and
HTML::Template support for flexibility, and many other features. It
operates in an Apache/mod_perl environment, and uses the PostgreSQL
RDBMS for its repository. A comprehensive, actively-developed open
source CMS, Bricolage has been hailed as "Most Impressive" in 2002 by
eWeek.

Learn more about Bricolage and download it from the Bricolage home page,
http://bricolage.cc/.

Enjoy!

David

-- 
David Wheeler                                     AIM: dwTheory
da...@ki...                              ICQ: 15726394
http://www.kineticode.com/                     Yahoo!: dew7e
                                                Jabber: Th...@ja...
Kineticode. Setting knowledge in motion.[sm]

[htmltmpl] ANNOUNCE: Bricolage 1.6.3

[David W. <da...@ki...>]

I'm pleased to announce announce the release of Bricolage-Devel
1.6.3. This maintenance release addresses a number issues discovered
since the release of version 1.6.2. Some of the more important changes
since 1.6.2 include:

     * Document and contributor type field information (label, options)
       is no longer pushed through Locale::Maketext, thus preventing
       errors when element and contributor type admins create field
       options with brackets in them.

     * Documents associated with categories that have been deleted will
       once again work properly. Even though a category may be
       deactivated, any documents previously put into that category
       should still work, and still treat the category as a working
       category. And so they do.

     * Permissions granted on the "All" groups work again.

     * Resize now works in super bulk edit.

     * When a template is deployed, Bricolage now checks to see if its
       file name has changed since it was last deployed, and if it has,
       it deletes the old file.

     * Optimized performance of Bric::Dist::Resource queries and wrote
       lots of tests for them.

     * When a story or media document is published, Bricolage now looks
       to see if any files distributed for previous versions of the
       document are no longer associated with the document, and expires
       them if they are. It does so on a per-output channel basis, so
       note that if output channel settings have changed since the
       document was last published, the expiration may miss some stale
       files. The same goes for when destinations are changed. But this
       should cover the vast majority of cases.

     * Text input fields no longer impose a default maximum field
       length. This is so that element fields that have their maximum
       length set to 0 can truly be unlimited in length.

     * Passing an undef via the "workflow__id" parameters to the "list()"
       method of Story, Media, or Template once again causes Bricolage to
       correctly return only those assets that are not in workflow.

     * Extra blank lines between subelement tags in super bulk edit no
       longer causes an error.

     * Searches no longer return unexpected results or all objects when
       pagination is enabled.

For a complete list of the changes, see the changes file at:

   https://sourceforge.net/project/shownotes.php?release_id=177689

ABOUT BRICOLAGE

Bricolage is a full-featured, enterprise-class content management and
publishing system. It offers a browser-based interface for ease-of use,
a full-fledged templating system with complete HTML::Mason and
HTML::Template support for flexibility, and many other features. It
operates in an Apache/mod_perl environment, and uses the PostgreSQL
RDBMS for its repository. A comprehensive, actively-developed open
source CMS, Bricolage has been hailed as "Most Impressive" in 2002 by
eWeek.

Learn more about Bricolage and download it from the Bricolage home page,
http://bricolage.cc/.

Enjoy!

David

-- 
David Wheeler                                     AIM: dwTheory
da...@ki...                              ICQ: 15726394
http://www.kineticode.com/                     Yahoo!: dew7e
                                                Jabber: Th...@ja...
Kineticode. Setting knowledge in motion.[sm]

Re: [htmltmpl] "dump"-ing a loop

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

ok... that set me thinking, and I found the solution. Here is a 
complete example using XBase, so that some other poor sod in the future 
might quickly get going instead of fretting...

In the script --

	my $dbftable = new XBase $table or die XBase->errstr;

	# get the fieldname
	my @fns;
	for ($dbftable->field_names) {
		my %f = ('fn' => "$_");
		push(@fns, \%f);
	}
	$template->param(fns => \@fns);

	# get the first ten rows
	my @res;
	for my $row (0..9) {
		my @col;
		for (0..$dbftable->last_field) {
			my @c = $dbftable->get_record_nf($row, $_);
			my %c = ('cv' => "$c[1]");
			push(@col, \%c);
		}
		my %r = ('rv' => \@col);
		push(@res, \%r);
	}
	$template->param(res => \@res);

And then in the template --

		<table border="1">
			<tr><tmpl_loop fns><th><tmpl_var fn></th></tmpl_loop></tr>
			<tmpl_loop res>
				<tr><tmpl_loop rv><td><tmpl_var cv></td></tmpl_loop></tr>
			</tmpl_loop>
		</table>

done. Hope this helps someone in the future.


On Tuesday, August 12, 2003, at 07:53  AM, Joel wrote:

> Morning folks,
>
> I've done this before, and it's a bit tricky, but it's certainly 
> possible.
>
> What you need is a pair of nested loops. One to iterate through the 
> rows of
> your data and one to iterate through the columns of each row. Your 
> template
> would look like the following: (let's pretend like we are putting 
> everything
> into a table)
>
> <table>
> <TMPL_LOOP NAME=ROWS_LOOP>
>     <tr>
>     <TMPL_LOOP NAME=COLS_LOOP>
>         <td><TMPL_VAR NAME=VALUE></td>
>     </TMPL_LOOP>
>     </tr>
> </TMPL_LOOP>
> </table>
>
> Now it's just a matter of building your array of hashrefs to send to 
> HTML
> template, which I'll leave as homework. :)
>
> If anyone can come up with a better solution, I'm open to it.
>
> --Joel
>
>>
>> On Tuesday, August 12, 2003, at 12:42  AM, Kenneth Gonsalves wrote:
>>
>>> On Tuesday 12 August 2003 09:45, you wrote:
>>>
>>>> did a few "feeble" searches in the archive, but I really don't know 
>>>> how
>>>> to word this exactly...
>>>>
>>>> I want to query a database table, and then print the results. The
>>>> problem is, I don't know what the names of the fields are...
>>>>
>>>> so, while I can build an array of hash refs from the returned 
>>>> results,
>>>> and assign them to a tmpl_loop, I don't know the names of the
>>>> tmpl_vars... so in my template, I don't really know what to print 
>>>> out.
>>>
>>> you have an anonymous array/hash. you dont need to know the names of 
>>> the
>>> variables. assign something like:
>>> $var1 = @$return[0]. $var2 = @$return[1] etc (do this in the code and
>>> not in the template)
>>> kg
>>>
>>
>> won't really work, I think. See, I query the database table like so (I
>> have to, not that I want to)...
>>
>>   SELECT * FROM mytable WHERE somecondition
>>
>> so in advance I have no idea how many fields are returned, and what
>> their names are. While I can find that out in my code using the
>> capabilities of my database driver module, I can't really rewrite my
>> template on the fly (unless that is one way of doing it). Hence, I am
>> stuck...
>>
>>

RE: [htmltmpl] debugging in cgi scripts?

[Jeff M. <in...@bi...>]

open STDERR,">>/some/directory/mylog.log";

at the first of your script.

and close it at the end.

jeff.

>> -----Original Message-----
>> From: htm...@li... 
>> [mailto:htm...@li...] On 
>> Behalf Of Andreas Schuldei
>> Sent: Tuesday, August 12, 2003 8:47 AM
>> To: html-template
>> Subject: [htmltmpl] debugging in cgi scripts?
>> 
>> 
>> unfortunatly i have to write a webmin module, which does not 
>> run on apache but in some cgi environment of its own.
>> 
>> how can i dump the debug output not to stderr but to some 
>> other place?
>> 
>> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites 
>> including Data Reports, E-commerce, Portals, and Forums are 
>> available now. Download today and enter to win an XBOX or 
>> Visual Studio .NET. 
>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspne
t_072303_01/01
_______________________________________________
Html-template-users mailing list
Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users

[htmltmpl] debugging in cgi scripts?

[Andreas S. <an...@sc...>]

unfortunatly i have to write a webmin module, which does not run
on apache but in some cgi environment of its own.

how can i dump the debug output not to stderr but to some other
place?

Re: [htmltmpl] "dump"-ing a loop

[Joel <htm...@jo...>]

Morning folks,

I've done this before, and it's a bit tricky, but it's certainly possible.

What you need is a pair of nested loops. One to iterate through the rows of
your data and one to iterate through the columns of each row. Your template
would look like the following: (let's pretend like we are putting everything
into a table)

<table>
<TMPL_LOOP NAME=ROWS_LOOP>
    <tr>
    <TMPL_LOOP NAME=COLS_LOOP>
        <td><TMPL_VAR NAME=VALUE></td>
    </TMPL_LOOP>
    </tr>
</TMPL_LOOP>
</table>

Now it's just a matter of building your array of hashrefs to send to HTML
template, which I'll leave as homework. :)

If anyone can come up with a better solution, I'm open to it.  

--Joel

>
>On Tuesday, August 12, 2003, at 12:42  AM, Kenneth Gonsalves wrote:
>
>> On Tuesday 12 August 2003 09:45, you wrote:
>>
>>> did a few "feeble" searches in the archive, but I really don't know how
>>> to word this exactly...
>>>
>>> I want to query a database table, and then print the results. The
>>> problem is, I don't know what the names of the fields are...
>>>
>>> so, while I can build an array of hash refs from the returned results,
>>> and assign them to a tmpl_loop, I don't know the names of the
>>> tmpl_vars... so in my template, I don't really know what to print out.
>>
>> you have an anonymous array/hash. you dont need to know the names of the
>> variables. assign something like:
>> $var1 = @$return[0]. $var2 = @$return[1] etc (do this in the code and 
>> not in the template)
>> kg
>>
>
>won't really work, I think. See, I query the database table like so (I 
>have to, not that I want to)...
>
>   SELECT * FROM mytable WHERE somecondition
>
>so in advance I have no idea how many fields are returned, and what 
>their names are. While I can find that out in my code using the 
>capabilities of my database driver module, I can't really rewrite my 
>template on the fly (unless that is one way of doing it). Hence, I am 
>stuck...
>
>

Re: [htmltmpl] "dump"-ing a loop

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

On Tuesday, August 12, 2003, at 12:42  AM, Kenneth Gonsalves wrote:

> On Tuesday 12 August 2003 09:45, you wrote:
>> did a few "feeble" searches in the archive, but I really don't know 
>> how
>> to word this exactly...
>>
>> I want to query a database table, and then print the results. The
>> problem is, I don't know what the names of the fields are...
>>
>> so, while I can build an array of hash refs from the returned results,
>> and assign them to a tmpl_loop, I don't know the names of the
>> tmpl_vars... so in my template, I don't really know what to print out.
> you have an anonymous array/hash. you dont need to know the names of 
> the
> variables. assign something like:
> $var1 = @$return[0]. $var2 = @$return[1] etc (do this in the code and 
> not in
> the template)
> kg
>

won't really work, I think. See, I query the database table like so (I 
have to, not that I want to)...

	SELECT * FROM mytable WHERE somecondition

so in advance I have no idea how many fields are returned, and what 
their names are. While I can find that out in my code using the 
capabilities of my database driver module, I can't really rewrite my 
template on the fly (unless that is one way of doing it). Hence, I am 
stuck...

[htmltmpl] "dump"-ing a loop

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

did a few "feeble" searches in the archive, but I really don't know how 
to word this exactly...

I want to query a database table, and then print the results. The 
problem is, I don't know what the names of the fields are...

so, while I can build an array of hash refs from the returned results, 
and assign them to a tmpl_loop, I don't know the names of the 
tmpl_vars... so in my template, I don't really know what to print out. 
Am I missing something obvious in the docs? Is there a way to simply 
dump out the results of a tmpl_loop a la Data::Dumper?

many tia,

Puneet.