Re: [cgiapp] Re: Uploading files with C::A
Mark, Thanks. Actually that was helpful. I just didn't know if there was a C::A::P::Upload in the offering. I did look at C::Uploader, but need to look again. I know that is outside the purview of this list serve, but would be curious to see a working example. Brad On 2005-12-30, Brad Cathey [EMAIL PROTECTED] wrote: Hi all, I've not used C::A to upload files. Anything different or do I just use standard CGI? File uploading is outside the scope of C::A, so there is no standard solution. I wrote CGI::Uploader as one way to solve the problem. CGI::Upload is a lighter weight solution, and directly using the upload() method of CGI.pm (or equivalent) definitely works as well. I tend to use CGI::Uploader as my solution, but since I wrote it, that's not an incredibly helpful endorsement. Mark -- http://mark.stosberg.com/ - 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 commands, e-mail: [EMAIL PROTECTED] - 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 commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Uploading files with C::A
Oops. I did see some samples in the C::U::Cookbook. I guess I'm looking for general file uploads (I don't need the image manipulation that is in all the examples). Am looking to check for size, and trap errors in a friendly way while uploading a file to the hard drive. Thanks, Brad Mark, Thanks. Actually that was helpful. I just didn't know if there was a C::A::P::Upload in the offering. I did look at C::Uploader, but need to look again. I know that is outside the purview of this list serve, but would be curious to see a working example. Brad On 2005-12-30, Brad Cathey [EMAIL PROTECTED] wrote: Hi all, I've not used C::A to upload files. Anything different or do I just use standard CGI? File uploading is outside the scope of C::A, so there is no standard solution. I wrote CGI::Uploader as one way to solve the problem. CGI::Upload is a lighter weight solution, and directly using the upload() method of CGI.pm (or equivalent) definitely works as well. I tend to use CGI::Uploader as my solution, but since I wrote it, that's not an incredibly helpful endorsement. Mark -- http://mark.stosberg.com/ - 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 commands, e-mail: [EMAIL PROTECTED] - 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 commands, e-mail: [EMAIL PROTECTED] - 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 commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Altering EXPIRY times in C::A::P::Session
Hi all, I want to give users the ability to set their own expire times. Problem is that I'm not tapping the database for their choice until after cgiapp_init, the only place I can really: $self-session_config( DEFAULT_EXPIRY = 15); without getting an error and death. I'd like to be able to (re)set the expiration time later. Anyway to do this? (I'm not using cookies, other than the one made by default by C::A::P::Session).) Thanks! Brad - 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 commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Exit strategies from C::A
I'm curious about
handling situations where I have common operations that must be applied
to
all modes upon exiting. Example:
I load a unique .tmpl files and assign values to parameters in run
modes.
But before outputing, I want to assign some values common to all of
.tmpls.
cgiapp_postrun doesn't always work because it runs after each mode, and
I
only want it to run after all modes are finished (forwarding). I tried
it
teardown, but I lose the $common values somewhere before I get there.
Save $common:
$self-param('common',$common);
Get $common in teardown():
my $common = $self-param('common');
I wish there was something like cgiapp_lastrun that would come only
after
the last mode for the instance was run, and before teardown.
It seems like the desire for this arises because although the teardown
is present at the place in flow you want, it's not doing what you want.
I think using param() can solve that.
Mark
I tried this, but to no avail:
my $template;
sub setup {
#do normal setup and run mode1
$self-param('graphic','header.gif');
}
sub teardown {
my $self = shift;
my $graphic = $self-param('graphic'); # -$graphic has a value here!
$template-param(graphic = $graphic); # -but doesn't get passed to
template here
}
sub mode1 {
$template = $self-load_tmpl('users.tmpl');
return $template-output;
}
Do I have it right?
Brad
-
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 commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Transferring control to another application
Bill, yes I have. But that really doesn't answer my question. I could be any module that I am trying to transfer control to. Brad On Dec 19, 2005, at 9:21 PM, [EMAIL PROTECTED] wrote: Typical scenario: The user is initially directed to Login.pm. After successfully logging in, a home screen is output. From there they can fire user.cgi and User.pm. Of course, I want to check their log-in status at the start of the User app, so I check the session. If they timed out, I want to direct them back to Login.pm. How do I do that and keep some object in tact? Have you looked at: CGI::Application::Plugin::Authentication; It will help maintain state between timeouts. Kindest Regards, -- Bill - 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 commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Transferring control to another application
Influenced by a long thread that I started over the weekend about the
number of run modes allowed in an application, I've been breaking my one
large app into several. I have a question about turning control back to
another module.
Typical scenario: The user is initially directed to Login.pm. After
successfully logging in, a home screen is output. From there they can fire
user.cgi and User.pm. Of course, I want to check their log-in status at
the start of the User app, so I check the session. If they timed out, I
want to direct them back to Login.pm.
How do I do that and keep some object in tact?
$self-prerun_mode('sl');#show log-in screen
OR
show_login($self);
OR
$self-header_type('redirect');
$self-header_props(-url=index.cgi?rm=sl);
Thanks, Brad
BTW: Here's the whole deal (sorry for the length):
index.cgi ***
#!/usr/local/bin/perl
use lib cgi-bin/cgiwrap/dsoft/;
use strict;
use Login;
my $log = Login-new();
$log-run();
* Login.pm ***
package Login;
sub setup
{
my $self = shift;
$self-start_mode('sh');
$self-mode_param('rm');
$self-run_modes(
'sh' = 'show_home',
'sl' = 'show_login', #show login screen
'li' = 'log_in',
'lo' = 'log_out',
);
}
sub show_login
{
my $self = shift;
#...
}
user.cgi ***
#!/usr/local/bin/perl
use lib cgi-bin/cgiwrap/dsoft/;
use strict;
use User;
my $user = User-new();
$user-run();
* User.pm
package User;
use Login;
sub cgiapp_prerun
{
my $self = shift;
if ($self-session-param('logged_in'))
{
#do stuff
}
else
{
$self-prerun_mode('sl'); #show log-in screen
OR
show_login($self);
OR
$self-header_type('redirect');
$self-header_props(-url=index.cgi?rm=sl);
-
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 commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Number of rm's best practice (more)
I'm liking this thread. But I have some elementary questions:
package My::MainApp;
use base qw/My::BaseApp/; # I already have this one; it handles sessions
etc
use My::MainApp::Admin; # contains the run modes dealing with admin
functions
use My::MainApp::News; # another example package of run modes
# rest of app follows
# this app still has some runmodes of its own, but most have been moved
# into the packages use()d above.
1;
1) The above is *not* your base program, right? So what is it doing? I
understand base has all the cgiapp_ stuff and your setup. And I
understand that ::Admin and ::News are doing specific functions, but this
inbetween module is unclear.
2) Also, in your sub import {} are you only importing the run modes for
that module (I assume)? My real question is, then, do ALL the runmodes
still get listed in the base module?
3) How are these files named when they are saved to the server? Just
Admin.pm?
Thanks!
package My::MainApp::Admin;
use CGI::Application; # to get the callback functionality
use base qw/Exporter/;
sub import
{
caller()-add_callback( 'prerun' = sub {
my $self = shift;
$self-run_modes([qw/
save_user
delete_user
/]);
} );
goto Exporter::import;
}
sub save_user {} # these used to be a run mode in MainApp
sub delete_user {} # but are now in their own package
1;
Hope that helps a bit :)
Rhesa
-
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 commands, e-mail: [EMAIL PROTECTED]
-
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 commands, e-mail: [EMAIL PROTECTED]
[cgiapp] location of instance and application files
Where's the best the place for instance and application files? I thought, originally, that instance scripts would go in my web directory, as in index.cgi, so it would fire automatically. But maybe, if I go with the multi-instance scenario that Jesse just suggested, they should go in my /cgi-bin. And then the applications themselves would logically go in /cgi-bin as well. So, if I have an instance script of 'users.cgi' and my applications are My::User and ::Save I would maybe set it up like: http://www.domain.com/cgi-bin/users.cgi http://www.domain.com/cgi-bin/My/User.pm http://www.domain.com/cgi-bin/My/User/Save.pm Does this work? What was throwing me off is the CPAN modules that are off my root directory. Thanks, Brad - 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 commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] C::A::P::Session not 'remembering' session
Cees:
That is odd, as it usually works out of the box without requiring any
configuration.
You're absolutely right. I was just trying too hard. After commenting out
session_config and having it work, I successfully added back in:
$self-session_config( DEFAULT_EXPIRY = '+15m');
As I am finding with all of C::A stuff (this being my first week using
C::A and the plug-ins) is that it's almost *too* easy. I was telling a
fellow coder, who has yet to make the switch, that I'm incredulous
everytime I use a new plug-in (once I get them installed).
Anyway, hats off to all those who have contributed to the C::A way, the
Perlmonks that pushed me in the first place (guilt), and for this
list-serve that has made the jump so much easier for me.
Brad
On 12/16/05, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Seems like I have spent more time on C::A::P::Session than all the other
plugins combined--and I just can't get it to work.
That is odd, as it usually works out of the box without requiring any
configuration.
It is setting a session
in cgiapp_postrun after logging in for the first time (it is also
setting
a cookie very nicely). This is evidenced by the line: 'logged_in: 1 in
my
debug2.txt file and the visual setting of the cookie.
However, when I come return from the next HTML page to execute another
runmode, the session is coming up empty. This is evidenced by the line:
'logged_in: ' in my debug1.txt file.
In good olde CGI::Session, I have to use the session id to retrieve the
session:
my $session_id = cookie('CGISESSID');
my $session = new CGI::Session(driver:File, $session_id,
{Directory='/tmp'});
Actually, you don't have to do that with CGI::Session, you can just
give it a CGI.pm object and it will figure out the session_id from
that. That is the technique that CAP::Session uses.
I see that an id is created in the cookie by C::A::P::S, but how is it
use
to retrieve the session, if at all? Here's my bare bones code:
sub cgiapp_init {
my $self = shift;
$self-session_config(
CGI_SESSION_OPTIONS = [ driver:File, $self-query,
{Directory='/tmp'} ],
DEFAULT_EXPIRY = '+15m',
COOKIE_PARAMS = { -name= 'designsoft',
-path= '/'},
SEND_COOKIE = 1);
What you are doing here is telling CAP::Session to use a different
name for the cookie. The docs for CAP::Session warn you about doing
that. My recommendation would be to comment out your entire
'session_config' line and let CAP::Session use its defaults. That
should work for everyone. Then you can start adding customizations in
and test as you make changes. That way you will figure out where
things are going wrong.
Cheers,
Cees
-
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 commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: C::A::P::Session not 'remembering' session
Mark, I recommended using postrun for this, becaues it runs after every run mode in the module, but is only needed one once: After you have logged in. I would find it more efficient and logicial to then call set_session() at the end of the login processing run mode. Thanks, I didn't realize that it ran after every run mode. I'll put it up in cgiapp_init. postrun tends to be rarely used my experience. The one related thing I have done is to call $self-session-flush() in the teardown() phase. I think that should happen automatically. Are you saying flush happens automatically and not to use it? One more question. flush comes from C::S. Am I reading that I can use methods from the parent modules in the C::A::Plugins? Thanks, Brad Mark -- http://mark.stosberg.com/ - 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 commands, e-mail: [EMAIL PROTECTED] - 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 commands, e-mail: [EMAIL PROTECTED]
[cgiapp] C::A::P::Session not 'remembering' session
Seems like I have spent more time on C::A::P::Session than all the other
plugins combined--and I just can't get it to work. It is setting a session
in cgiapp_postrun after logging in for the first time (it is also setting
a cookie very nicely). This is evidenced by the line: 'logged_in: 1 in my
debug2.txt file and the visual setting of the cookie.
However, when I come return from the next HTML page to execute another
runmode, the session is coming up empty. This is evidenced by the line:
'logged_in: ' in my debug1.txt file.
In good olde CGI::Session, I have to use the session id to retrieve the
session:
my $session_id = cookie('CGISESSID');
my $session = new CGI::Session(driver:File, $session_id,
{Directory='/tmp'});
I see that an id is created in the cookie by C::A::P::S, but how is it use
to retrieve the session, if at all? Here's my bare bones code:
sub cgiapp_init {
my $self = shift;
$self-session_config(
CGI_SESSION_OPTIONS = [ driver:File, $self-query,
{Directory='/tmp'} ],
DEFAULT_EXPIRY = '+15m',
COOKIE_PARAMS = { -name= 'designsoft',
-path= '/'},
SEND_COOKIE = 1);
open (DEBUG, debug1.txt) or die debug error: $!;
print DEBUG logged_in:. $self-session-param('logged_in').\n; close
DEBUG;
}
sub cgiapp_prerun {
if ($self-session-param('logged_in')) {# if logged in then grab
the rest of the session
$user_name = $self-session-param('user_name');
$user_id = $self-session-param('user_id');
} elsif ($query-param('rm') eq li) { #If attempted to log in
$self-prerun_mode('li');# run log-in mode
} else { #If not logged in
$self-prerun_mode('sl');# then show form
}
}
sub cgiapp_postrun {
my $self = shift;
$self-set_session(); #set the session
}
sub set_session {
my $self = shift;
$self-session-param(user_name = $user_name);
$self-session-param(user_id = $user_id);
$self-session-param(logged_in = 1); #persistent
open (DEBUG, debug2.txt) or die debug error: $!;
print DEBUG logged_in:. $self-session-param('logged_in').\n; close
DEBUG;
}
-
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 commands, e-mail: [EMAIL PROTECTED]
[cgiapp] C::A::P::Session
Just started working with CGI::Application::Plugin::Session and am confused about a few things: 1) I'm used to CGI::Session, where I have to assign a cookie name and the deal with a session id generated by C::S and written into the cookie. How is the session id and cookie name handled in C::A::P::S? Here's what I'm doing (pretty typical): - when script is started I use the prerun to check to see if 'logged-in' is still TRUE. If not, I show the login screen. Otherwise I grab the session values for use in the script. Is C::A::P::S going to work? 2) why do coders preface 'logged-in' with a tilde, e.g., '~logged-in'? What's wrong with 'logged-in'? Thanks, Brad - 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 commands, e-mail: [EMAIL PROTECTED]
[cgiapp] running modes in sequence
Hi all.
New to CGI::App and am wondering how to do the following in C::A that I
was doing with a switch statement previously.
The old:
SWITCH: for ($query-param('funct')) {
/save project/ido { saveproject(); editproject(); last; };
}
The above runs sub called 'saveproject' and then when completed runs
'editproject'. How do I run two runmodes in one trip to my application
with C::A?
The new:
sub setup {
$self-start_mode('menu');
$self-mode_param('rm');
$self-run_modes(
'menu' = 'adminmenu',
'save' = 'saveproject',
???
}
Is there anyway to send a hash, something like:
sub setup {
$self-start_mode('menu');
$self-mode_param('rm');
$self-run_modes(
'menu' = 'adminmenu',
'save' = { 'step1' = 'saveproject',
'step2' = 'editproject'}
}
Of course, I could call 'editproject' from 'saveproject', but that defeats
the modularity of the script.
Thanks, Brad
-
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 commands, e-mail: [EMAIL PROTECTED]
