Mailing List Archive

Two feature requests
Gerald et al:

In our use of embperl on the www.research.att.com web site, we've come across
a number of pains with respect to embperl and people who have pages that don't
want embperl. Inertia causes these people to not want to have to do a thing to
their work (like changing file extensions to something that doesn't go through
embperl or double bracketing), and I find that completely understandable but
unfortunate.

People have made two requests which I think might be useful to put into
Embperl. Please let me know if you agree or disagree.

1) With documents that contain no embperl code, the last-modified header is
included to be the actual last-modified date of the file.

2) Put in a special embperl command that basically means "stop looking for
embperl from here down in this document".

Regards,
Christian

-----------------
Christian Gilmore
Senior Technical Staff Member
AT&T Labs IP Technology, Florham Park
cgilmore@research.att.com
http://www.research.att.com/info/cgilmore
RE: Two feature requests [ In reply to ]
Hi,

> In our use of embperl on the www.research.att.com web site,
> we've come across a number of pains with respect to embperl
> and people who have pages that don't want embperl.

shouldn't the system work the other way around - enable embperl
where you need it (from .htaccess file for example), not disable
where you don't?


Rgds,
Tfr

--==< tfr@cafe.ee >==< http://tfr.cafe.ee/ >==< +1-504-4467425 >==--
RE: Two feature requests [ In reply to ]
If one were building a system from scratch, I'd certainly agree with you. When
one puts embperl into an already-built environment using an extension (.html)
that is already in wide use, you find that you often wish to disable embperl
on file that already exist and do not use embperl. Our choice was not made
lightly. It was the best solution to a murky situation. If you care, I could
go into detail on it.

Since there's no UnSetHandler, once you've set the handler for a certain file
pattern ( .*\.html$ ), you're stuck with it across the entirety of the site.

Regards,
Christian

> -----Original Message-----
> From: embperl-return-46-cgilmore=research.att.com@perl.apache.org
> [mailto:embperl-return-46-cgilmore=research.att.com@perl.apache.org]On
> Behalf Of indrek siitan
> Sent: Thursday, March 23, 2000 10:13 AM
> To: Christian Gilmore; embperl@perl.apache.org
> Subject: RE: Two feature requests
>
>
> Hi,
>
> > In our use of embperl on the www.research.att.com web site,
> > we've come across a number of pains with respect to embperl
> > and people who have pages that don't want embperl.
>
> shouldn't the system work the other way around - enable embperl
> where you need it (from .htaccess file for example), not disable
> where you don't?
>
>
> Rgds,
> Tfr
>
> --==< tfr@cafe.ee >==< http://tfr.cafe.ee/ >==<
> +1-504-4467425 >==--
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>
RE: Two feature requests [ In reply to ]
> Since there's no UnSetHandler, once you've set the handler for a certain file
> pattern ( .*\.html$ ), you're stuck with it across the entirety of the site.

You should be able to do something like this:

<Location /no_embperl>
SetHandler default
</Location>

and as long as you put this after you setup embperl, apache will use the
default handler.


>
>> -----Original Message-----
>> From: embperl-return-46-cgilmore=research.att.com@perl.apache.org
>> [mailto:embperl-return-46-cgilmore=research.att.com@perl.apache.org]On
>> Behalf Of indrek siitan
>> Sent: Thursday, March 23, 2000 10:13 AM
>> To: Christian Gilmore; embperl@perl.apache.org
>> Subject: RE: Two feature requests
>>
>>
>> Hi,
>>
>> > In our use of embperl on the www.research.att.com web site,
>> > we've come across a number of pains with respect to embperl
>> > and people who have pages that don't want embperl.
>>
>> shouldn't the system work the other way around - enable embperl
>> where you need it (from .htaccess file for example), not disable
>> where you don't?
>>
>>
>> Rgds,
>> Tfr
>>
>> --==< tfr@cafe.ee >==< http://tfr.cafe.ee/ >==<
>> +1-504-4467425 >==--
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
>> For additional commands, e-mail: embperl-help@perl.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org

---
Jason Bodnar + jbodnar@tivoli.com + Tivoli Systems

I swear I'd forget my own head if it wasn't up my ass. -- Jason Bodnar
RE: Two feature requests [ In reply to ]
Huh. I learn something new every day. Thanks, Jason. That did work.

Regards,
Christian

> -----Original Message-----
> From: jbodnar@jbodnar.dev.tivoli.com
> [mailto:jbodnar@jbodnar.dev.tivoli.com]On Behalf Of Jason Bodnar
> Sent: Thursday, March 23, 2000 12:02 PM
> To: Christian Gilmore
> Cc: embperl@perl.apache.org; indrek siitan
> Subject: RE: Two feature requests
>
>
> > Since there's no UnSetHandler, once you've set the handler
> for a certain file
> > pattern ( .*\.html$ ), you're stuck with it across the
> entirety of the site.
>
> You should be able to do something like this:
>
> <Location /no_embperl>
> SetHandler default
> </Location>
>
> and as long as you put this after you setup embperl, apache
> will use the
> default handler.
>
>
> >
> >> -----Original Message-----
> >> From: embperl-return-46-cgilmore=research.att.com@perl.apache.org
> >>
> [mailto:embperl-return-46-cgilmore=research.att.com@perl.apache.org]On
> >> Behalf Of indrek siitan
> >> Sent: Thursday, March 23, 2000 10:13 AM
> >> To: Christian Gilmore; embperl@perl.apache.org
> >> Subject: RE: Two feature requests
> >>
> >>
> >> Hi,
> >>
> >> > In our use of embperl on the www.research.att.com web site,
> >> > we've come across a number of pains with respect to embperl
> >> > and people who have pages that don't want embperl.
> >>
> >> shouldn't the system work the other way around - enable embperl
> >> where you need it (from .htaccess file for example), not disable
> >> where you don't?
> >>
> >>
> >> Rgds,
> >> Tfr
> >>
> >> --==< tfr@cafe.ee >==< http://tfr.cafe.ee/ >==<
> >> +1-504-4467425 >==--
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> >> For additional commands, e-mail: embperl-help@perl.apache.org
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> > For additional commands, e-mail: embperl-help@perl.apache.org
>
> ---
> Jason Bodnar + jbodnar@tivoli.com + Tivoli Systems
>
> I swear I'd forget my own head if it wasn't up my ass. -- Jason Bodnar
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>
RE: Two feature requests [ In reply to ]
>
> In our use of embperl on the www.research.att.com web site,

Could you write me a few words about it for
http://perl.apache.org/embperl/Sites.pod.1.html

>
> People have made two requests which I think might be useful to put into
> Embperl. Please let me know if you agree or disagree.
>
> 1) With documents that contain no embperl code, the last-modified
> header is
> included to be the actual last-modified date of the file.
>
> 2) Put in a special embperl command that basically means "stop looking for
> embperl from here down in this document".
>

I think Jason already pointed out how you do this within the Apache config,
but both points maybe usefull in other contexts too, basicly when you want
to include files (with Execute), which doesn't contain Embperl commands. The
last modified header will also come into play, once we have caching of the
output.

Gerald


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

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------