Re: modperl Digest 15 Jun 2002 20:05:58 -0000 Issue 797
Hi First thanks for your answer. Date: 14 Jun 2002 12:33:35 -0400 To: [EMAIL PROTECTED] From: Vivek Khera [EMAIL PROTECTED] Subject: Re: location of LoginScript in Apache::AuthCookie* modules Message-ID: [EMAIL PROTECTED] ED == Eric Doutreleau [EMAIL PROTECTED] writes: ED Right now i would like to make user authenticate throug a SSL ED page. ED In order to do that i modify the configuration script to use ED PerlSetVar WhatEverLoginScript https://corbeau/perl/login.pl Well, in order to be able to get the original location, this has to be done via an internal redirect. When you switch protocols (ie, from http to https) you cannot do internal redirect. I was indeed afraid of that. But really, your login page doesn't need to be ssl secured as there is no information in it. What you want is the target of the from in that page to be aimed at an SSL URL. That's the transaction you want secured, since that's where the id/password are sent. Well what i want to secure is the sending of the login/ password. But i don t want at all to send the html pages in sll. Therefore i want to switch on ssl for sending the login and password and switch back to http after when i set the cookie. Is that possible? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ --
Re: [RFC] Change our habits in module naming?
At 17:01 16.06.2002, Perrin Harkins wrote: I have been thinking about a reorganization of the Apache/Perl modules for a while, and have come to the conclusion that it would probably be a good idea. Please tell me what you think about this proposal. Sounds fine to me. I would suggest creating a brief document with naming guidelines that people can be referred to. Also, a module map might be a good thing to create, i.e. an improved version of this: http://perl.apache.org/src/apache-modlist.html. Well, because the module list has now moved into the Perl Module List entirely, we are removing it with the new site. However, I have created a new document which takes over that task somewhat, here: http://perl.apache.org/release/products/apache-modules.html . That's where I was thinking to have the guidelines. As for the organization of the module list, I suppose that new modules that adapt these guidelines will be correctly organized into the Perl module list (because of their different namespaces). -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: [RFC] Change our habits in module naming?
Also, a module map might be a good thing to create, i.e. an improved version of this: http://perl.apache.org/src/apache-modlist.html. Well, because the module list has now moved into the Perl Module List entirely, we are removing it with the new site. What I meant was that since you can't expect all of the existing modules to change their names you could make a little directory page that follows the organization you're proposing and have it list the existing modules in each category. Maybe not worth it, but it could be useful for newbies. - Perrin
Re: [RFC] Change our habits in module naming?
At 18:01 16.06.2002, Perrin Harkins wrote: Also, a module map might be a good thing to create, i.e. an improved version of this: http://perl.apache.org/src/apache-modlist.html. Well, because the module list has now moved into the Perl Module List entirely, we are removing it with the new site. What I meant was that since you can't expect all of the existing modules to change their names you could make a little directory page that follows the organization you're proposing and have it list the existing modules in each category. Maybe not worth it, but it could be useful for newbies. Yes, I see your point, but my proposal was loosely tied to the categories already existing here: http://www.cpan.org/modules/00modlist.long.html#ID15_WorldWideW (browse down to 'Apache'), so the classification has been done already. -- Per Einar Ellefsen [EMAIL PROTECTED]
CGI::Application
Hi, I am still working on building a framework, design plan for this busy site I am working on. It is a total revamp so I have the chance to do things right I have been looking into HTML::Template which is a lot simper than Embed perl or the template tool kit. I am wondering if anyone has experence with using both of these with Registry.pm I have decided to make my modules class modules instead of traditional modules, and thanks to Perrin's great article, I have a lot more confidence in my basic plan. There are some differences between our site and etoyz. Our site is not nearly as loaded. Busy, but not giant. Still, I would like to build something that can get that big without another total rewrite, moving things around, new hardware sure, but not a whole change to the system. Right now things are small enough that the rewrite will only take a few weeks. So I am looking for gotchas, and other problems that could come esp from CGI::Application because it doesn't make much mention of working under mod_perl. I think the modes could be appealing to the PHP guys in my office. It could give them something to chear about, since I think right now they just look at mod_perl as being more work than PHP which is probably true. I am also sure that the HTML templates will make the boss very happy because he is always changing HTML in scripts and breaking the scripts, then calling and saying, hey the form isn't working anymore! :( The big points I want to achieve right now, is to make everything I write OOP, separate HTML from code as much as possible, and to not make it impossible to deal with for the people I work with who don't know as much perl as I do. Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: CGI::Application
On Sun, 16 Jun 2002, Eric Frazier wrote: I have been looking into HTML::Template which is a lot simper than Embed perl or the template tool kit. I am wondering if anyone has experence with using both of these with Registry.pm I do! Back when I worked for Jesse Erlbaum (the author of CGI::Application) most of our development was in CGIs designed to be run under Apache::Registry. CGI::Application uses CGI.pm for all its CGI services and CGI.pm works great under Apache::Registry. The big points I want to achieve right now, is to make everything I write OOP, separate HTML from code as much as possible, and to not make it impossible to deal with for the people I work with who don't know as much perl as I do. That sounds like an excelent goal. Feel free to drop by the CGI::Application (and HTML::Template) mailing-list if you run into trouble. -sam
Re: CGI::Application
soapbox
Grr. Why can't people just write bloody applications with HTML in them
instead of spending so much energy tryuing to find a way to avoid writing
any HTML?
I mean, it's not that hard. Formulate what you want parts to do, make a sort
of vanilla, unformatted output here-doc ior template file for each part as
necessary, get the functionality going, then prety it up by copying each
here-doc or template file into Dreamweaver or something, formatting the HTML
to look nice, and then moving the formattted html back in.
Template. Mason. Yecch. I feel mildly nauseated every time I hear about
stuff like Mason and similar cop-outs. If people would spend half the time
learning to output their own HTML that they do trying to find ways around
doing so, they'd get a lot more programs written, and there would be less
ugly, clunky, messy, badly-interfacd, hard-to-use and ungodly slow web
applications out there.
I'm still distastefully amazed when I find people using CGI.pm to print a
content-type header on something that in no other way uses CGI.pm, has no
cookies, or anything else. Yes, I have actually seen someone use CGI to do
nothign more than dump their environment variables, when a simple;
print Content-type:
text/html\n\ndl\n,map(dt$_/dt\ndd$ENV{%_}/dd\n, sort keys
%ENV),/dl\n;
would do the job perfectly fine.
/soapbox
- Original Message -
From: Eric Frazier [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, June 16, 2002 10:02 AM
Subject: CGI::Application
Hi,
I am still working on building a framework, design plan for this busy site
I
am working on. It is a total revamp so I have the chance to do things
right
I have been looking into HTML::Template which is a lot simper than Embed
perl or the template tool kit. I am wondering if anyone has experence with
using both of these with Registry.pm I have decided to make my modules
class modules instead of traditional modules, and thanks to Perrin's great
article, I have a lot more confidence in my basic plan. There are some
differences between our site and etoyz. Our site is not nearly as loaded.
Busy, but not giant. Still, I would like to build something that can get
that big without another total rewrite, moving things around, new hardware
sure, but not a whole change to the system. Right now things are small
enough that the rewrite will only take a few weeks.
So I am looking for gotchas, and other problems that could come esp from
CGI::Application because it doesn't make much mention of working under
mod_perl. I think the modes could be appealing to the PHP guys in my
office. It could give them something to chear about, since I think right
now
they just look at mod_perl as being more work than PHP which is probably
true. I am also sure that the HTML templates will make the boss very happy
because he is always changing HTML in scripts and breaking the scripts,
then
calling and saying, hey the form isn't working anymore! :(
The big points I want to achieve right now, is to make everything I write
OOP, separate HTML from code as much as possible, and to not make it
impossible to deal with for the people I work with who don't know as much
perl as I do.
Thanks,
Eric
http://www.kwinternet.com/eric
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: CGI::Application
At 01:06 PM 6/16/02 -0400, Sam Tregar wrote: On Sun, 16 Jun 2002, Eric Frazier wrote: I have been looking into HTML::Template which is a lot simper than Embed perl or the template tool kit. I am wondering if anyone has experence with using both of these with Registry.pm I do! Back when I worked for Jesse Erlbaum (the author of CGI::Application) most of our development was in CGIs designed to be run under Apache::Registry. CGI::Application uses CGI.pm for all its CGI services and CGI.pm works great under Apache::Registry. Well I was hoping for some 3rd parties :) That is great news! The big points I want to achieve right now, is to make everything I write OOP, separate HTML from code as much as possible, and to not make it impossible to deal with for the people I work with who don't know as much perl as I do. That sounds like an excelent goal. Feel free to drop by the CGI::Application (and HTML::Template) mailing-list if you run into trouble. -sam Thanks Sam, It is pretty cool, the more serious work I have to do, the more I appreciate the mod_perl list. I am starting to think that in general mod_perl guys are nice guys :) Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: CGI::Application
Hi,
I think mostly it is about having standards and in a business env making it
so that people who only know part of the picture can still work on the
project as a whole. Sounds like OOP huh? HTML in perl scripts just messes
that whole thing up, like I said before, our fearless leader can mess up
stuff now because HTML is in the scripts and he then edits the scripts,
messes *something* up and we have to fix it.(I an new btw just started 3
weeks ago and am cleaning up the mess). Well then, put the HTML in a
module, fine you can do that, but then why not make a system that makes
doing that basic idea easy? And even a system that once you choose to use it
will not get altered and played with by every programer on staff.
I do agree about the CGI pm stuff though. It is goofy to use print header
instead of print content type but still that is getting kind of anal. If it
really matters to your scripts then that would be kind of weird.
Thanks for your thoughts,
Eric
At 01:28 PM 6/16/02 -0400, Dodger wrote:
soapbox
Grr. Why can't people just write bloody applications with HTML in them
instead of spending so much energy tryuing to find a way to avoid writing
any HTML?
I mean, it's not that hard. Formulate what you want parts to do, make a sort
of vanilla, unformatted output here-doc ior template file for each part as
necessary, get the functionality going, then prety it up by copying each
here-doc or template file into Dreamweaver or something, formatting the HTML
to look nice, and then moving the formattted html back in.
Template. Mason. Yecch. I feel mildly nauseated every time I hear about
stuff like Mason and similar cop-outs. If people would spend half the time
learning to output their own HTML that they do trying to find ways around
doing so, they'd get a lot more programs written, and there would be less
ugly, clunky, messy, badly-interfacd, hard-to-use and ungodly slow web
applications out there.
I'm still distastefully amazed when I find people using CGI.pm to print a
content-type header on something that in no other way uses CGI.pm, has no
cookies, or anything else. Yes, I have actually seen someone use CGI to do
nothign more than dump their environment variables, when a simple;
print Content-type:
text/html\n\ndl\n,map(dt$_/dt\ndd$ENV{%_}/dd\n, sort keys
%ENV),/dl\n;
would do the job perfectly fine.
/soapbox
http://www.kwinternet.com/eric
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: CGI::Application
Dodger opined on the soapbox: Grr. Why can't people just write bloody applications with HTML in them instead of spending so much energy tryuing to find a way to avoid writing any HTML? Because I don't want to have to go find a!@#$*^$ Perl programmer every time the marketing department or a customer wants their website re-themed. And being a Perl programmer, thank deity-of-choice Perl programmers cost more than HTML coders. Because I don't want to have to figure out what *your* code was doing when you wrote it two years ago and are now long, long since gone. *THAT* is why everyone is so interested in Mason, Template, XSLT and all of the other templating technologies. It's a simple business decision. Mike808/ -- () Join the ASCII ribbon campaign against HTML email and Microsoft-specific /\ attachments. If I wanted to read HTML, I would have visited your website! Support open standards.
Re: CGI::Application
On Sunday, June 16, 2002, at 07:02 AM, Eric Frazier wrote: The big points I want to achieve right now, is to make everything I write OOP, separate HTML from code as much as possible, and to not make it impossible to deal with for the people I work with who don't know as much perl as I do. One thing that has proven immensely beneficial on the project that I'm working on now, which is very similar to yours in that it's a complete redo intended to be 'right', is this: Write each page's functionality in a package that is 100% removed, interface-wise, from HTML, then 'glue' that module to HTML (via HTML::Template for output and CGI.pm for input) in a module name identical to, but preceded by Apache:: So, we have a page module like: Functionality in CompanyName::page1, and glue code in Companyname::Apache::page1 Modules NOT under the CompanyName:: namespace cannot be dependent IN ANY WAY on mod_perl, but must be mod_perl clean, of course. This makes the module functionality very easy to test WITHOUT firing up Apache. We have a complete white box test suite that tests at the Perl level, and complete black box test suite that tests at the HTTP level. This proved a good strategy when we decided to implement a SOAP interface to some of our functionality. We made some new glue code in CompanyName::SOAP::page1 that was based on SOAP::Lite and it was just as easy as it should be, with 100% code reuse. -- -- Tom Mornini -- InfoMania Printing and Prepress -- -- ICQ: 113526784, AOL: tmornini, Yahoo: tmornini, MSN: tmornini
RE: [RFC] Change our habits in module naming?
On Sun, 16 Jun 2002, Jonathan M. Hollin wrote: I have been thinking about a reorganization of the Apache/Perl modules for a while, and have come to the conclusion that it would probably be a good idea. Please tell me what you think about this proposal. Per Einar, I have cut most your email only for convenience... I agree with you. It would be great (necessary?) to reorganise the mod_perl modules on CPAN ready for mod_perl/apache v2. Users of v1 would also benefit from a more descriptive name-space. However, the major problem, as I see it is, is simply that people already KNOW modules by a specific name and changing them is probably going to lead to confusion and possibly even some bitterness. If I'm setting up a new server I'm going to be mighty pissed to have to unlearn what I know about the mod_perl module namespace... If you think this can be overcome (symbolic links on CPAN anyone?), or if you see major support for your proposal, then you also have my vote. I think your idea is sound and logical. Nice one. It is a really good suggestion ... The existing modules not following a naming convention do pose a problem, though, and possibly future ones who don't/can't follow such a convention for various reasons (historical, ignorance, multi-purpose, ...). And then one might get back to having to manually edit the module list to add these To try to automate somewhat the idea of creating Apache subcategories, and to accommodate existing/future modules, what about doing something like PAUSE does in how it creates top-level categories? That is, have a form which presents a list of some number of subcategories of Apache (eg, some variation of those Per Einar had: authentication, logging, database, , ), and the author chooses one (or more) subcategories she/he would like her/his module to appear in. For each subcategory a number of subsubcategories are then automatically created, based on the module name, and the name of the distribution then appears in the subsubcategory. In this way existing modules can be categorized without having to change their names (some of which probably never will, even with modperl-2). As well, it can make allowance for relevant distributions (eg, Embperl, HTML-Mason, SOAP-Lite) for which one might not even think to look under an Apache::* namespace, or those which may fall into one or more subcategories. Finally, manual editing of the list will be kept to a minimum, as the author will be able to do most things ... best regards, randy kobes
