Re: [cgiapp] Proposed new look and branding for cgi-app.org
Lyle Hopkins has generously worked with me to prepare this proposed redesign for cgi-app.org. I'm interested in your feedback before moving forward: http://cosmicsitedesign.com/cgi-app/ I think it looks great! Good job Lyle and thanks. The update addresses long standing complaints about the genericness of the name CGI::Application or that the project name includes CGI at all. The words CGI::Application also just hard to create a brand and marketing materials around. So the update emphasises the Titanium name and branding, although all the content will generally continue to refer to CGI::Application and related plugins as it does now. I realize Titanium is just one possible direction to go with CGI::Application, but overall I think it's a better name to brand and market around than CGI::Application. I would agree that CGI::App is a bit generic and often confusing. I'm not sure I care for the name of Titanium. How about 'Mantle'? http://en.wikipedia.org/wiki/Pearl, http://en.wikipedia.org/wiki/Mantle_(geology) A couple of positive meanings, easy to say and type, short and not used much beyond geology. Take Care, Lee # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] changing app modes during cgiapp_prerun
Hello Amelia,
Since you are still in that run mode, you can't logically change it until the
prerun finishes. The prerun_mode only changes the mode after the all the
preruns get called so without mucking around with the internal data structure
(which is a bad idea) it won't change. ( this also makes sure plugins have a
more predictable state)
I guess I could see trying to save a bit of processing by validating data then
changing the run mode and running more validation instead of doing a redirect.
I think logically this get complex and difficult to debug very quickly.
As an idea, you could have the code check the value in the prerun_mode.
Something like:
sub cgiapp_prerun {
my $self = shift;
if ( ! $self-valid_for_rm ) {
$self-prerun_mode('mode2');
}
if ( ! $self-validate_more ) {
$self-prerun_mode('mode3');
}
}
sub validate_more {
my $self = shift;
my $rm = $self-prerun_mode || $self-get_current_mode;
## do validation based upon rm
}
Without knowing more of what your trying to do I'm not sure I would recommend
this. In general i think its preferrable to issue a redirect and let the next
request do the next series of processing. Or use a dispatch table or code ref
for run mode parameter lookup to change pages if that is what your trying to
do. I think this would be less confusing down the road, IMHO.
Hope this helps,
Lee
- Original Message
From: Amelia Ireland [EMAIL PROTECTED]
To: CGI Application cgiapp@lists.erlbaum.net
Sent: Tuesday, July 22, 2008 2:45:16 PM
Subject: [cgiapp] changing app modes during cgiapp_prerun
Hi,
I was wondering if there is a way to immediately change the run mode
during cgiapp_prerun. If I change it using prerun_mode, the run mode
(as reported by get_current_runmode) doesn't actually change until
cgiapp_prerun is finished. This is causing me a problem with some data
validation that I am doing.
Thanks,
Amelia.
--
Amelia Ireland
GO Editorial Office
http://www.ebi.ac.uk || http://www.berkeleybop.org
BBOP Plant Project: http://bbopgarden.blogspot.com
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Q: Authz, but only when user is Authenticated...
Hello Graham,
I just ran into this same problem last week. I was just crafting an email about
it but found it hard to explain. You did a great job :)
So, I load up CAP::Authen and CAP::Authz in my App superclass and the prerun
hooks get invoked in order (authen first, then authz). However... if they
both fail (user isn't logged in, so I obviously fail authz), CAP::Authz
calls prerun_mode() last and overrides the rm that was set by CAP::Authen
to trigger the login screen.
This is a problem with any prerun callbacks. The last one run will be the one
that sets the 'prerun_mode'.
I did find that one plugin (Dispatch I think) that was being aware and checking
to make sure that prerun_mode wasn't set yet. I'm not sure this is a great
choice since it assumes that plugin authors will be aware of this and code
around it. It just seems wrong to me...
I've got a few possible ideas for working around this, but wanted to find out
what others are doing...
1) Load CAP::Authz first. That way, even if Authz fails, CAP::Authen would
be
the last one to call prerun_mode() and the user would get shown the login
page. This works, but feels counter-intuitive; I'm always thinking that I
want Authen to run first so I load that plugin first.
I didn't like this one either.
2) Add a new REQUIRES_AUTHEN option to CAP::Authz, so that if its unable to
even figure out what the username is then it doesn't even bother doing an
Authz check.
I like this.
What are you guys doing when you want similar behaviour?
I needed a really quick solution, so I added the following to my code until a
better long term solution could be determined:
(prerun_mode could have been $self-auth-username too)
package My::WebApp;
## ..snip...
my @protected_modes = qw( page1 page2 );
sub cgiapp_prerun {
my $self = shift;
if ( !$self-prerun_mode ) {
## validate user authz stuff
$self-authz-authz_runmodes( map { $_ = 'pxdesk' }
@protected_runmodes );
## this is a bit strange but has to due with calling stuff
## I would expect: $self-authz-prerun_callback too...
$self-CGI::Application::Plugin::Authorization::prerun_callback();
}
}
In my case, I need to have some other prerun code still run so I just excluded
the authz code.
Overall, I think CA should handle this a bit better, but I'm not sure how since
that call_hook code is really well separated and has a clean design. It seems
wrong to 'mess' it up for this one case.
Maybe it would be good to have the callback throw an exception that would tell
CA to stop processing other callbacks? But I could envision situations where
the app may want other callbacks to still be called anyway like mine above :)
Today the callback code will just die if it sees an exception. Maybe
'prerun_mode' could only be set once inside the prerun callbacks, first one to
set it gets it.
Other ideas?
Take Care,
Lee
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] CGI::Application::Dispatch Install Issues
Hello Todd, I had the same issues, see bug: http://rt.cpan.org/Public/Bug/Display.html?id=33498 I found that I needed to patch a Build.PL and Makefile.PL when Apache::Test wasn't installed. There are patches attached to the bug, give them a try. I'm pretty confident they will work (that probably means something is mucked up with them :) Good Luck, Lee - Original Message From: Todd Ross [EMAIL PROTECTED] To: CGI Application cgiapp@lists.erlbaum.net Sent: Friday, March 7, 2008 9:34:00 AM Subject: [cgiapp] CGI::Application::Dispatch Install Issues I've seen quite a few posts on this list concerning CGI::Application::Dispatch. I'd like to try it out. Installing it, however, seems to be a problem. Since there is no README or INSTALL included in the archive, I'm following the normal Makefile.PL (or Build.PL) procedures. [EMAIL PROTECTED]:~/perltemp/CGI-Application-Dispatch-2.12] ls Build.PL Changes lib Makefile.PL MANIFEST META.yml tTODO [EMAIL PROTECTED]:~/perltemp/CGI-Application-Dispatch-2.12] perl Makefile.PL This module can optionally use Apache::Test to test the mod_perl functionality. Undefined subroutine ExtUtils::MakeMaker::prompt called at Makefile.PL line 31, DATA line 547. [EMAIL PROTECTED]:~/perltemp/CGI-Application-Dispatch-2.12] perl Build.PL Can't locate object method new via package Module::Build (perhaps you forgot to load Module::Build?) at Build.PL line 2. Is there a known problem with CGI::Application::Dispatch? How have others installed this? Since its complaining about not finding a MakeMaker sub, the version of MakeMaker I'm using is probably relevant: [EMAIL PROTECTED]:~/perltemp/CGI-Application-Dispatch-2.12] perl -MExtUtils::MakeMaker -e 'print $ExtUtils::MakeMaker::VERSION\n' 6.30 The Perl version is also probably relevant: [EMAIL PROTECTED]:~/perltemp/CGI-Application-Dispatch-2.12] perl -v This is perl, v5.8.8 built for sun4-solaris snip I've installed 100s of CPAN modules using these procedures with this build of Perl, so I'm comfortable with my environment. Todd # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CGI::Application::Dispatch Install Issues
Hello Michael,
[EMAIL PROTECTED]:~/perltemp/CGI-Application-Dispatch-2.12] perl
Makefile.PL
This module can optionally use Apache::Test to test the mod_perl
functionality.
Undefined subroutine ExtUtils::MakeMaker::prompt called at
Makefile.PL
line 31, DATA line 547.
I'm curious about this one. I'm not sure which version of
ExtUtils::MakeMaker
added prompt (it's in at least 6.31, but I don't know about
6.30). It works just
fine for me.
This isn't a problem with ExtUtils::MakeMaker not having prompt in some old
version, it is an issue with trying to use the 'prompt' sub before requiring
the library. The require of it occurs only if you install module::build above,
if you have it installed it makemaker won't get loaded.
snippet
# see if they have Apache::Test, if not, ask if they want it
my $build_pkg = 'Module::Build'; unless(eval use Apache::Test 1.30; 1) {
print This module can optionally use Apache::Test to test the mod_perl
functionality.\n;
my $yn = ExtUtils::MakeMaker::prompt(' Install Apache::Test now from
CPAN?', 'y');
/snippet
I am trying to be smarter than the average Makefile.PL, but I
just seem to be
getting more trouble then it's work at this point. I'll probably
just go back to
being dumb and not run the Apache/mod_perl tests unless the person
already have
Apache::Test installed.
I think its nice to try this. These problems aren't anything major.
[EMAIL PROTECTED]:~/perltemp/CGI-Application-Dispatch-2.12] perl
Build.PL
Can't locate object method new via package Module::Build
(perhaps you
forgot to load Module::Build?) at Build.PL line 2.
You need to install Module::Build using CPAN.
I had Module::Build installed, the problem was w/out apache::testmb it didn't
try to require or use it.
Here is the snippet from the Build.PL:
my $build_pkg = eval require Apache::TestMB ? 'Apache::TestMB' :
'Module::Build';
my $build = $build_pkg-new( ...
If you notice Module::Build is never loaded.
Is there a known problem with CGI::Application::Dispatch? How have
others
installed this?
I had these same issues but once I patched the Makefile.PL and Build.PL it
worked just fine.
These are really small things and nothing to get angry about. Thanks for your
work on C:A:Dispatch, it is a great tool.
Take Care,
Lee
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
[cgiapp] Session name, CGI::Session and CAP::Session
Hello Everyone,
I am having a bit of an issue with how the 'name' attribute is being set on
CGI::Session (CGI::Session-name). It is necessary to set the class value for
'name' before creating a session after which it is possible and useful to set
it on the instance.
I have a base class that I use for multiple CGI::App sub classes, this setups
the main support for CAP::Session. Since we have lots of different cgi based
apps that do very different things and that shouldn't really share session
data, I need a way to alter this name. The main problem is that some of these
apps are mod-perl based, which is where the class value causes issues ( or has
the potential for issues). I know that I could use the 'path' value but there
are cases where two subclasses could use the same session but be at different
paths... ( I know, I'm being a pain in the butt :)
I have found a solution but I'm not sure its the best one. In the base class, I
allow each class to set the name differently for each app as a parameter. The
main problem I run into is to prevent issues with it storing that for all other
sub classes, I need to do something like:
... in some code that is called as a init callback
## fetch current global name
my $old = CGI::Session-name;
## change it temporarily until new session has been created
CGI::Session-name( $self-session_name );
$self-session-name( $self-session_name );
## restore global one
CGI::Session-name( $old);
This is pretty ugly but I couldn't figure out a way around it. This give me a
brief amount of time where the package value is set and I hope that it doesn't
get used (or reset) by another app. Most of the apps are used by just a few (or
single) users so this isn't a huge problem. But it just doesn't feel right.
From looking at the CGI::Session code, I don't there is another way to do
this. Any ideas?
One solution that I had was a new hash ref of parameters could be passed to
'new' and 'load' (of CGI::Session). Something like:
CGI::Session-new( 'driver:File', $self-query, { Directory =
File::Spec-tmpdir}, { name = 'SpecialName', update_atime = 1, } );
I am very willing to create a patch and tests for this new constructor option,
if it makes sense to everyone.
Also, I have noticed that CAP::Session uses CGI::Session-name is a few places
where the instance may have changed the parameter and will require a patch to
fix these issues. I am willing to produce a patch and test for these issues as
well.
Thanks,
Lee
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Session name, CGI::Session and CAP::Session
Hello Todd,
Good to hear from you.
I think I might not have been clear. I do want the sessions to be manage per
user but I want to alter the session name in the cookie/url based upon the
application subclass.
e.g.
App::Base has subclasses:
App::A - has session name of 'A'
App::B - has session name of 'B'
App::C and App::D - share some settings/values between them and share
session name of 'CD'.
Thanks for pointing out the Stash module, I didn't know there was one for CGI
app and that is very useful for lots of things.
Take Care,
Lee
- Original Message
From: Todd Wade [EMAIL PROTECTED]
To: CGI Application cgiapp@lists.erlbaum.net
Sent: Friday, February 15, 2008 3:56:06 PM
Subject: Re: [cgiapp] Session name, CGI::Session and CAP::Session
Hi Lee,
Unless I'm misunderstanding I would dispense with CAP::Session and store
different CGI::Session instances in CAP::Stash:
http://search.cpan.org/~kazeburo/CGI-Application-Plugin-Stash/lib/CGI/Application/Plugin/Stash.pm
use CGI::Application::Plugin::Stash;
...
$self-stash-{sessions}{'My::Subclass1'} = CGI::Session-new(...);
$self-stash-{sessions}{'My::Subclass2'} = CGI::Session-new(...);
Then maybe make my own -session method that finds the correct session for the
subclass:
sub session {
my $self = shift;
return $self-stash-{sessions}{ ref $self };
}
?
Todd W.
- Original Message
From: Lee Carmichael [EMAIL PROTECTED]
To: cgiapp@lists.erlbaum.net
Sent: Friday, February 15, 2008 3:00:46 PM
Subject: [cgiapp] Session name, CGI::Session and CAP::Session
Hello Everyone,
I am having a bit of an issue with how the 'name' attribute is being set on
CGI::Session (CGI::Session-name). It is necessary to set the class value for
'name' before creating a session after which it is possible and useful to set
it on the instance.
I have a base class that I use for multiple CGI::App sub classes, this setups
the main support for CAP::Session. Since we have lots of different cgi based
apps that do very different things and that shouldn't really share session
data, I need a way to alter this name. The main problem is that some of these
apps are mod-perl based, which is where the class value causes issues ( or has
the potential for issues). I know that I could use the 'path' value but there
are cases where two subclasses could use the same session but be at different
paths... ( I know, I'm being a pain in the butt :)
I have found a solution but I'm not sure its the best one. In the base class, I
allow each class to set the name differently for each app as a parameter. The
main problem I run into is to prevent issues with it storing that for all other
sub classes, I need to do something like:
... in some code that is called as a init callback
## fetch current global name
my $old = CGI::Session-name;
## change it temporarily until new session has been created
CGI::Session-name( $self-session_name );
$self-session-name( $self-session_name );
## restore global one
CGI::Session-name( $old);
This is pretty ugly but I couldn't figure out a way around it. This give me a
brief amount of time where the package value is set and I hope that it doesn't
get used (or reset) by another app. Most of the apps are used by just a few (or
single) users so this isn't a huge problem. But it just doesn't feel right.
From looking at the CGI::Session code, I don't there is another way to do
this. Any ideas?
One solution that I had was a new hash ref of parameters could be passed to
'new' and 'load' (of CGI::Session). Something like:
CGI::Session-new( 'driver:File', $self-query, { Directory =
File::Spec-tmpdir}, { name = 'SpecialName', update_atime = 1, } );
I am very willing to create a patch and tests for this new constructor option,
if it makes sense to everyone.
Also, I have noticed that CAP::Session uses CGI::Session-name is a few places
where the instance may have changed the parameter and will require a patch to
fix these issues. I am willing to produce a patch and test for these issues as
well.
Thanks,
Lee
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/##
####
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp
Re: [cgiapp] prerun and errormode handling
Hello James,
just curious. why are you using the Dev version of CGI-Application-4.07_01?
it doesn't seem to
have any advantages to me.
Sorry for the confusion but we aren't using the development release. We
are using 4.06. I didn't want to go through the work of writing a patch
for 4.06 if there weren't any plans for another release or writing a
patch for 4.06 and forcing someone else to port the change forward.
I guess I was asking more about the release plans for cgiapp 4.07 vs 4.06 but
not in a very clear way. :)
regarding trapping errors, usually the failures from cgiapp_prerun/setup are
unexpected system
errors. I let apache handle that (use ErrorDocument)
As for 'setup' errors, I agree that they would be better handled by something
else. But I have some items that seem to make sense to validate inside of
cgiapp_prerun method. My understanding with ErrorDocument is that it doesn't
pass any real message to your page. (for example: if database connection is
down call dba's vs. filesystem is missing call sysadmins, it just calls a page
for 500's or such.).
Thinking a bit more about it, I guess I could do something like:
sub cgiapp_prerun {
my $self = shift;
eval { $self-validate_env(); };
my $err = $@;
if ( $err) {
$self-param('error_msg', $err );
$self-prerun_mode( 'error' );
}
}
but this seems a bit wrong.
Take Care,
Lee
-
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]
