For those of you using path_info parsing to get at run_modes, how do
YOU deal with the dynamic run_mode changes? It is easy enough to
return $self-other_run_mode, but in the setting of using path_info,
that seems contradictory and may even defeat the apache-based
authorization concept (if
Sean Davis wrote:
For those of you using path_info parsing to get at run_modes, how do YOU
deal with the dynamic run_mode changes? It is easy enough to return
$self-other_run_mode, but in the setting of using path_info, that seems
contradictory and may even defeat the apache-based
Sean Davis wrote:
On Jan 7, 2005, at 9:17 AM, Michael Peters wrote:
Sean Davis wrote:
For those of you using path_info parsing to get at run_modes, how do
YOU deal with the dynamic run_mode changes? It is easy enough to
return $self-other_run_mode, but in the setting of using path_info,
that
On Fri, 7 Jan 2005, Mark Stosberg wrote:
Is this module incompatible with C::A::P::DBH?
Probably not. (as the author of that module). Go ahead and take a lot at
the source of ::DBI. It's very simple.
It could be worth taking ::DBH out of the picture, just to help narrow
down where your
On Thu, 6 Jan 2005, Michael Peters wrote:
Hope that gives you even more ideas.
Thanks to you and William for your responses. Looking back at my initial
message, I think I was unclear as to exactly what I'm asking. I want to
know if there are are better ways to do the authenticate in the
On Fri, Jan 07, 2005 at 09:55:03AM -0500, Jaldhar H. Vyas wrote:
Thanks to you and William for your responses. Looking back at my initial
message, I think I was unclear as to exactly what I'm asking. I want to
know if there are are better ways to do the authenticate in the script
itself
I am using CGI::App in a mod_perl environment. I typically have
run_modes submit back to themselves for validation, etc. If the form
information passes, I return $self-next_run_mode (just an example).
I have made a couple of changes to my previous coding style. First, I
am using path_info
On Jan 7, 2005, at 12:59 PM, Michael Graham wrote:
I am using CGI::App in a mod_perl environment. I typically have
run_modes submit back to themselves for validation, etc. If the form
information passes, I return $self-next_run_mode (just an example).
I have made a couple of changes to my
For an example, I wrote a quick database for gene expression profiles.
We have a quirky access for it (you apply to via email submission
rather than automatic), but it is available. As you can see from the
URL, it is not mod_perl based and has somewhat limited functionality
compared to what
Hope everyone on the list had a happy holidays great new year ..
I recently got some requirements for a new project that involved a shopping
cart application. Aside from building the standard shopping cart portion of
the site (all C::A driven .cgi files), the site needed other regular .html
Steve Comrie wrote:
Hope everyone on the list had a happy holidays great new year ..
I recently got some requirements for a new project that involved a shopping
cart application. Aside from building the standard shopping cart portion of
the site (all C::A driven .cgi files), the site needed other
I might be missing something, but seems to me like you're just
reinventing SSI. Have you looked at mod_include ? It would be much
faster than having to bring php into the mix.
I guess in a way I have reinvented SSI, I didn't really think of that as I
was writing the code because I haven't
All,
In my next project I'll be making a lightweight document management system. The
specs are fairly simple:
* use existing infrastructure: Oracle DB, perl on vanilla cgi webserver and
existing authentication system
* Provide upload, storage and access to .PDF, .xls, .doc etc.
* Support Meta
Fred,
If you'e an Oracle shop, what aboout Oracle iFS? You can use a web or
explorer/smb interface (or anything else like FTP), and your documents can
be automatically indexed when they're uploaded. Plus, it's got versioning,
check-out and check-in. Alas, it's not Perl based, but it may do what
14 matches
Mail list logo
