Re: ePerl (fragment of Re: Apache::SimpleTemplate)

[Todd Finney]

Yea, I tried that, but it was still unhappy.  There are apparently a 
couple of other tweaks that needed to be done.   I didn't think too 
much about it; after the first error, I went looking for information 
and found the patch.

http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/textproc/eperl/Makefile

cheers,
Todd


At 01:21 AM 7/9/01, Mithun Bhattacharya wrote:
>The only thing I had to fix was that the Makefile didnt know about
>version 5.6 otherwise it compiled cleanly... Ofcourse there is a issue
>with a function declaration which gcc didnt like but it got fixed when 
>I
>commented it out.
>
> > There's a patch to make it work with 5.6 floating around, but I 
> haven't
> > seen anything else new in some time.

Re: Apache::SimpleTemplate (don't do it!)

[Robert Landrum]

>Yes.  Writing a templating system in Perl is trivial.  Writing a
>*useful* templating system in Perl is demonstratably hard.

I too have written a templating system.

About a year ago I wrote a simple module called dbq.pm.  It performed 
database queries.  Basically, you could mock up a simple html page, 
add some special dbq tags, and it would run queries against the 
database.  I wrote it to see if I could write a simple version of 
ColdFusion It took 90 minutes to write on a saturday night.

On monday morning, I made the mistake of showing it to my boss.  He 
made it is personal quest to try to rewrite parts of our existing CGI 
system using this 90 minute version of ColdFusion.

As his quest continued, he found that there were certain features 
that were not present.  It was quickly made a "company project," and 
new features (such as the ability to interface with our existing 
widget and api modules) were added.

Then we switched to using XHTML.  Everything had to be compliant.  We 
started using Expat.  DBQ (now XML::DBQ) started core dumping 
mysteriously.  We traced everything to a problems with the (then 
unstable) Expat libraries.  So we rewrote the XML parser using native 
perl.  Since we now had full control over the parser, we found we 
could add new features (like if else constructs and defines).

Then we added the ability to execute internal perl functions (like 
substr).  Our quest was still not over, and we continued to add more 
features.

And it is now that we realize that we have written a system that is 3 
times slower than CGI, 8 times slower than mod_perl, 10 times more 
difficult to read than perl, and is being used in about 45% of our 
site.

The moral of this story is that using an existing templating system 
will save you more hours of coding, learning, debugging, upgrading, 
adding new features, and maintaining than you could possibly hope to 
account for when writing a "Simple" templating system.

I hope this helps answer any questions about why you should not write 
your own templating system.

Robert Landrum

any trick to exclude some files in FilesMatche

[Surat Singh Bhati]

Hi,

I want to configure the Apache for Apache::PerlRun as:


 SetHandler fastcgi-script
 Options +ExecCGI



SetHandler perl-script
PerlHandler Apache::PerlRun
PerlSendHeader On
Options +ExecCGI
  


But all the .pl , including fast_(.*).pl are run by Apache::PerlRun 
handler, I tryed by changing the order, any trick to make
it working. I cannot get help of the  or  as
all files are in the same dir.

Any solution to exclude the fast_(.*).pl in second expression?

Regards,

-Surat Singh 

Re: The latest templating system: PSP in DDJ

[Joshua Chamas]

Perrin Harkins wrote:
> 
> on 7/7/01 9:30 PM, Ron Pero at [EMAIL PROTECTED] wrote:
> 
> > Just received my issue of Dr. Dobbs Journal today, and one of the articles
> > is "A Tiny Perl Server Pages Engine". Pretty nifty.
> >
> > Read about it here:
> > http://www.ddj.com/articles/2001/0108/0108g/0108g.htm
> >
> > Here is an excerpt:
> > "PSP is modeled after JSP. It is neither an ASP nor a JSP port. PSP
> > includes many JSP-like features and, most importantly, custom tag support.
> > The latter gives you the ability to develop custom tag modules to
> > encapsulate complex server-side behaviors and business rules into simple
> > XML-like elements that content developers can use.
> > PSP shares the same basic elements with JSP..."
> 
> Good grief!  This sounds exactly like Apache::ASP with its XMLSubs feature.
> I give up.

All Andy Yuen, author of PSP, had to do was ask that Apache::ASP
get ported to run under old school CGI... I already have it
mostly working, just never had incentive to finish the job.  

Maybe I'll finish that off now that I've seen lack of ASP's 
CGI support posted in an article   :)

--Josh

_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks <- Web Link Checking  Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051

Re: Apache::SimpleTemplate

[Thomas Eibner]

On Sat, Jul 07, 2001 at 06:00:24PM -0400, Geoffrey Young wrote:
> I actually use Text::Template for all my templating (sigh), and have such a
> wrapper (save just a bit of custom code).  I basically implement the HASH
> version and use a PerlInitHandler to set up the substitutions using pnotes.
> I can work it up into a more generic release if anyone is interested, but
> using Text::Template is really incredibly simple and it's just a few lines
> of code (and actually twice as long as it needs to be due to copious
> debugging), so I really don't think a release is warranted.
> 
> In reality, I feel guilty every time I use it for not migrating to
> TemplateToolkit or one of the other systems available.

Why feel guilty for using something that works for you? I use
CGI::FastTemplate in most the stuff I write now and I'm quite happy with
it, since it gets the job done. I wrote my own wrappers around this
module too, like you and it works pretty well with the rest of the
framework I use. 

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

Re: internet redirection

[Brooklyn Linux Solutions CEO]

BTW

No only is that internet redirectionb, but it is also

INTERNAL redirection it's been a long day.


Ruben

> Greeting
> 
> I have a programing doing interent redirect after
> reading a cookie and doing some authentication.
> 
> I return the OK constant after the redirection, but it 
> seems that a bunch of other calls are being made
> to the server.
> 
> Specifically,
> 
> if you use your browser to call
> 
> http://www.mysite.com/home/
>   it calles a module and the module redirects to
> 
>   http://www.mysite.com/home/restricted/index.html
> 
>   then I return OK.
> 
>   However
> 
>   http://www.mysite.com/home/restricted/ is controlled
>   by a perl module which authenticates.
> 
>   After this module finished, I expected to be done
>   for everything that's a text/html type file.
> 
>   It does some form parsing and returns ok like this:
> 
>   print STDERR "CHOOSE3: FileHandle $fh : Line 48\n";
> 
> print STDERR "CHOOSE3: FileHandle $fh : Line 48\n";
> 
>   $r->send_http_header;
>   my $data;
>   while($data = <$fh>){
>   if($data =~ //){
>   $data =~ 
>s//&include_file($r,$2)/ges;
>   print STDERR "GOT $1 $2\n";
>   }
>   $r->print($data);
>   }
> print STDERR "MUST STOP HERE Line 59\n";
>   return OK;
>   }
> print STDERR "MUST NOT BE HERE Line 62\n";
>   return OK;
> }
> 
> It seems to end, and then I get a bunch of calls from the original URL
> which was called for more files, even index.html again.
> 
> Ideally, after return OK, it is finished retreiving files.  I'm thinking of
> using Apache exit.
> 
> I can't seem to get it to stop cold at this line (Line 59).
> 
> It's like the module stops, and then the redirecting lines in the previous
> module just keeps calling things and ignorns it's return stop command.
> 
>   
>   print STDERR "LINE 72\n";
>   if($status[0] eq 'AUTH' and $obj->site eq 'restricted'){
>   $r->internal_redirect("http://$server/restricted/index.html";);
>   print STDERR "THIS SHOULD NOT BE REACHED LINE 77\n";
>   return OK;
>   print STDERR "THIS SHOULD NOT BE REACHED LINE 79\n";
>   }
>   print STDERR "LINE 80\n";
> 
> 
> 79 is not called, but a bunch of calls are made in the logs
> with the referer  from http:/www.mysite.com/ into the restricted
> directory.
> 
> I've done a hack to decline the processing of these calls, but it seems
> they shouldn't be being created in the first place.
> 
> 
> Ruben
> 

send_httpd_headers

[Brooklyn Linux Solutions CEO]

Is there a way to know that headers have already been sent 
before send headers out?


Ruben

internet redirection

[Brooklyn Linux Solutions CEO]

Greeting

I have a programing doing interent redirect after
reading a cookie and doing some authentication.

I return the OK constant after the redirection, but it 
seems that a bunch of other calls are being made
to the server.

Specifically,

if you use your browser to call

http://www.mysite.com/home/
it calles a module and the module redirects to

http://www.mysite.com/home/restricted/index.html

then I return OK.

However

http://www.mysite.com/home/restricted/ is controlled
by a perl module which authenticates.

After this module finished, I expected to be done
for everything that's a text/html type file.

It does some form parsing and returns ok like this:

print STDERR "CHOOSE3: FileHandle $fh : Line 48\n";

print STDERR "CHOOSE3: FileHandle $fh : Line 48\n";

$r->send_http_header;
my $data;
while($data = <$fh>){
if($data =~ //){
$data =~ 
s//&include_file($r,$2)/ges;
print STDERR "GOT $1 $2\n";
}
$r->print($data);
}
print STDERR "MUST STOP HERE Line 59\n";
return OK;
}
print STDERR "MUST NOT BE HERE Line 62\n";
return OK;
}

It seems to end, and then I get a bunch of calls from the original URL
which was called for more files, even index.html again.

Ideally, after return OK, it is finished retreiving files.  I'm thinking of
using Apache exit.

I can't seem to get it to stop cold at this line (Line 59).

It's like the module stops, and then the redirecting lines in the previous
module just keeps calling things and ignorns it's return stop command.


print STDERR "LINE 72\n";
if($status[0] eq 'AUTH' and $obj->site eq 'restricted'){
$r->internal_redirect("http://$server/restricted/index.html";);
print STDERR "THIS SHOULD NOT BE REACHED LINE 77\n";
return OK;
print STDERR "THIS SHOULD NOT BE REACHED LINE 79\n";
}
print STDERR "LINE 80\n";


79 is not called, but a bunch of calls are made in the logs
with the referer  from http:/www.mysite.com/ into the restricted
directory.

I've done a hack to decline the processing of these calls, but it seems
they shouldn't be being created in the first place.


Ruben

Error in PerlRun

[Surat Singh Bhati]

Hi,

I am not able to run the mod_perl scriptsd as with
Apache::PerlRun, Apache::Registry  is working fine.

PerlRun says :
"filename not found or unable to stat"
and gives the 404 error.

The file is exists there with proper permission, I am able to run same 
file with Apache::Registry 

I changed the PerlRun.pm as:

-35  if (-r $r->finfo && -s _) { 
+35  if (-r $filename && -s _) { 

Now it is working fine. 

Version inormation:
Soralis 2.7
Apache/1.3.12 
mod_perl/1.25
Perl v5.6.0

Can anybody tell me why $r->finfo is not working on my system?

thanks and regards,

-Surat Singh Bhati
http://www.indiamart.com

RE: ePerl (fragment of Re: Apache::SimpleTemplate)

[Todd Finney]

At 02:40 PM 7/8/01, Perrin Harkins wrote:
> > We use ePerl for a fair number of things, and I have yet to run 
> into
> > something we needed of which it was not capable.   What are you
> > thinking of?
>
>It's not a question of it not being capable, it's just that most 
>people seem
>to choose one of the more full-featured tools.

Yea, I'm a glutton for punishment. :/ I don't necessarily mind, though 
- reinventing the wheel periodically is a good learning experience.

>There's lots of talk on the list about Apache::ASP, Embperl, Mason, 
>etc., but not much about ePerl.   (Maybe I should do some research in 
>the mail archives and graph the results.  Sounds like a magazine 
>column...)  Also, I think Text::Template stole some users away from 
>ePerl.

It probably doesn't help that ePerl isn't even listed at 
perl.apache.org with the others.

>Like SSI, ePerl is perfect for some people who just want a simple 
>solution
>that stays out of their way.

...and people that are too lazy to bother remembering the difference 
between [+ +], [- -], and [! !].

cheers,
Todd

Re: ePerl (fragment of Re: Apache::SimpleTemplate)

[Todd Finney]

At 07:47 AM 7/8/01, Ged Haywood wrote:
>On Sat, 7 Jul 2001, Todd Finney wrote:
>
> > We use ePerl for a fair number of things, and I have yet to run 
> into
> > something we needed of which it was not capable.
>
>Didn't I read somewhere that there were security concerns?

There was a fix made in 1998 regarding QUERY_STRING, but I think that 
was the last time anything like that came up.  I'm not even sure 
there's been a new release since then; I suppose that could mean either 
Ralf has lost interest in it, or it's just 'done'.  It's probably a 
little bit of both.

There's a patch to make it work with 5.6 floating around, but I haven't 
seen anything else new in some time.

Todd

Re: Apache::SimpleTemplate

[Perrin Harkins]

on 7/8/01 2:46 AM, Gunther Birznieks at [EMAIL PROTECTED] wrote:
> In addition one of the criteria for "useful" to me is "fast". If the
> template system is slow, it's quite annoying. However, this goes against
> other people's ideas of "useful" being "full featured". As Steven Wright
> says (paraphrased) if you had everything where would you put it?

I think this is more of an issue with CGI.  All of the popular tools are
fast enough under mod_perl that they're very unlikely to be your bottleneck.
It's far more likely to be database work or IPC of some kind that slows down
an application.

Under CGI, the caching schemes of many of these systems don't work.  That
does make a difference.

- Perrin

RE: ePerl (fragment of Re: Apache::SimpleTemplate)

[Perrin Harkins]

> We use ePerl for a fair number of things, and I have yet to run into
> something we needed of which it was not capable.   What are you
> thinking of?

It's not a question of it not being capable, it's just that most people seem
to choose one of the more full-featured tools.  There's lots of talk on the
list about Apache::ASP, Embperl, Mason, etc., but not much about ePerl.
(Maybe I should do some research in the mail archives and graph the results.
Sounds like a magazine column...)  Also, I think Text::Template stole some
users away from ePerl.

Like SSI, ePerl is perfect for some people who just want a simple solution
that stays out of their way.

Also, I believe that security issue Ged referred to was fixed by the author.

- Perrin

Re: The latest templating system: PSP in DDJ

[Robin Berjon]

On Sunday 08 July 2001 03:30, Ron Pero wrote:
> Just received my issue of Dr. Dobbs Journal today, and one of the articles
> is "A Tiny Perl Server Pages Engine". Pretty nifty.
>
> Read about it here:
> http://www.ddj.com/articles/2001/0108/0108g/0108g.htm

Nifty indeed, if you're interested in such systems, you may wish to check out 
AxKit's XSP implementation, it's good, and becoming faster every day.

-- 
___
Robin Berjon <[EMAIL PROTECTED]> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
---
Sleep is no substitute for coffee.

Re: getting URL of refused page, after OnDeny

[wald]

> Can you set up a custom error document handler and redirect to that, 
> rather than using your OnDeny?  Return something like 409
> ("Conflict"), and Apache will do an internal redirect, from which
> you can get the requesting URI in the same way that you can in
> other redirects.
> 

> Actually, how is the require handled? What does your auth handler
> return if the user is not subscribed?  Can/does your handler do an
> internal redirect?

I do (in my C handler):
ap_table_set (r->headers_out, "Location", sec->auth_LNonDeny);
return REDIRECT;

your suggestion sounds good, off to hit my books to see how to do that -
sounds like a good solution (never done an internal redirect - I think -))
  thanks for the pointer,  
  Bob Waldstein   [EMAIL PROTECTED]

Re: problems compiling Embperl 1.3.3 on MacOS X 10.0.4

[Gerald Richter]

Hi,

unfortunately I don't know anything about MaxOS X. The only idea I have, is
to look at other Perl modules, that compiles successfully,
Makefile/Makefile.PL and see where the differences is.

Do you try to compile with or without mod_perl support ? I think you should
start without mod_perl support, because with mod_perl it will need to link
against Apache and this may cause problems.

Let me know if you find anything new!

Gerald

-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-

- Original Message -
From: "Gustav Kristoffer Ek" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 06, 2001 4:08 PM
Subject: problems compiling Embperl 1.3.3 on MacOS X 10.0.4


When I try compiling Embperl, it dies when it comes to
blib/arch/auto/HTML/Embperl/Embperl.bundle:

cc -o blib/arch/auto/HTML/Embperl/Embperl.bundle  -bundle -undefined
suppress Embperl.o epmain.o epio.o epchar.o epcmd.o eputil.o epeval.o
epapinit.o

/usr/bin/ld: multiple definitions of symbol _embperl_module
Embperl.o definition of _embperl_module in section (__DATA,__common)
epmain.o definition of _embperl_module in section (__DATA,__common)
epio.o definition of _embperl_module in section (__DATA,__common)
epchar.o definition of _embperl_module in section (__DATA,__common)
epcmd.o definition of _embperl_module in section (__DATA,__common)
eputil.o definition of _embperl_module in section (__DATA,__common)
epeval.o definition of _embperl_module in section (__DATA,__common)
epapinit.o definition of _embperl_module in section (__DATA,__data)

Any thing I can do to bugtraq and resolve this?

- gustav

--
Gustav Kristoffer Ek,  Netcetera, Brolæggerstræde 4, 1211 København K
+45 33147000, +45 2045, fax +45 33146200 http://www.netcetera.dk/

Re: Apache::SimpleTemplate

[Gunther Birznieks]

At 06:16 PM 7/7/2001 -0700, brian moseley wrote:
>On 7 Jul 2001, Randal L. Schwartz wrote:
>
> > Yes.  Writing a templating system in Perl is trivial.
> > Writing a *useful* templating system in Perl is
> > demonstratably hard.
>
>unless you keep application features in a separate layer
>from the templating system (eg the servlet api ;)


I think it is still quite difficult. Even if you have servlets, for 
example, adding JSPs was quite a task. At issue is providing a minimal API 
yet still allow the templates to do things that weren't originally intended.

In addition one of the criteria for "useful" to me is "fast". If the 
template system is slow, it's quite annoying. However, this goes against 
other people's ideas of "useful" being "full featured". As Steven Wright 
says (paraphrased) if you had everything where would you put it?

So to make something that is powerful yet fast is quite the challenge. And 
then there are architectural tradeoffs as to the type of application that 
the template is being used for. Transactions? Portal based? Integrating 
many apps together? Standalone?

Later,
   Gunther

Re: ePerl (fragment of Re: Apache::SimpleTemplate)

[Ged Haywood]

Hi there,

On Sat, 7 Jul 2001, Todd Finney wrote:

> We use ePerl for a fair number of things, and I have yet to run into 
> something we needed of which it was not capable.

Didn't I read somewhere that there were security concerns?

> Just asking.

Ditto.

73,
Ged.

Re: modperl install without Apache src?

[Ged Haywood]

Hi all,

On Fri, 6 Jul 2001, Doug MacEachern wrote:

> On Fri, 6 Jul 2001, Ged Haywood wrote:
>> On Thu, 5 Jul 2001, Knox, Laurie A, NPONS wrote:
>>> I was going to upgrade it to 1.25, but I don't have the Apache src.
>> Why don't you just get it?

> there should be no need if apache was properly installed with a header tree.
> mod_perl can be built as a dso without the apache source tree

Hmm, when did you ever see me recommend DSO?  (Especially on Solaris... :)
But I have to admit that it seems far fewer people are having trouble
with it lately.

73,
Ged.

RE: modperl install without Apache src?

[Ged Haywood]

Hi there,

On Fri, 6 Jul 2001, Knox, Laurie A, NPONS wrote:

>I read somewhere that there were potential problems when running
>mod_perl and PHP together in Apache, but I haven't been able to find
>that info again  Is this an issue?

I fear it is.  Lots of people seem to run into trouble with that
combination, I think Doug is looking at it again right now.

> I don't have ultimate control over this server I'm working on

Hmm, that's a nuisance.

73,
Ged.