Quoting Mark Stosberg [EMAIL PROTECTED]:
Another method would be to put the $DBH in a CGI::App param.
This makes the handle available everywhere you have a sub-class of
your CGI Application with:
sub foo {
my $self = shift;
my $dbh = $self-param('dbh');
}
That seems
Quoting Jesse Erlbaum [EMAIL PROTECTED]:
Hi Nate --
I have a few projects written with CGI::App right now. A
couple of them
are lower traffic sites but now a few of them are falling
into the realm
of performance intensive. I'd like to start using mod_perl for those
sites.
Quoting Jesse Erlbaum [EMAIL PROTECTED]:
Hi All --
I have a little module I've been working on, and I'd love to get some
feedback. You can download it here:
I finally found some time to look at your new module... It looks very
interesting. I definately think it will be useful to people.
Quoting Brett Sanger [EMAIL PROTECTED]:
On Thu, Apr 03, 2003 at 10:19:25AM -0500, Steve Comrie wrote:
I've been using HTML::FillInForm to get this job, and other similar ones
done quickly and easily.
Ditto. I'm not using HTML::Template, so I have my own output() routine
to call Template
Quoting Jesse Erlbaum [EMAIL PROTECTED]:
Hi Chris --
How is Apache::Registry much easier than this? As Chamas
indicates a
handler is somewhat faster than Apache::Registry. This speed
margin (and
CPU savings) is an easy comfort given the painlessness of doing so.
I guess that's
Quoting Flowers, Jay [EMAIL PROTECTED]:
Well I don't know why this, but it seems that this problem is due to
windows XP. The same setup on a windows 2000 server machine works as
expected. I have inspected the headers with wget -S and I see no
difference between the OSes. I also found that
Quoting Steve Comrie [EMAIL PROTECTED]:
You could have a cgiapp_prerun in your superclass, and also have one in
your
application module. If you want both to be executed, then you just have
to
remember to call $self-SUPER::cgiapp_prerun() in the cgiapp_prerun of
your
application
Quoting Eric Moore [EMAIL PROTECTED]:
Randall Swartz said something to the effect of you shouldn't let anyone
know what you are using for cgi. He was speaking of using extensions to
file names like .pl.
Security through obscurity?
Security through obscurity is only bad if it is the only
Quoting Mark Fuller [EMAIL PROTECTED]:
I do not know CGI::Minimal, but CGI::Application does not use the
HTML-producing functions of CGI.pm.
Thanks. CGI::Minimal is just a way to get access to CGI vars without
accepting all the more popular things CGI.pm gives.
...
Do you know how I can
Quoting Mark Fuller [EMAIL PROTECTED]:
I use cgiapp_init to retrieve session tracking from a MySQL table, and
determine if the visitor needs to sign in (either because no
session-tracking row was found or the information expired due to
inactivity). I know how to redirect to the login
Quoting Mark Fuller [EMAIL PROTECTED]:
For session tracking, I keep the values in a hash and update the table in
the teardown method. I thought this would be a faster way to update the
session-tracking table because, by then, I the runmode would have emitted
its output and the visitor would be
Quoting Mark Stosberg [EMAIL PROTECTED]:
header_props - works as is
Keeping header_props unchanged sounds like a good idea in order not to
break things.
I think I prefer to move forward with allow header_props to be called
multiple times.
header_add- add a header of this
Quoting Thilo Planz [EMAIL PROTECTED]:
header_add- add a header of this type to the current list
I think adding a header of this type to the current list makes sense
only for cookies.
Passing a list (arrayref) to CGI-header does not work with other
headers than cookies:
Quoting Mark Stosberg [EMAIL PROTECTED]:
These are good concerns. My concern is about proliferation of the C::A
interface. If we have header_add, but /not/ add_cookie, I could be
happy.
header_add() can be documented to explain It's really only useful for
cookies and warnings right now.
there...
Cheers,
Cees
Quoting Cees Hek [EMAIL PROTECTED]:
Quoting Jesse Erlbaum [EMAIL PROTECTED]:
Hello all --
Cees, Mark, and I are in a conversation regarding changes to the
functionality of header_props() in version 3.2. Before I reply to Cees'
message, I wanted to forward
Quoting Bill McCormick [EMAIL PROTECTED]:
Ok I see.
# allow only the guest user, for real applications use a subclass
meaning override the _login sub? I don't think I like that. I think I'll
build a feature that allows you to pass in a hash of user/passwd values.
Thoughts?
What you
been added to allow setting extra headers, particularly
cookies,
after header_props has already been called (Cees Hek, Mark Stosberg)
I still think I like having the header_set and header_add functions instead of
just the header_add. The way you have implemented header_add seems like
petersm wrote:
Hello all,
We have several large sites that are using CGI::App and we are very unhappy
with our current testing methods which consist of trying to do everything a
stupid user would do to try and break the app and then fixing problems as they
occur. This isn't that bad for smaller
John Day wrote:
Hi,
I am using CGI::Application::ValidateRM in a webapp and i tmust be too late in teh week for clear thinking.
I need to do a check on a cofirmation password. You know, the old signup page that asks you to confirm the password by retyping it. Is there a simple way of doing it
I just noticed that CGI::Application is the module being showcased on
the Perl Advent Calendar today.
http://perladvent.org/2003/8th/
For anyone who hasn't found this gem yet, you are definately missing
out. I already found a couple of new useful modules that I didn't know
about this year
Mark Stosberg wrote:
Since so many of us use DBI database handles and session management, I
would love to see some plug-in modules to add these kind new methods.
Perhaps something in the spirit of ::ValidateRM would work. (I think
that technique is called mix-in module.
Well, I found a couple of
Mark Stosberg wrote:
Has anyone used Ima::DBI for database handle management with CGI::App? I
understand it's used for this as part of the popular Class::DBI
framework.
I have been using it indirectly, since I use Class::DBI for most of my
web applications. It does make it a cinch to work with
Mark Stosberg wrote:
I've now reviewed the POD and code for this. I find it very useful.
Sure, it's very simple. That means I can focus on CGI::App and
CGI::Session and this little glue module will just work and be easy to
use. So I give the usefulness two thumbs up.
Thanks.
I have one
Mark Stosberg wrote:
On 2004-01-21, Terrence Brannon [EMAIL PROTECTED] wrote:
Cees Hek wrote:
What if someone wants to create a CGI::Application::Session module
based on Apache::Session?
Someone has:
http://perlmonks.org/index.pl?node_id=142050
Thanks for the reference. I definitely don't
petersm wrote:
From: Cees Hek [EMAIL PROTECTED]
We actually do something like this in the CheesePizza. The base class for all
of our plugins (named 'Plugin' btw) has an implementation of cgiapp_prerun
that looks to see if a param named 'preRun' exists. It it does, then it is
run. This was any
petersm wrote:
I agree with Mark. I don't see why you have a problem with a call like
$self-SUPER::cgiapp_prerun(). If they are overriding a method but they still
want that method to run then I think this is a very clean and easy solution.
For the most part I feel that there are enough hooks that
From: Stephen Howard [EMAIL PROTECTED] wrote
do consider when making your hook stacks that it might be handy for a
module to be able to state a preference as to whether it would rather
it's version of the method in question to be run before or after the
methods of its parent module(s). There
Stewart C. Russell wrote:
I'd agree with all of those, William, but it's only fair to note that
there are downsides:
- There can a considerable performance hit using CDBI over embedded SQL.
Yes, there is always a tradeoff with abstraction. But as you know, you
can default to the Ima::DBI
Stephen Howard wrote:
That makes a lot of sense to me for things like Session and DBI, which
could install things similar to $self-query ($self-dbh,
$self-session), but I don't see why a mixin would need to hook into the
pipeline, rather than be called upon by methods in the pipeline.
Perhaps
Sam Tregar wrote:
That could be. My evaluation was necessarily cursory. I've never
actually used any of the modules I so casually discarded.
Well, you probably realized very quickly that Class::DBI doesn't really
work well when using HTML::Template (which you are using for obvious
reasons).
[
Domizio Demichelis wrote:
I think Domizio's case is similar, even though it's not a sub-class,
because it passes all the current CGI::App tests.
I would be careful about stating that it passes all the tests, because I
don't believe it does. The failures seem to be minimal but they are
there.
Bob Hicks wrote:
I have 5.8.2.808 and I am only using CGI-Application and HTML-Template.
I am going to do a reinstall of Apache to see if that is a problem as
well.
I should have reread the Subject and I would have realized you were
using 5.8.2...
Ah! From the log:
[Mon Jan 26 14:12:29 2004]
Mark Stosberg wrote:
What are other specific features that would make TT attractive to an
H::T user? Someone already mentioned the ability to more easily
reference objects. What are some other favorite features that get used
frequently?
Like I have mentioned in a previous email, my main reason for
Vitaliy Babiy wrote:
Hi guys!
One more question...
I need to check registration form, so there are two 'password' fields, they must be
identical.
It's simple how to check they are not blank, but how to check identity?
And I need to check if choosen login is exists.
The question is - how to do
Steve Hay wrote:
but that's no great hardship. Even that could be made easier, e.g.
enhance CGI::Application's import() method so that users can say
use CGI::Application qw(-apache_request);
to tell CGI::Application to load and use Apache::Request, rather than
the CGI.
In other words,
Jesse Erlbaum wrote:
In a pure mod_perl environment, this would have to be implemented via
the httpd.conf or .htaccess file:
PerlHandler My::App
I'm happy with that interface. CGI-App could simply implement a
handler() method which constructs and runs CGI-App.
Also, we need a method, via
[EMAIL PROTECTED] wrote:
One further request, and this could generate a flame war, which I
have neither the time, nor the interest to entertain, is the dedicated
support of a session module, and obviously, it should also be persistantly
available througout the application like query(), and
I'd like to announce that the first public release of
CGI::Application::Session is now available on CPAN. This module
seamlessly integrates CGI::Session support into CGI::Application. Since
this is the first public release, the code is still considered alpha,
and the functionality is
[EMAIL PROTECTED] wrote:
Is there an easy way to get this to work with an earlier version of C::A,
in light of the critical bug announced earlier this morning?
The only feature that depends on CGI::App 3.21 is the automatic cookie
support. If you don't mind handling the cookies yourself, then
Sam Tregar wrote:
On Wed, 11 Feb 2004, Cees Hek wrote:
Here is the simplest example of how to use this module:
use base qw(CGI::Application);
use CGI::Application::Session;
I love the idea, but this usage seems a little suspect to me. It
reminds me of Time::Piece::MySQL, which also adds
David Kaufman wrote:
i'm not sure if or how the C::A::Session Cees has announced relates to
the CGI::Session which i've used, the other Session modules that i've
seen, or others that i've heard mentioned, but the fact that there is
more than one on the market is a strong argument IMO for adding
Eric wrote:
Hi,
I want to make a progress bar showing time expired and using $|=1 for this statement.
The easiest, and most common way to do this is to post to an interim
page that shows the progress bar, and have that page automatically
redirect to the real page which can take it's time doing
Hi Adrian,
I just tried your code snippet, and I got the expected results!
There must be something else that you are doing that is causing your
problem. One note, you do realize that you aren't supposed to be
printing anything from your scripts right? I am assuming that you used
print in
Quoting Brian Cassidy [EMAIL PROTECTED]:
Hi All,
Something I've been wanting for a while now is a generic caching system to
plug in to CGI::Application. For example, I have a CGI::App which uses
Gedcom.pm. Some of its operations can be quite lengthy, thus caching would
be wise.
The
Quoting Scott Prelewicz [EMAIL PROTECTED]:
After days of frustration, I must turn to the list for some help. Below
is my code for the start of a rewrite of a shopping cart. I am rewriting
it to CGI::App with CGI::App:Sess. I don't know what Im doing wrong and
about to give up. I cat get the
Quoting Scott Prelewicz [EMAIL PROTECTED]:
Based on a user config option, at a point in my script I want to either
call a format_html function or redirect to another url. In both cases, I
have tosend out the cookie. Where should I put this if.else, and how do
I do this, namely how do I send a
Ron Savage wrote:
V 3.94 has this on line 168:
if ( $arg-isa('CGI') ) {...
which means only a CGI-derived object can be used.
To use CGI::Simple you could - but shouldn't - try:
if ( $arg-isa('CGI') || $arg-isa('CGI::Simple') ) {...
Obviously it's ridiculous to list all possible class
Gabor Szabo wrote:
I might missing something seriously and it is late at night
but is there a module that can be plugged in easily that would
provide authentication in a regular CGI environment ?
[snip]
ps. maybe CGI::Session::Auth is what I am looking for ?
I have been using CGI::Session::Auth
Ron Savage wrote:
Lincoln Stein says he's too busy at the moment (surprise!) and has
asked me to whip up a can() method. I'll do that now.
Cool! Thanks for following up on this Ron.
If you have any suggestions, post them to this list (I'm subscribed).
Here is a first stab at a solution. I
Quoting William McKee [EMAIL PROTECTED]:
On Sun, May 02, 2004 at 06:28:38PM -0400, Linda Jen wrote:
I have been trying to find a way to get the absolute path for the url
returned in HTTP_REFERER. The url may referce an alias, virtual host,
or simply some subdirectory but will not be
Stosberg wrote:
Cees Hek [EMAIL PROTECTED] wrote:
Quoting Brian Cassidy [EMAIL PROTECTED]:
- you have effectively hijacked the prerun and postrun methods which means they
are unavailable to any sub/super classes. This brings me back to my request
from many months ago for the ability to register
Quoting William McKee [EMAIL PROTECTED]:
This forwarding of an event is not necessary developer unfriendly. I
have experience with an environment (formerly known as Asymmetrix
Toolbook) in which event messages had to be explicitly forwarded. You
forget occasionally but the unexpected results
William McKee wrote:
It sounds like what your patch will ultimately provide is a way to
easily add/remove functions into C::App which would make things much
easier for new users as well as for those of us who have our favored
modules and gobs of code to make them easily available in C::App (e.g.,
Quoting John Day [EMAIL PROTECTED]:
At 04:19 PM 6/7/2004, John Day wrote:
I have an application where I want to generate a 'printable invoice' in a
separate window. Preferably I would like the browser page to not have
toolbars and all that, just a simple link at the bottom that has an
Kleindenst, Fred wrote:
Hello,
I'd like to measure the time taken to execute each particular hit to cgi::app and
display the result.
My thoughts on how to implement this are roughly:
* get the time $T1 in cgiprerun - store in $self
* get the time $T2 in cgipostrun and compute the difference
*
, methods of this class will not be found. In other words,
inherited
methods will not be found.
=head1 SEE ALSO
=over
=item *
CGI::Application
=back
=head1 AUTHOR
Packaged up for CGI::Application by Cees Hek,
Elt[EMAIL PROTECTED]gt,
but really written by Jean-Christophe Zeus in Class::DBI::Plugin
Quoting Michael Peters [EMAIL PROTECTED]:
Cees Hek wrote:
I really love the plugin based model that so many other modules
(Template Toolkit, Class::DBI now, etc). It really simplifies
development yet it doesn't the flexibility that we all enjoy. Don't like
the plugin, don't use
Michael Peters wrote:
Just one more comment/question here. Other modules that use a plugin
style architecture usually put them into a ::Plugin namespace (ie,
Template::Plugin::DBI). Should we consider doing that here if we are
serious about hording up a lot of plugins? Should CGI::Application::TT
Mark Stosberg wrote:
It simplifies and standardizes the way a plugin can be built for
CGI::Application, and it works completely outside of the
CGI::Application codebase (ie no patches necesary). It avoids the
annoyances of building a big inheritance tree for the plugins you want
to use by
Bill Catlan wrote:
Cees,
So a plugin author would
use base CGI::Application::Plugin;
in their plugin, and that would be it?
That is the first part, the second part is to mark which methods you
want automatically exported to the class that is 'use'ing the plugin,
and that is done using a
Quoting Bill Catlan [EMAIL PROTECTED]:
Should C::A::Plugin perhaps put the plugin methods
into C::A space, and not the C::A app module? After
all, the plugin is a /C::A/ plugin, not a 'MyApp'
plugin.
Hi Bill,
That is how the C::A::Session module currently does it. But there are some
Thanks for spending some time on this guys. I appreciate the help and
support.
Bill Catlan wrote:
Just to set a reference point, do we all agree that
everything we discussed would benefit from some agreed
upon method of preventing namespace conflicts between
plugins - no matter what space they
BARKER, Paul wrote:
Hi All
I'm back using CGI::Application after what must be a year or more away doing
other stuff so feel free to flame me (gently!) if this is an obvious mistake
but ...
Welcome back
sub img_index
# Show index of images for a particular hostid
{
my $self = shift;
my
Quoting Jason Purdy [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm trying to understand the Session.pm module/plug-in and the
documentation isn't helping me understand (that serves as a reflection
on me, unfortunately -- not the docs ;)).
Hi Jason,
doc patches are
Quoting Tim Howell [EMAIL PROTECTED]:
Do any of you ever create applications that present forms to a user
based on information entered by a different level of user? For example,
in an event registration system I'm writing, a user is required to enter
different information when registering
I agree with what Stephen is suggesting here as it is definately the
right way to go, but please remember to check the license of all of the
modules that you include in your distribution if you go this route. I
think most modules on CPAN are released under the Artistic license (or a
combined GPL
Yung-chung Lin wrote:
I don't think CGI::App's design is good enough. Using run modes is
useful and helps a lot to clearly define functions of a web
application. But what I don't understand why not make return value passing
purely data-oriented. Then, people don't need to mess with code
and data
PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 08, 2004 9:33 PM
Subject: [cgiapp] Re: plugins
On 2004-05-29, Cees Hek [EMAIL PROTECTED] wrote:
The great thing about CGI::Application is that it gives you the freedom
to use whatever modules you want and buildup your own toolbox of code
Quoting Tony Fraser [EMAIL PROTECTED]:
Hi,
I'm developing a reusable subclass of CGI::Application. For this project
I would like to have a new hook added to CGI::Application.
The attached patch includes the changes I have made to my local copy for
development. If anyone has any
and as such, the features and interface are
subject to change. So please check the Changes file when upgrading.
SEE ALSO
CGI::Application, Template, perl(1)
AUTHOR
Cees Hek [EMAIL PROTECTED]
LICENSE
Copyright (C) 2004 Cees Hek [EMAIL PROTECTED]
This library is free software. You
Hi Mark,
Just wondering if anyone thinks the multiple hooks patch that I provided
back in February is still worthwhile. here is the relevant thread:
http://www.jsw4.net/info/list-archives/cgiapp/04-02/msg00034.html
This is something that will be very helpful (if not required) for the
Auth plugin
Tony Fraser wrote:
The names work fine for me. They are the same as Apache 2.0 uses, minus
the leading HOOK_. Apache 1.3 didn't have that ability you had to fiddle
with the AddModule directive order to get modules in the right order, it
was a pain. I admit Apache is written in C and this is Perl,
Mark Stosberg wrote:
I think it's still an interesting an idea, and I'm seen it come up
several times in discussion since then. I'm not opposed to it, I just
feel conservative about moving it directly to CGI::Application proper.
The patch does not alter any of the current functionality in
Quoting William McKee [EMAIL PROTECTED]:
On Fri, Sep 24, 2004 at 02:01:35PM +1000, Cees Hek wrote:
Sounds good to me. The MIDDLE or DONTCARE are really the default, so
they could be eliminated as well. ie specify FIRST or LAST, or leave
blank for the default.
Couldn't MIDDLE
a small app that replicates
the problem and I'll see if I can recreate the problem.
Cheers,
--
Cees Hek
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Cees Hek
Mark Stosberg wrote:
On this list there was just a thread which brought to light how
people access databases through CGI::Application. There were three primary
groups of answers:
1. Custom SQL called directly from the CGI::Application project.
2. Using custom Data Access Objects to abstract
, although you
will have to write a few of the extra bits yourself.
--
Cees Hek
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL
: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Cees Hek
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail
On Mon, 18 Oct 2004 20:18:17 +1300, Dan Horne [EMAIL PROTECTED] wrote:
Cees Hek wrote:
Is it possible that you are using CGI::Simple instead of CGI?
Ah, that's it! I thought CGI::Simple was a drop-in replacement for CGI if I
didn't require the HTML functions (as per
http
or
not, and handle the situation appropriately... That would solve the
issues for people using CGI::Simple. I don't really want to do that,
since I think the proper place to fix it is in CGI::Session, not in
C::A::P::Session, but I guess I can always remove the checks if
CGI::Session gets fixed.
Cheers,
--
Cees
module like CGI::Simple
- Be more intelligent about choosing a default temporary directory
for windows users (suggested by Dan Horne)
- Add a doc note to warn users when they change the name of the
cookie, to also notify CGI::Session-name
--
Cees Hek
CGI.pm module. I think you can just look at $ENV{MOD_PERL}
for whether mod_perl is running, and what version is being used.
This would allow app developers to put the C::A::P::Apache plugin in
all their apps, and use it in a CGI and mod_perl environment without
any code changes.
Cheers,
--
Cees Hek
will get many useful suggestions on how to make it work seemlessly
with mod_perl1 and mod_perl2.
Cheers,
--
Cees Hek
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l
file uploads). I think it just comes
down to documentation. Make sure the developer knows what to expect
when working in the different environments.
Cheers,
--
Cees Hek
-
Web Archive: http://www.mail-archive.com/[EMAIL
we're modifying the constructor code
anyway?
Fair enough. I was sort of trying to follow the programming style
that CGI::Application already uses, but your suggestion would work
equally well.
Cheers,
--
Cees Hek
-
Web Archive
. Use something like Apache::DBI if you want persistent
database connections (since you are closing your DB connections, I
assume you don't want persistent connections anyway).
Cheers,
--
Cees Hek
-
Web Archive: http://www.mail
will always have fresh data on each request. That philosiphy has
worked out well for me.
The other big things to look out for with mod_perl are already solved
for you just by using CGI::Application :)
Cheers,
--
Cees Hek
-
Web
Hi Drew,
I have been hinting at an Authentication plugin for a while now, but
haven't finished it yet. I did a little bit more work on it
yesterday, but I don't have any docs, or any tests written for the
module yet.
I you also have a start on a module, maybe we can colaborate. From
your
On Fri, 29 Oct 2004 11:16:30 -0400, Drew Taylor
[EMAIL PROTECTED] wrote:
On Fri, 29 Oct 2004 16:31:40 +1000, Cees Hek [EMAIL PROTECTED] wrote:
Nice. At $dayjob I have my own version of require_authentication(),
but I haven't (yet) needed group authentication. I've thought of using
Role-based
, then possibly the next callbacks don't
get executed?
Thanks for your input
Cheers,
--
Cees Hek
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
in the session to
identify the computer (even a second cookie with a unique ID that is
stored in the session would do).
Cheers,
--
Cees Hek
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http
little work. It does a few
simple checks to make sure the configuration info makes sense, and
stores the config options away for later use.
So I guess the lazy loading applies to the CGI::Session object, not
necesarily the CGI::Application::Plugin::Session.
--
Cees Hek
so it should work
fine. However CGI::Minimal will not work, since it doesn't have a
cookie method... There are probably other CGI like modules that won't
work either.
Cheers,
--
Cees Hek
-
Web Archive: http://www.mail
soon, but patches are
always welcome.
--
Cees Hek
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED
.
Michael: If you want to use something besides CGI.pm, why don't you
make a wrapper class which is compatible with the former?
I agree that this would probably be the ideal approach.
Cheers,
--
Cees Hek
-
Web Archive: http
is a great app and I have been
using it for years, but unless you really need to dig into the guts of
Apache to build your app, then there are other alternatives.
Cheers,
--
Cees Hek
-
Web Archive: http://www.mail-archive.com/cgiapp
');
Which saves me a few keypresses, and I don't have to bother checking
the docs on how header_type works everytime (I have a short memory ;)
Just a couple of small suggestions that might make life a little bit easier.
Cheers,
--
Cees Hek
more complex) queries.
Cheers,
--
Cees Hek
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
. Michael, If you find any other compatibility issues between
CAP::Session and CAP::Apache while you develop your compatibility
layer, just let me know and we can try and resolve them before your
next release.
Cheers,
--
Cees Hek
1 - 100 of 379 matches
Mail list logo
