Re: [cgiapp] Re: Perl Certified Hosting
Mark Stosberg wrote: Some projects offer both XS and Pure Perl alternatives, but I'm not aware that we have a standard to automate choosing one or the other, so you can easily get a whole Pure Perl dependency chain. I've always tried to stick to pure perl modules, but I think the problem is that for some operations, such as graphics manipulation, pure perl code would be far to slow... Lyle # 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] New Internationalization module
Hi All, I've finally got my head around internationalization (I18N) and written a plugin for CGI::Application. I've just uploaded v0.02 to CPAN, so it should show up in the next few hours. Details on usage at:- http://search.cpan.org/~cosmicnet/CGI-Application-Plugin-I18N/lib/CGI/Application/Plugin/I18N.pm Guide to I18N and making you language packs (lexicons):- http://search.cpan.org/~cosmicnet/CGI-Application-Plugin-I18N/lib/CGI/Application/Plugin/I18N/Guide.pod Feedback very much appreciated. Using this module and following all the resources in the guide, you should be able to get yourself fully up to speed with internationalization in less than a day (it's taken me weeks to sort through it all :-[ ). Let your CGI::Applications be in any language your users want :) Lyle # 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] Safe way to remember user login?
Hi All, I know a lot of sites have a check box for remember me or what not. But I'm trying to figure out a safe way to do this. Saving the username and password in cookies wouldn't be secure, so I guess some kind of cookie ID. But then once you display the login form you'd be writing out the password into the input type=password value=, which isn't secure either as someone could view source and grab it. I'm guessing this kind of thing has come up for a lot of people on this list, care to share a solution? Lyle # 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] Safe way to remember user login?
Mark Fuller wrote: On Tue, Jan 13, 2009 at 5:41 PM, Lyle webmas...@cosmicperl.com wrote: People wrote: (various comments) I think you're right, I shouldn't worry and just let the browser handle it. I might make it remember the username by default for convenience if they choose to enter their password each time. I don't understand the remember me thing. If you use a cookie with a session key, and maintain on the server side that the user wants to be remembered, why even display the login page to them? Just treat them as already logged in, and let them into your site? That's what's going to happen anyway if you fill in the userID and password for them. It seems to me like what's really happening here is someone wanting to not be logged off for 2 weeks. Making them go through the login page with their credentials supplied for them, that's just making it harder to remain logged in for 2 weeks. (?) Maybe I don't get it. Doh! That makes sense :) Like ebays remember more for a day. I could have a remember me check box, when checked have javascript add a drop down box where they can select day, week, month, etc. Then just leave it in the session. Runs the risk of the session ID being found, but I guess if I verify the cookie and IP address... Lyle # 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] Windows Environment Setup
Mike Tonks wrote: Hi All, I was recently asked how to setup a dev environment on Windows for CGI::Application, and couldn't answer, other than to install ubuntu as a dual boot and use that. Can anyone suggest ways to do this? You've got a few options. Depends on what windows they have and what they already have setup really. IIS-ActivePerl Apache-ActivePerl I can't say I've used strawberry Perl yet, so can't comment on that option. ppm install CGI::Application Komodo Edit is pretty good, they also offer a trial for the full Komodo http://www.activestate.com Lyle # 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] Windows Environment Setup
fREW Schmidt wrote:
On Fri, Jan 16, 2009 at 10:29 AM, Lyle webmas...@cosmicperl.com wrote:
Mike Tonks wrote:
Hi All,
I was recently asked how to setup a dev environment on Windows for
CGI::Application, and couldn't answer, other than to install ubuntu as
a dual boot and use that.
Can anyone suggest ways to do this?
You've got a few options. Depends on what windows they have and what they
already have setup really.
IIS-ActivePerl
Apache-ActivePerl
I can't say I've used strawberry Perl yet, so can't comment on that option.
ppm install CGI::Application
Komodo Edit is pretty good, they also offer a trial for the full Komodo
http://www.activestate.com
Also: I would recommend adding the recommended sources to ppm. Run
the ppm ui and click Edit-Preferences, go to the repositories tab,
and then add all of the suggested from the list. That will give you
options for plugins and whatnot that you wouldn't have otherwise.
Good point I missed that. Also if you are using IIS you'll want to start
your scripts like:-
#!/Perl/bin/perl.exe
BEGIN {
use FindBin qw ($RealBin $RealScript);
use lib $FindBin::RealBin;
chdir $RealBin;
if ( $ENV{'SERVER_SOFTWARE'} =~ /IIS/ ) {
open STDERR, ' iisError.log' || die Can't write to
$RealBin/issError.log: $!\n;
binmode STDERR;
#close STDERR;
}#if
}#BEGIN
Unlike Linux/Apache, Windows/IIS doesn't execute your Perl scripts with
the pwd set to where your script actually is. This can play havoc with
Linux code that uses relative paths for files, directories, require,
use, etc. This bit of code fixes it.
Also IIS has a habit of sending anything sent to STDERR to STDOUT
instead. This can cause some weird problems, so either close STDERR or
set it to your own log file instead (as above).
Hope that helps
Lyle
# 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] Getting error_mode to catch die in cgiapp_prerun
Hi All,
I've noticed that if my app dies in cgiapp_prerun then my error mode
defined in setup isn't called.
Is there a reason for this? Is there a way to get error_mode to catch
errors in cgiapp_prerun?
Sample module:-
package Test;
BEGIN {
use FindBin qw ($RealBin $RealScript);
use lib $FindBin::RealBin;
chdir $RealBin;
if ( $ENV{'SERVER_SOFTWARE'} =~ /IIS/ ) {
open STDERR, ' iisError.log' || die Can't write to
$RealBin/issError.log: $!\n;
binmode STDERR;
#close STDERR;
}#if
}#BEGIN
use base 'CGI::Application';
use strict;
sub setup {
my $self = shift;
$self-start_mode('test');
$self-error_mode( 'error' );
$self-run_modes(
'test' = 'test',
);
}#sub
sub teardown {
my $self = shift;
}#sub
sub cgiapp_prerun {
my $self = shift;
die( Death message ); ## 500 error
}#sub
sub test {
my $self = shift;
#die( Death message ); ## works
return Test;
}#sub
sub error {
my $self = shift;
return Error mode ran @_;
}
1;
# 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] Getting sub associated with runmode?
Hi All,
The only was I could find to do this was:-
my %rmhash = $self-run_modes();
my $subname = $rmhash{$runmode};
then looking up the key in the hash.
Seems a bit of a waste to return the whole hash.
$self-run_modes( $runmode ) gives and error rather than returning the
sub name.
Is there a better way to do it?
Lyle
# 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] mod_perl vs. FastCGI
Perrin Harkins wrote: On Mon, Jan 19, 2009 at 11:57 AM, fREW Schmidt fri...@gmail.com wrote: The main issues I have with mod_perl is that even with Apache2::Reload I still get errors and have to restart the server while I am developing. Pity the Java guys. It can take 5 minutes or more to restart IBM's EJB dev environment. Most mod_perl servers restart in less than 5 seconds. However, if that still seems like too long, and your code is too tricky for Apache2::Reload, there are two simple solutions. One is to develop under CGI, which should be easy for most CGI::App users. Then you just switch over to mod_perl when you're ready for testing. Another is to set MaxRequestsPerChild to 1, so that your code is compiled fresh every time. If you do this, make sure you don't load the code you're editing in your startup.pl (before the fork). I also like the idea that with FastCGI we can switch back to IIS. Can't say I agree with you there, but to each their own. However, I would caution you that when I tried to find an IIS FastCGI solution a few years ago, there was really nothing available. That may have changed since Ruby increased the popularity of FastCGI. Microsoft have themselves made a FastCGI library. It was done in partnership with Zend to improve PHP's performance on IIS. All details can be found at www.iis.net You don't have to like Microsoft or IIS, but it makes business sense to have it as an option. Lyle # 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] [Fwd: Re: ValidateRM not PP]
Lyle wrote: On Fri, 23 Jan 2009 02:49:24 + Lyle webmas...@cosmicperl.com wrote: Hi Mark, I've only just noticed that ValidateRM has some non Pure Perl dependencies ... Is there currently a way around this that I'm not aware of? No, there isn't. --- Anyone got input on this? I've been working on Data::FormValidator to provide Pure Perl alternatives to Email::Valid and Date::Calc. So if the Xs modules aren't available it'll default to my Pure Perl alternatives. I've got an alternative and patch for Date:Calc, and I'm just finishing off the alternative to Email::Valid... Anyone had any ideas for a Pure Perl FillinForm replacement? At the moment I'm thinking of a simple regexp based alternative??? Lyle # 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] [Fwd: Re: ValidateRM not PP]
Michael Peters wrote: Lyle wrote: Anyone had any ideas for a Pure Perl FillinForm replacement? At the moment I'm thinking of a simple regexp based alternative??? Please, please don't do that! HTML is a complicated language and any regular expressions you come up with will fail on real world code. Trying to identify and change the properties of HTML form elements would be tricky enough, but what about things like + Javascript code which has HTML in strings (very common in DHTML apps) Does the current parser pick that up? I don't think HTML::Parser executes any JavaScript. + HTML comments? + targetting specific forms? Dealing with HTML requires a parser. Anything else won't make people happy. I see. But there isn't a Pure Perl parser available, and for those that really can't get HTML::Parser on their cheap shared hosting, isn't a regexp that works most/some of the time better than nothing? On a side note, get a hosting provider that gives you a compiler, gee wiz! I've got a couple of dedicated boxs, one in the UK and one in the USA. I actually offer hosting on both. Being able to compile isn't an issue for me, but I make commercial scripts and some of my customers have cheap hosting where they can't compile. (Yes I offer them my hosting, or the scripts ran off my hosting, but some of them insist on having all scripts on their cheap hosting). Lyle # 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] [Fwd: Re: ValidateRM not PP]
P Kishor wrote: On 1/25/09, Ron Savage r...@savage.net.au wrote: Hi Lyle I see. But there isn't a Pure Perl parser available, and for those that really can't get HTML::Parser on their cheap shared hosting, isn't a regexp that works most/some of the time better than nothing? No, it's not 'better than nothing'. Ever. All you're doing is lighting the fuse on a time-bomb. Fortunately I am neither advocating nor desiring a pure-Perl form validation module, but I don't understand the resistance to this. The poor bloke is saying -- look, I have folks who want to utilize my scripts in situations where they cannot compile modules... what do I do? Give them something or give them nothing? I am surprised that there is so much vehemence against this. I don't believe Lyle is saying that a pure-Perl alternative is better or even as good as the compiled modules... all he wants is an alternative, which, while most likely unsuitable for more than the simple cases, is likely a pretty good fit for those simple cases. I heartily agree :) In fact, my suggestion would be to not do any form validation with Perl as much as possible... form validation should be done in the browser, and it just might be best to do it with JavaScript so good data reaches the server in the first place. Then, on the server, check for sanity and security. I had given up on the idea of using Data::FormValidator until I read someone post a link to http://formvalidatorjs.berlios.de/ With a JS drop in for Data::FormValidator. It made sense to use these rather than create my own validation in JS and Perl. I've now finished and tested the Pure Perl alternative functions in Data::FormValidator and they pass all the Build tests. Note: These aren't a replacement to the XS modules, they are an alternative used only is the XS modules aren't available. In any case, I respectfully disagree with the Ever qualification to No, it's not 'better than nothing.' There just might be situations in which it maybe better than nothing. I agree. I'm not saying that a regexp solution will ever compare HTML::Parser. Just that those who really don't have a choice, a developed and tested collection of regexps will likely be better than them having noting or writing their own. Lyle # 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] [Fwd: Re: ValidateRM not PP]
Joshua Miller wrote: As for HTML::FillInForm, it's better to do nothing, than to use some regexp. I believe that is the point to which Ron was pointing. Using a regexp can cause you far more problems than good. That's not to say a pure-perl parser cannot be written, but that hand-writing a regex to attempt to half-ass the job is a horrible idea... you'll cause more problems than it's worth. It's still up to you, so you've been warned. I've been reading up on it. It's true that a regexp will always break. A collection of regexps working to get individual parts would be better, but still break in some circumstances. Writing a Scanner - Lexer - Parser in Pure Perl would be ideal, but not without it's own problems. As for validation, your suggestion to not do any form validation with Perl as much as possible is beyond bad advice. If anything, the advice should be reversed (and this is coming from the author of Data.FormValidator.js, which the following post recommends). The whole point of Data.FormValidator.js is to encourage backend validation along with frontend validation, and when issues arise, to encourage the use of backend validation. I don't think he meant not do any form validation with Perl as much as possible. I think that came across wrong, as he later made a comment Then, on the server, check for sanity and security.. I think he was trying to say you should try and have JavaScript as well to reduce calls to the server which is more costly... I could be wrong... I'd second the ever qualification on using a hand made regex to replace a real html parser. It simple doesn't makes any sense. Find an html parser that is pure perl, and extend it - I'm sure there are ones out there. I've looked for one, the only one I could find is HTML::TagParser but it isn't suitable as it can't be used to recreate the page. Also looking at the source it uses regexp. As much as the idea of writing a Pure Perl parser intrigues me, I don't have the time :( Especially as at this time I wouldn't actually be using it (my script is generating all the html input tags and parsing them into the html template). Maybe I'll add it to one of my would like to do at some point if I get chance lists... Lyle # 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] Data.FormValidator.js [Was: ValidateRM not PP]
Joshua Miller wrote: (and this is coming from the author of Data.FormValidator.js, which the following post recommends). I'm just going through the docs and I've downloaded the script (JSAN site only has 0.06 and not 0.07). The script is almost 70K. Wouldn't it be worth offering a minimal version without all the comments, etc? I just fed it through http://javascriptcompressor.com/ and it shrank to less than 20K (although certainly not as pretty). I get the feeling a lot of people would see the size and jump to compress it like me, and you'd loose all your headers. If you offered a compressed version would could keep your copyright notice and site link at the top. Just an idea :) Lyle # 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] Data.FormValidator.js
Joshua,
Have you managed to figure out a work around for:-
'constraints' = {
'password1' = {
'constraint' = check_passwords,
'params' = [ qw( password1 password2 ) ],
},
},
...
sub check_passwords {
my ( $pw1, $pw2 ) = @_;
if ( $pw1 eq $pw2 ) {
return 1;
} else {
return 0;
}
}
I would have thought this is common enough to warrant a work around...
I couldn't see one in your examples.
Am I missing something?
Lyle
# 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] Data.FormValidator.js - New C::A validation plugin
Joshua Miller wrote:
Apologies if this has gone too far offtopic...
I'm planning on incorporating this into a new C::A plugin or possibly an
extension of C::A::VRM, so it's still on topic. Plus me, you and Mark
are on this list which makes things easier.
On Mon, Jan 26, 2009 at 6:40 AM, Lyle webmas...@cosmicperl.com wrote:
Joshua,
Have you managed to figure out a work around for:-
'constraints' = {
'password1' = {
'constraint' = check_passwords,
'params' = [ qw( password1 password2 ) ],
},
},
...
sub check_passwords {
my ( $pw1, $pw2 ) = @_;
if ( $pw1 eq $pw2 ) {
return 1;
} else {
return 0;
}
}
Currently, there is no easy, built-in way to do this.
I would have thought this was a common enough form requirement that
potentially a new profile key could be created. Given that this is also
used for email verification, etc, and not just passwords. After all we
already have the keys dependency_groups and require_some. Potentially
all that is needed is an extra feature for dependency_groups?
Assuming that DFV doesn't error on invalid keys (I haven't checked), a
new key could be made that Data.FormValidator.js uses for this and maybe
the main DFV will follow later?
I would like to see Data.FormValidator.js get support for including
things like that in the profile. While it would break the profiles
compatibility with Data::FormValidator.pm, a filter could be
implemented to let the profile be used on both of them. I'm not
totally sure how that would work out though. At least for myself, I
usually generate the javascript profile from a profile written in
perl, and that would make it difficult to include a javascript
function definition inline.
That's the way I've been testing it out. I think being able to export
(and thus only having to maintain one) Perl's DFV profile is excellent
and something that shouldn't be broken. Although it would be very easy
to add an extra key before it's passed to JS, or remove and extra key
before sent to DFV.
I'm open to suggestions and patches, but that conversation should
probably be moved offlist or to the forum on the Data.FormValidator.js
berlios page.
See opening sentence :)
Lyle
# 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] [Fwd: Re: ValidateRM not PP]
Michael Peters wrote: Lyle wrote: I've looked for one, the only one I could find is HTML::TagParser but it isn't suitable as it can't be used to recreate the page. Also looking at the source it uses regexp. Just looking at the source code briefly, it seems that it's using regexes as part of it's lexing/tokenizing, which is completely appropriate. I've contacted him about a possible patch to allow HTML::TagParser to update the DOM style tag changes into the original HTML. We've exchanged a couple of emails so with a bit of luck we might come up with a solution. It'd certainly be a lot quicker than starting from scratch. As much as the idea of writing a Pure Perl parser intrigues me, I don't have the time :( Especially as at this time I wouldn't actually be using it (my script is generating all the html input tags and parsing them into the html template). Have you thought about maybe using an XML module? XML::SAX has a pure perl driver. Maybe if your HTML is XHTML it could work. Or if you want, you can probably use a libxml based module. It's extremely common (installed on most systems) and has an forgiving/HTML mode. I'll see how it goes with HTML::TagParser, then look into this if needs be. Thanks for the pointer :) Lyle # 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] Data.FormValidator.js - New C::A validation plugin
Lyle wrote:
Joshua Miller wrote:
Joshua,
Have you managed to figure out a work around for:-
'constraints' = {
'password1' = {
'constraint' = check_passwords,
'params' = [ qw( password1 password2 ) ],
},
},
...
sub check_passwords {
my ( $pw1, $pw2 ) = @_;
if ( $pw1 eq $pw2 ) {
return 1;
} else {
return 0;
}
}
I've just tried this code in DFV and I can't get it working? I'm getting
the error
No constraint found named 'must_match' at Data/FormValidator/Results.pm
line 965.
Can't seem to figure out what I'm missing...
Should be working according to the guide I followed at:-
http://search.cpan.org/~purdy/Data-FormValidator-Tutorial-1.61/lib/Data/FormValidator/Tutorial.pm
Has anyone got this working? Do I have to put the sub in a special
package or pass it to DFV in some way?
Lyle
# 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] Should cgi-app use HTML::Template::Pro if available?
Lyle wrote: Hi All, I was wondering if there were reasons why cgi-app shouldn't try to use HTML::Template::Pro (if available) over HTML::Template by default? One of the main selling points of cgi-app for me is it's speed under normal cgi. Considering HTML::Template::Pro's speed gains I would have thought this would be preference? Oops, just read:- http://search.cpan.org/dist/HTML-Template-Pro/lib/HTML/Template/PerlInterface.pod#DISTINCTIONS_AND_INCOMPATIBILITIES Seems they aren't 100% compatible. Lyle # 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] Best email module?
Peter Karman wrote: Lyle wrote on 1/29/09 8:26 PM: Hi All, I wondering what peoples experiences are with email modules on CPAN. ... Any recommendations? Maybe a C::A::P wrapper around the best one(s) would be good? I like Email::Stuff I was very impressed with this. But it looks like it's got some XS dependencies (although checking the code Clone doesn't seem to actually be used, but Params::Util is an issue). I've emailed Adam incase there is a Pure Perl solution/work around to this. Stewart Heckenberg wrote: I like MIME::Lite -- has a very simple attachment interface :) Pure Perl and looks promising, thanks :) Lyle # 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] Best email module?
Lyle wrote: Peter Karman wrote: I like Email::Stuff I was very impressed with this. But it looks like it's got some XS dependencies (although checking the code Clone doesn't seem to actually be used, but Params::Util is an issue). I've emailed Adam incase there is a Pure Perl solution/work around to this. Adam has got back to me already, Params::Util does have a Pure Perl option but it contained a bug. I was able to fix it a supply a patch, Adam took it further and wrote some tests to stop it from happening again. There is now a new version on it's way to CPAN :) Hopefully an Email::Stuff update with Clone removed will follow suit and this module will be a viable option. Lyle # 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] Best email module?
Octavian Rasnita wrote: From: Michael Peters mpet...@plusthree.com Stewart Heckenberg wrote: I like MIME::Lite -- has a very simple attachment interface :) MIME::Lite is what I've used in the past, although the Perl Email folks don't recommend it. Apparently it's very crufty on the insides. I think they recommend Email::MIME instead. Email::MIME is in alpha version yet, although it could work fine. Email::Lite is too low level and it requires too much coding for a complex email message. Mail::Builder::Simple is easier to use for sending complex email messages, with attachments, inline images, or create the message body or the attachments using Template-Toolkit or HTML::Template. It also automaticly encodes the message body and the headers to UTF-8 so they can contain non-english chars. It uses Email::Send for sending email, so it doesn't have the bugs of some Mail::* modules. Octavian This looks great, but it leans heavily on CPAN and there are several XS modules I don't think I could resolve :/ Lyle # 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] Best email module?
Michael Peters wrote: Stewart Heckenberg wrote: I like MIME::Lite -- has a very simple attachment interface :) MIME::Lite is what I've used in the past, although the Perl Email folks don't recommend it. Apparently it's very crufty on the insides. I think they recommend Email::MIME instead. Email::MIME looks good, but Email::Stuff seems like an easier interface to it. I notice that Email::Send now says to use Email::Sender instead. Anyone got any experience with this? Lyle # 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] Re: Should cgi-app use HTML::Template::Pro if available?
Mark Stosberg wrote: On Thu, 29 Jan 2009 21:55:58 + Lyle webmas...@cosmicperl.com wrote: Lyle wrote: Hi All, I was wondering if there were reasons why cgi-app shouldn't try to use HTML::Template::Pro (if available) over HTML::Template by default? One of the main selling points of cgi-app for me is it's speed under normal cgi. Considering HTML::Template::Pro's speed gains I would have thought this would be preference? Oops, just read:- http://search.cpan.org/dist/HTML-Template-Pro/lib/HTML/Template/PerlInterface.pod#DISTINCTIONS_AND_INCOMPATIBILITIES Seems they aren't 100% compatible. That, and I've never noticed HTML::Template to be the bottleneck for a web application. If anything is slow, it's usually a complex, large, or unoptimizeda database query in my case. Besides, we just added the 'html_tmpl_class' method to make it incredibly easy to use a different HTML::Template-like replacement. I know. I found that feature the other day when looking to use HTML::Template::Set. Not having to update all my template code to use it put a big smile on my face :) Lyle Mark # 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] Re: HTML::FillInForm maintanence, patch idea
Mark Stosberg wrote: I have some interest in a pure-perl FillInForm to support a more portable Titanium distribution. The trick there is finding a suitable replacement for HTML::Parser. I haven't had much luck with this. The only pure-perl HTML parser is HTML::TagParser. It works very differently to HTML::Parser and has no methods to re-create the page based on changes you make. I contacted the author about this, he said he has no plans to add that feature but would consider patches. I had an idea about how I might to able to do it, emailed him asking what he thought and haven't heard back for over a week :/ HTML::TagParser currently parses it's way through the HTML extracting everything out into DOM style objects. My idea was to modify the lexer so that it stored the start and end point of each tag. That way when the DOM objects were changed they could be re-made into HTML and swapped back into the original. Whether that's the best idea or not I don't know :/ However I have made some good progress on my YAML based form creation module, which negates the need for HTML::FillInForm. Hopefully I'll have some distributable code soon. Lyle # 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] Re: HTML::FillInForm maintanence, patch idea
Ron Savage wrote: Hi Ron On Sun, 2009-02-08 at 10:58 +1100, Ron Savage wrote: Hi Ron On Sun, 2009-02-08 at 10:53 +1100, Ron Savage wrote: Hi Folks On Fri, 2009-02-06 at 19:10 +, Lyle wrote: Mark Stosberg wrote: I have some interest in a pure-perl FillInForm to support a more portable Titanium distribution. The trick there is finding a suitable replacement for HTML::Parser. I haven't had much luck with this. The only pure-perl HTML parser is HTML::TagParser. It works very differently to HTML::Parser and has no Let's start looking around for a pure-X (X != Perl) parser, and adapt that. How about: http://ejohn.org/blog/pure-javascript-html-parser/ A link on that page (under Philip Taylor (May 5, 2008 at 10:31 am) ) leads to this: http://lists.w3.org/Archives/Public/public-html/2007Jul/1103.html which can generate a Perl parser. Are you willing to take this project on? Personally I'd love to, but to be completely honest there is no way I have time, I've go so many (non paid) open perl projects to keep up to date that I wouldn't be able to make anything more than a pitiful effort to do this, if anything at all. (not the mention the fixing the Perl mushroom plans and projects that I haven't even announced yet). I urge you to take this forward. I'm sure there would be plenty of Kudos for you if you do :) Lyle # 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] Re: HTML::FillInForm maintanence, patch idea
Ron Savage wrote: Hi Lyle How about: http://ejohn.org/blog/pure-javascript-html-parser/ A link on that page (under Philip Taylor (May 5, 2008 at 10:31 am) ) leads to this: http://lists.w3.org/Archives/Public/public-html/2007Jul/1103.html which can generate a Perl parser. Are you willing to take this project on? Personally I'd love to, but to be completely honest there is no way I have time, I've go so many (non paid) open perl projects to keep up to date that I wouldn't be able to make anything more than a pitiful effort to do this, if anything at all. (not the mention the fixing the Perl mushroom plans and projects that I haven't even announced yet). I urge you to take this forward. I'm sure there would be plenty of Kudos for you if you do :) I have plenty of time, but I'm not quite silly enough to volunteer. I'll have to think about it... And, yes, it's tempting :-). Go on! Do it! You never know, you might even get a glass engraved Perl award for doing it. Like those that we give at BBPM:- http://perl.bristolbath.org/?About Lyle # 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] CGI::Application Task and Bundle
Hi All, While working on PerlCertifiedHosting.com I put together our first Bundle::CertHost (Task now also available). I ended up listing within it a lot of CGI::Application plugins (I chose all the ones listed on http://cgi-app.org/index.cgi?Plugins minus the platform specific things like mod_perl). I just checked and Catalyst have a Task:: for common modules. I seems to me it could make sense to have a Bundle and Task for CGI::Application that I could just link to from Bundle::CertHost. I've gone ahead and created a Task::CGI::Application. Let me know if you think any particular plugins should be included or excluded. I thought maybe a special page on the cgi-app wiki could be created for this? That way a script could easily automate the addition of new plugins to the Task::. Lyle # 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] CGI::Application::Dispatch
Hi All,
I was just looking at this modules docs and I noticed it says:-
It will translate a URI like this (under mod_perl):
/app/module_name/run_mode
or this (vanilla cgi)
/app/index.cgi/module_name/run_mode
I'm guess it might have come up before, but might be worth mentioning
anyway. If you are on Vanilla CGI, you can rename you index.cgi to just
index, then use Apache config like:-
Files index
SetHandler cgi-script
/Files
To get URLs like:-
yourdomain.com/index/run_mode
Personally I'd add .html onto the end of all my URLs, and just parse it
off later ($ENV{'PATH_INFO'} =~ s/\.html$//;), to get:-
yourdomain.com/index/run_mode.html
Which is way, way more SEO friendly.
If someone knows the Apache config to get this down to:-
yourdomain.com/run_mode.html
Then please share :) I'm guessing it's possible...
Also, I'm sure similar things are possible on IIS, but haven't figured
that out yet either :/
Lyle
# 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] Re: HTML::FillInForm maintanence, patch idea
Ron Savage wrote: Hi Ron On Sun, 2009-02-15 at 12:21 +1100, Ron Savage wrote: Hi Ron An update on using Ocaml to generate a pure-Perl HTML parser... A link on that page (under Philip Taylor (May 5, 2008 at 10:31 am) ) leads to this: http://lists.w3.org/Archives/Public/public-html/2007Jul/1103.html which can generate a Perl parser. I installed Ocaml, and downloadered Philip's code, but make fails. I've emailed him to see if there is a newer version available. Philip replied, and suggests his code is not the best to investigate. He's given me this URL to follow up: http://suika.fam.cx/www/markup/html/whatpm/readme There are a set of Perl modules there I had never heard about. I shall look into the HTML parser there. Good find. Those aren't on CPAN and look really promising :) Lyle # 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] [Announce] CGI::Application::Plugin::Email
Hi All, Very easy lazy loaded emailing based on Email::Stuff (with it's new Pure Perl dependency options). Lyle # 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] Re: HTML::FillInForm maintanence, patch idea
Ron Savage wrote: Hi Folks Let's start looking around for a pure-X (X != Perl) parser, and adapt that. How about: http://ejohn.org/blog/pure-javascript-html-parser/ I've decided to waste a few days, starting now, converting this to Perl. The module is tentatively called HTML::Parser::PurePerl. Make sure it can either parse in place, or recreate the original HTML with changes. Looking forward to this :) Lyle # 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] [Announce] CGI::Application::Plugin::Email
Perrin Harkins wrote: On Tue, Feb 17, 2009 at 12:39 PM, Lyle webmas...@cosmicperl.com wrote: Very easy lazy loaded emailing based on Email::Stuff (with it's new Pure Perl dependency options). I know you mean well with this, but trivial wrappers around other modules described as plugins is the kind of thing that made me stop taking Catalyst seriously. I mean, you could do this sort of plugin for basically everything on CPAN (and Catalyst did). Considering that almost everything is already on CPAN, then most plugins are likely to be wrappers, adding extra benefits like lazy loading and framework specific functions. It would be wrong to try and recreate things that are already tried and tested on CPAN. Plugins that initially just add lazy loading, will likely grow to take advantage of of other modules and create more framework specific features. For example C::A::P::I18N is a lot more than a wrapper around Locale::Maketext::Simple, and another plugin I haven't released yet for Date and Time methods has already had extra C::A functions added. If you were to extract the lazy-loading code into a sort of generic plugin module that can wrap anything and then give Email::Stuff as a SYNOPSIS example, that would be more interesting. I've been thinking this method would work for a lot of modules, although for some it's a bit more tricky (look at C::A::P::YAML). Lyle # 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] Re: [OT] HTML::Parser::PurePerl
Hi Ron, Ron Savage wrote: Tree, for example, uses Scalar::Util, which uses List::Util, which uses XS. I've drawn similar wrong conclusions several times before. List::Util drops back to Pure Perl if XS is not available. From Util.pm:- # This code is only compiled if the XS did not load eval 'ESQ' if !defined sum; I was the one who suggested Cantrell to add the Purity warnings to CPANdeps. It only really tells you that XS files are a part of the distribution. The only work around for this is for authors to add a comment tag of # pureperl to their manifest if they use XS but can drop back to Pure Perl. Lyle # 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] Re: [OT] HTML::Parser::PurePerl
Ron Savage wrote:
Hi Folks
Uploaded HTML::Parser::Simple to CPAN.
See the FAQ for why the name HTML::Parser::PurePerl was not used.
Good stuff :)
Although after looking through the pod I can't see immediately how to
make changes to the html? Maybe a short example with a change, such as:-
my($p) = HTML::Parser::Simple - new();
$p - parse('htmlinput name=test/html');
### Parse value into input tag test
print $p - result();
Also you say:-
Does this module handle all HTML pages?
No, never.
Have you no intentions of making this read XHTML?
Lyle
# 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] Re: [OT] HTML::Parser::PurePerl
Ron Savage wrote: Any other advice people have on supporting XHTML will be gratefully received. Lots of real pages will declare XHTML but use HTML4 tags and vice versa... I know that's not very helpful but I thought I'd mention it :/ Although looking at the bigger picture... How bad would it be to demand more compliant HTML from ValidateRM users? After all, it's a little bit like having use strict;. Lyle # 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] Intermittent problem with sessions when redirecting
Hi All, I just wasted the last 2 hours going round in circles trying to figure out what is going wrong. Everything works find if I return the normal text/html header. But as soon as I use a redirect instead, the session is sometimes lost. I added logging to try and figure out what's happening. At the bottom of this email are 3 examples, 2 of which fail, one gets through. No code changes were made during the tests. You can see from the 2 that fail, 1 doesn't even make it to teardown, the other starts teardown but doesn't finish. The one that passes completes teardown. From this I take it that something is going wrong and causing the process to die prematurely. This is losing the session file, even though the code to create the session has already ran and completed. Nothing is showing up in the error logs. Any advice very much appreciated, I'm banging my head against a wall here :( P.S. Just noticed I'm not the only one experiencing this http://rt.cpan.org/Public/Bug/Display.html?id=40751 Log started 2009/03/05_02:29:33 cgiapp_init complete setup started setup complete cgiapp_prerun started cgiapp_prerun complete auth_create started auth_create complete session user test ### This one lost the session Log started 2009/03/05_02:30:03 cgiapp_init complete setup started setup complete cgiapp_prerun started cgiapp_prerun complete auth_create started auth_create complete session user test teardown started teardown complete ### This one was ok Log started 2009/03/05_02:32:02 cgiapp_init complete setup started setup complete cgiapp_prerun started cgiapp_prerun complete auth_create started auth_create complete session user test teardown started ### This one lost the session # 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] Apache 1.3 vs Apache 2.2
a...@spatialsystems.org wrote: I'm building a new server for use with CGI::Application and I'm deciding on Apache 1.3 vs Apache 2.2. Currently I use Apache 1.3. I don't see a compelling argument to go one way or the other and I think you all might have more insight as it relates to CGI::Application use. Fellow CGI::Application users, can you tell me which one you prefer? Use 2.2. Some Linux's don't have packages for 1.3 any more. Apache in fact classes 1.3 as legacy now. Lyle # 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] Alpha release - GenVal Form generation and client/server validation
Hi All, I've uploaded part of the YAML based form generation and client/server validation module I've been working on. It's aim is make make creating forms with client and server validation very easy, and ultra easy to keep up to date. Once setup all you need to do is edit the central YAML schema to add/remove/edit form fields and the server and client validation is automatically updated. Background: I'm working on a large project with a lot of config forms. The usual process of updating HTML, JavaScript, DFV profile then finally Perl code is simply not feasible and would be far to time consuming. So I've created this module so all this can be done by editing one YAML file. Issues it resolves: Newer versions of DFV use compiled regexps and closures. These are great for the server side Perl validation but no longer exportable to the client side Data.FormValidator.js validation. As GenVal has all the validation regexps and method names in the YAML, is uses this to create the compiled regexps and closures for the Perl validation and also downgrades them to normal regexps and methods for the JS validation. I've also updated Data.FormValidator.js so that it displays errors in the exact same way as the Perl DFV. I've made newer DFV methods that are only available as closures, such as FV_eq_with, available in Data.FormValidator.js. This is possible because GenVal downgrades the new closure methods to the old format that Data.FormValidator.js can understand. This is only alpha release, so will probably have a few bugs while I work on it. But I thought I'd put it out there for people to see. I've got another version that has all the mysql database schema in the YAML as well. It creates/updates the database tables as needed, so you no longer need to write and DB upgrade routines when you change your forms and data. This isn't released yet though. Feedback much appreciated. Lyle # 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] Re: Proposed new look and branding for cgi-app.org
Stewart Heckenberg wrote: I don't mind the name Titanium, although I actually like saying CGI Application or cgi app -- do we shorten Titanium to tit? :-) Apart from the Ti chemical symbol logo and the name Titanium itself, the site isn't very metallic what with the trees/leaves and green. It's kind of like calling something Chocolate and then not using brown as the primary colour but pink instead. The site design isn't as shiny and solid as the new name might suggest. If you're going to re-brand, you've got to go all the way and be complete. The first design we did was metallic and shiny. It really didn't look good on a site :( Lyle Stew 2009/4/17 Mark Stosberg m...@summersault.com: http://cosmicsitedesign.com/cgi-app/ 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. My biggest beef with Titanium is the name. It has these problems: 1) It's not googleable you can't find anything by searching for Titanium, Titanium Software or Titanium Framework. Contrast this with Jifty (which is #1) and Catalyst (which is #1 for Catalyst Framework and #6 for Catalyst Software). I share this concern, but believe SEO is addressable. There are some good domains available with titanium in the name, which matters a lot, as does the title tag, the keyword/meta tags and the h1 tag and opening content. In short, I think we can solve this with the relaunch of the new website, especially with an intentional focus on SEO, and some post-launch tweaking as we watch how Google and others respond. 2) It's not memorable. While titanium is a nice strong lightweight metal, it is kind of overused in pop-culture, at least imho. I agree it could be more unique. 3) It's too long. 4 syllables, come on! Maybe we could drop some syllables (like Southern US English) to make it titane or titaenyum :) Or maybe we can drop some vowels to make it more web 2.0ish: titnm :) It's 9 characters, the same as Catalyst. I'm open to people referring to it by nicknames. I know we've had this debate before and it's probably out of my hands, but I've always liked taking a few swings with a stick at the deceased bodies of equine animals. :) I appreciate the feedback. There is the practical matter that changing names would have cost of churn, so unless an a newer name is a nickname, it I think it should be *much* better. Mark -- http://mark.stosberg.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/ ## #### # 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] Re: Proposed Titanium site; will it have a wiki or wiki pages?
Ron Savage wrote: Hi Mark Yes, the entire content of the current wiki is intended to be preserved. I have some interest in moving from kwiki to a more functional wiki, but I don't have the motivation now to led that effort, so staying with what we have is easiest, along with re-skinning it. I'm intrigued by the comment about kwiki. I have very little experience in the area myself. Care to say more? I think it would be disastrous to move to a non-perl wiki. So if not Kwiki the options are SocialText or Twiki... Or maybe Perl 6's November in a few months... (I've been helping November run on Windows and IIS). I think a Wiki based on cgi-app would be ideal... Lyle # 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] Proposed new look and branding for cgi-app.org
Jaldhar H. Vyas wrote: I don't really care about the Titanium name but one thing that bothers me about the new site and for that matter the old site -- it's not based on CGI::Application! Shouldn't we be eating our own dogfood? Catalyst has mojomojo, Jifty has wifty. How hard would it be to write a wiki with C::A + appropriate plugins? (Oh God am I volunteering?) I sent my last reply before before your message got to me. You are right, it's great that your volunteering ;) Looks like someone gave this a go a few years back:- CGI::Wiki::Simple There is a well maintained wiki framework on CPAN:- Wiki::Toolkit It doesn't look like it would be hard at all to update CGI::Wiki::Simple to use a modern version of CGI::Application and Wiki::Toolkit Personally I'd love to give it a go, but recently I caught the Perl 6 bug so all my free coding time is spent hacking on that :/ Lyle # 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] Re: CGI::Application mailing list is evolving
Mark Stosberg wrote: Please disregard. Yes, I apologize for the premature announcement. Let me take is opportunity to reframe the conversation, after speaking with Jesse who has now repaired the original mailing list. Performance issues aside, I think it's time that we consider moving to a next generation mailing-list / group-collaboration platform, and I'd like your input on what that is, or what features it has. Lyle Hopkins is offering one solution that is ready to go and I linked to earlier: http://lists.perlportal.com/sympa/info/cgiapp It provides a number of features including built-in archiving, web-based list management, RSS feeds, web-based posting and more. It's also written in Perl, with parts done in CGI::Application. Sympa is written in Perl, but there was a little confusion in my email as it doesn't use CGI::Application. What I was saying was that the site www.perlportal.com (not yet live) will be using a new CGI::Application based CMS. I vote to use a Perl based system, and Sympa is certainly the best one. The PerlPortal project aims to address the issue of out dated and ageing Perl sites, providing modern, new, Perl powered alternatives. It would be great if the CGI::Application mailing list was a part of this. More details about the PerlPortal.com project are here http://wiki.perlportal.com Lyle # 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] Re: CGI::Application mailing list is evolving
Jesse Erlbaum wrote: On Wed, May 6, 2009 at 3:48 PM, Jesse Erlbaum je...@erlbaum.net wrote: Irrational though it may be, I get a much better feeling about something like Google Code (http://code.google.com) + Google Groups. This being said: http://code.google.com/p/cgi-application/ Just playing around. Anyone want admin access to check this out, let me know. Jesse Is it possible to change the design with this? Or will it always look like every other python powered google code website? Lyle # 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] Re: CGI::Application mailing list is evolving
Mark Stosberg wrote: http://code.google.com/p/cgi-application/ Is it possible to change the design with this? Or will it always look like every other python powered google code website? Very little customization is available with Google Code sites, and your point that it is Python powered is taken, although with commerical services the language choice is rather hidden from the user. Yes, Jesse gave me admin and I had a look at the options, it seems very restrictive to me. I've given Jesse admin on the PerlPortal list so that he can review that... Lyle # 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 Logo
Ron Savage wrote: Hi Stephen On Tue, 2009-07-14 at 10:06 -0700, Stephen Carville wrote: I am getting ready to deploy a couple of internal applications. One provides a login service to the wireless network, the other lets users change and reset their Kerberos password. I'd like to put a logo in the trailer section indicting that CGI::Application is the framework and link it to the homepage. Is there an official logo for this? Would the author(s) prefer i call it Titanium. (I like the name BTW) I have a bit of a agenda in doing this. The development department is stuck on Dot net and C sharp as the only way to do anything on the web. The company was recently sold and both the the above apps (and couple more I have in testing) will be seen regularly. I'd like to improve the visibility of Perl and Linux with the new owners. A simple sample is on it's way. Hold you breath. I was discussing having powered by CGI::Application and Titanium logos with Mark as a part of the site update... We didn't get far enough to make them though :/ Lyle # 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] Re: CGI::Application::Plugin::HTCompiled update: need some help
Alex wrote: Hopefully, I don't have to turn this into a git pull request, as I don't get along with git atm. It would take a while... 'git' is a very suitable name for it http://en.wikipedia.org/wiki/Git_(British_slang) Lyle # 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::Prototype - develop cgi applications by subclassing
Jason Purdy wrote: With new advances in Perl OO, we ask what would allow us to leverage that? For the goodness sake, let's please not base cgiapp on Moose. I have plenty of instance scripts in production that would not be able to support it. Can you elaborate on the new advances and what you'd like to see CGI::Application do? - Jason I choose cgi-app because of it's small number of Pure Perl dependencies, making it very fast and lightweight. Adding moose would effect this a lot. Saying that there is no reason you couldn't create a new superclass based on cgi-app that uses moose. Lyle # 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 Logo
I'll get my designer to do some concepts for free and post them here. I know Mark was interested in associating CGI::App with tree (hence the new site design). Lyle # 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::App - creating your own overloaded functions
Ron Savage wrote: I adopted a JS library (YUI), and now send all required JS down to the client in the very first response. Thereafter I use Ajax. The consequences are that the first page load seems a bit slow for the user (maybe 300Kb), but that's not really all that much these days. Sounds like some form of compression would be worth while. With a quick google this looks interesting:- http://demo.java2script.org/lz77js/ Lyle # 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] Logo Brainstorming [ was: CGI::Application Logo ]
Emmanuel Seyman wrote: Can we include something camel-like? A curve in the form of a hump will do fine. Anything to do with a Camel and Perl would have to get approval from O'Reilly. Anything with an onion I think you need permission from TPF. If anything I'd prefer the later, as it's the official Perl symbol controlled by TPF rather than something controlled by a book publisher. Lyle # 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] Powered by logos - first samples
Feedback please:- http://www.cosmicsitedesign.com/cgi-app/poweredby/ Lyle # 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] Powered by logos - first samples
Mark Rajcok wrote: Very nice. Where do I send my contribution? Just send any contribution to the TPF P6 fund ;) Lyle # 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] Runmodes in separate modules
Victor Bruno wrote:
sub display_dashboard : Path('dashboard/')
That's catalyst style code. The way I achieve what you are talking about
is to require in the relevant module based on the runmode name. That way
if you are in Vanilla CGI you only load the modules you need for the
current process. During the setup phase I check what modules are in a
set folder and populate the runmode has based on that.
Hope that makes sense...
Lyle
# 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] Logo Brainstorming [ was: CGI::Application Logo ]
Stephen Carville wrote: On Sat, Sep 5, 2009 at 4:08 AM, Paul Miller listm...@voltar-confed.org wrote: Indeed. If they had CGI-App (rather than ::) and the cool boarders and sizes from the leaves ones... these would be front runners too. Here are some more ideas in the same theme http://www.heronforge.net/cgiapp-logos.html If you want I can get my guy to add a little polish to these? Lyle # 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] Future of the wiki
Hi David, Sorry to come in late on this. As Mark said we discussed a CGI-App based wiki a while back... http://www.mail-archive.com/cgiapp@lists.erlbaum.net/msg07613.html and http://www.mail-archive.com/cgiapp@lists.erlbaum.net/msg07607.html On that second thread I found an old cgi-app wiki on CPAN. With the maintained Wiki toolkit that lives on CPAN I don't think building a new OR updating the old cgi-app wiki would be hard at all. I was supposed to implement that new design, but unfortunately the crunch hit me bad, since I've been juggling work and a Uni degree and haven't had time for much else. We could implement the new design with the Wiki update and kill two birds with one stone :) Go for it David, get this started! Lyle David Kaufman wrote: Seriously, I'd prefer use an exiting Wiki, too, if the goal was just to get some content out there in web editable form. But we already have that. I'm thinking that the development of a cgi-app based Wiki would be an enjoyable activity for the community, and could possibly result in a Wiki that we would not only meet our content publishing and community contribution needs but that would also serve as a best-practices example of what can be built with CGI application. -dave # 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] Future of the wiki
Jaldhar H. Vyas wrote: I believe what Mark is referring to is Stinki -- the Simple TItaNium wiKI which I mentioned to him at YAPC-NA last year. I began renovating CGI::Wiki::Simple which Lyle found on CPAN. And then I got distracted and forgot about it. So today I put it up on github, you may find it at http://github.com/jaldhar/App-Stinki Well done for getting it started :) Wish I had time to work on it :( But sounds like David may well take this up, maybe the two of you should get talking direct (that's if you haven't already) Lyle # 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] Future of the wiki
Cees Hek wrote: On Tue, Feb 2, 2010 at 7:29 PM, Mark Fuller azful...@gmail.com wrote: Mailing lists seem so 1990. I'd ditch it and go with a forum. A forum requires me to actively participate (ie go to the forum every day to see what is there). A mailing list allows me to passively keep in touch since I check my email regularly throughout the day. I don't read every message on the list, but I at least see the subjects and look at the stuff that interests me. I think switching to a forum would loose a lot of lurkers on this list... Cees is completely right. Many of us are very busy people and wouldn't have time to monitor a forum. But having the emails pop in let us quickly scan over the subjects, while we are getting on with our work. There is no way I would have caught this thread if it was on a forum. Lyle # 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] Dancer
P Kishor wrote: So, my question is thus -- how is Dancer different from CGI::App, and why should I use the latter instead of the former? I asked this not lightly because I have many years of experience invested in C::A, but Dancer truly shows how apps should be. I've taken a quick look at Dancer, haven't played with it yet. It certainly has some interesting things going on. I think when I play with the code I'll be aiming to pull some things into my cgi-app based superclass. I like the way cgi-app does things, I like the way Dancer simplifies some things. I like the statement from Mark (I think, correct me) that cgi-app is a good framework for creating frameworks. I'm building my own cgi-app based superclass for my software, I see Dancers simplicity will likely become a problem for the kinds of things I'm wanting to do, but that isn't to say that I can't incorporate some of the ideas into my superclass. Dancer recent came up on Bristol and Bath perl moungers (http://perl.bristolbath.org), Nigel mentioned a couple of other frameworks Mojo and Tatsumaki. I haven't looked at them yet, but if you are looking at Dancer, it's probably worth checking them out as well. Lyle # 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::Plugin::REST
Thanks Ron and Jaldhar for your replies :) # 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] Wikipedia is missing Perl web framework comparisons
Hi All, I apologise for the cross post, but in looking up comparisons to web frameworks I came across the Wikipedia page:- http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks Which has comparisons for most languages excluding the Perl frameworks! Catalyst does have a listing in the others section, but we can do better than that. Lyle # 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] CAP::Routes and Mojolicious::Lite
Hi All, After looking at CGI::Application::Plugin::Routes and Mojolicious::Lite I'm wondering whether it's work patching routes or creating a CGI::Application::Plugin::Routes::Lite plugin that creates the super short Dancer style code for CGI::Application? Lyle # 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::Plugin::REST
I almost did, but opted to roll my own for the time being as the script wasn't using cgiapp. Although once I upgrade it to cgiapp I very much want to use your module. Can't think of any comments off the top of my head, but I'll come back to you if I do. Lyle On 01/12/2010 03:38, Jaldhar H. Vyas wrote: As I prepare to do some more work on this module, I'm wondering is anyone actually using it? If so do you have any suggestions, comments, criticism etc.? # 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] Announce: Data::Session - A re-write of CGI::Session
On 06/12/2010 00:33, Ron Savage wrote: Hi On Sun, 2010-12-05 at 21:21 +, Larig Tech wrote: Thanks, that makes sense now. So at this moment it's pretty much the same as what we get from a visit to github, but you're planning to do frequent releases for bug-fixes and feature enhancements going forward. He, he, he. Let's hope there is no need for /frequent/ releases. Although, given all the testing you (all) are going to do for me, especially on Solaris (since that's the problematic platform reported by CPAN testers), we'll see. Looks interesting. I have to say I was worried when I saw the thread saying about UTF-8 issues with CGI::Session. Lyle # 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] Does CGI::Application::FastCGI support non-ascii Charset?
I remember seeing a Cat thread about the FCGI module having issues with
wide characters. Do you have the latest dev release of FCGI.pm installed?
http://search.cpan.org/~bobtfish/FCGI/FCGI.PL
Lyle
On 02/01/2011 23:06, Juwei Zhang wrote:
Hi,
I had developed a site with CA, where page display Chinese characters. Now I
switched to CA::FastCGI, all Chinese characters couldn't be displayed. Does
CGI::Application::FastCGI support non-ascii Charset? Below is how I set
charset.
sub setup {
my $self = shift;
$self-mode_param(
path_info = 1,
param = 'rm',
);
$self-query-header(-charset='gb2312',-type=text/html);
}
Your help would be greately appreciated!
Juwei Zhang
# 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] Titanium won't install
Sounds like a problem with the test. In the mean time I'd force it on if
I were you. Mark will likely read this and fix when he gets chance.
Lyle
On 28/02/2011 01:46, gvim wrote:
The latest Titanium failed to install on my CentOS 5.5 server, running Perl
5.12.3. It failed to load 2 deps:
Test::WWW::Mechanize::CGIApp
CGI::Application::Server
Output below.
gvim
PETDANCE/Test-WWW-Mechanize-1.30.tar.gz
/usr/bin/make -- OK
Running make test
PERL_DL_NONLAZY=1 /sw/bin/perl -MExtUtils::Command::MM -e
test_harness(0, 'blib/lib', 'blib/arch') t/*.t
t/00load.t .. 1/1 # Testing Test::WWW::Mechanize 1.30, with
WWW::Mechanize 1.66, LWP 5.836, Perl 5.012003, /sw/bin/perl
t/00load.t .. ok
t/autolint.t skipped: HTML::Lint is not installed, cannot test
autolint
t/back_ok.t . ok
t/click_ok.t ok
t/content_contains.t ok
t/content_lacks.t ... 2/5
# Failed test 'Handles not finding it'
# at t/content_lacks.t line 40.
# STDERR is:
# # Failed test 'Shouldn't say it's a test page'
# # at t/content_lacks.t line 39.
# # searched: html\x{0a}head\x{0a}titleTest Page/title...
# #and found: Test Page
# # at position: 33 (line 3 column 16)
#
# not:
# /#\s+Failed\ test.*?\n?.*?at\ t\/content_lacks\.t line 39.*\n?/
#
# # searched: html\x{0a}head\x{0a}titleTest Page/title...
#
# #and found: Test Page
#
# # at position: 33
#
# as expected
t/content_lacks.t ... Failed 1/5 subtests
t/follow_link_ok.t .. ok
t/followable_links.t ok
t/get_ok-parms.t ok
t/get_ok.t .. ok
t/has_tag.t . ok
t/head_ok-parms.t ... ok
t/head_ok.t . ok
t/html_lint_ok.t skipped: HTML::Lint is not installed, cannot test
html_lint_ok
t/link_content.t ok
t/link_status.t . ok
t/links_ok.t ok
t/new.t . ok
t/page_links_content.t .. ok
t/page_links_ok.t ... ok
t/pod-coverage.t ok
t/pod.t . ok
t/put_ok.t .. ok
t/stuff_inputs.t ok
t/submit_form_ok.t .. ok
t/text_contains.t ... ok
Test Summary Report
---
t/content_lacks.t (Wstat: 0 Tests: 5 Failed: 1)
Failed test: 5
Files=26, Tests=203, 24 wallclock secs ( 0.24 usr 0.06 sys + 5.12 cusr
0.44 csys = 5.86 CPU)
Result: FAIL
Failed 1/26 test programs. 1/203 subtests failed.
make: *** [test_dynamic] Error 255
PETDANCE/Test-WWW-Mechanize-1.30.tar.gz
/usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports PETDANCE/Test-WWW-Mechanize-1.30.tar.gz
Running make install
make test had returned bad status, won't install without force
Running make for H/HA/HARTZELL/Test-WWW-Mechanize-CGIApp-0.05.tar.gz
Has already been unwrapped into directory
/sw/.cpan/build/Test-WWW-Mechanize-CGIApp-0.05-GA0QZv
CPAN.pm: Going to build
H/HA/HARTZELL/Test-WWW-Mechanize-CGIApp-0.05.tar.gz
Warning: Prerequisite 'Test::WWW::Mechanize = 1.04' for
'HARTZELL/Test-WWW-Mechanize-CGIApp-0.05.tar.gz' failed when processing
'PETDANCE/Test-WWW-Mechanize-1.30.tar.gz' with 'make_test = NO'.
Continuing, but chances to succeed are limited.
cp lib/Test/WWW/Mechanize/CGIApp.pm blib/lib/Test/WWW/Mechanize/CGIApp.pm
Manifying blib/man3/Test::WWW::Mechanize::CGIApp.3
HARTZELL/Test-WWW-Mechanize-CGIApp-0.05.tar.gz
/usr/bin/make -- OK
Running make test
PERL_DL_NONLAZY=1 /sw/bin/perl -MExtUtils::Command::MM -e
test_harness(0, 'blib/lib', 'blib/arch') t/*.t
t/autorunmode.t ... skipped: Won't test autorunmode_hack if
CGI::Application::Plugin::AutoRunmode isn't installed.
t/cgiapp.t Can't locate object method new via package
Test::WWW::Mechanize::CGIApp::SUPER at lib/Test/WWW/Mechanize/CGIApp.pm
line 23.
# Looks like your test exited with 255 before it could output anything.
t/cgiapp.t Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 13/13 subtests
t/dispatch.t .. Can't locate object method new via package
Test::WWW::Mechanize::CGIApp::SUPER at lib/Test/WWW/Mechanize/CGIApp.pm
line 23.
# Looks like your test exited with 255 before it could output anything.
t/dispatch.t .. Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 13/13 subtests
t/instance.t .. Can't locate object method new via package
Test::WWW::Mechanize::CGIApp::SUPER at lib/Test/WWW/Mechanize/CGIApp.pm
line 23.
# Looks like your test exited with 255 before it could output anything.
t/instance.t .. Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 26/26 subtests
t/pod.t ... ok
t/pod_coverage.t .. ok
Test Summary Report
---
t/cgiapp.t (Wstat: 65280 Tests: 0 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 13 tests but ran 0.
t/dispatch.t(Wstat: 65280 Tests: 0 Failed: 0
Re: [cgiapp] CGI::Session
On 07/07/2011 03:01, Ron Savage wrote: OK - here's what I'll do. I'll use perlbrew to install a fresh copy of 5.10.1. My system Perl (5.10.1) is Debian's 6.0.2, but I won't use that, since I may have upgraded modules before switching to perlbrew, even though I /think/ I only ever used cpanm to upgrade modules. Then I'll check the versions in 5.10.1 with the modules I actually use in Data::Session, and report back. I suspect such a process could be automated and would be useful for module authors. Lyle # 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::Session
On 09/07/2011 03:19, Ron Savage wrote: Hi Lyle OK - As a first step, I've uploaded Module::Metadata::CoreList to CPAN. Docs: http://savage.net.au/Perl-modules/html/Module/Metadata/CoreList.html Sample report: http://savage.net.au/Perl-modules/html/module.metadata.corelist.report.html Looks good :) Lyle # 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 wiki page HomePage updated by MikeTonks
Mike++ On 06/09/2012 12:39, Ron Savage wrote: Hi Mike On 06/09/12 18:58, Mike Tonks wrote: Just a note to say I'm pretty sure we don't want these two spam links on the front page of the wiki, but if I've got the wrong end of the stick just let me know. Big game hunter - Shoot on sight! # 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] telecommute CGI::App job posted
tbh, the job looks nice, but the pay is a bit low for contracting. Lyle On 16/10/2012 15:36, Mark Stosberg wrote: The company I co-founded has posted a job opening for a Perl/JavaScript contract developer. Telecommute applications are welcome: http://www.summersault.com/about/careers/position-perl-javascript-developer/ The position could include helping us update the project to incorporate more PSGI and Moose into the website, among other things. We also have a test suite with close to 20,000 tests which we are constantly working on improving. As the project uses more JavaScript now, we are also using more functional testing using Selenium as well. If you are interested, details for following through are available through the link above. Thanks, Mark # 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] Mailing list shutting down
I makes sense to keep the list going if people still want it. I would rather see Thomas carry it on than it disappear. Lyle On 01/09/2017 17:44, Thomas Krichel wrote: >Thomas Krichel writes > >> If you give me the members' list, I can continue the list on my server. >Actually, since it looks like a mailman list, I could probably take >over the archives as well. > # 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] Ajax and JSON recipe
I have a need to incorporate Ajax calls with JSON data into our application. I was looking for something in terms of a piece of starter code or a recipe. I didn't see anything on the website related to it. CGI Application seems like such a robust framework, that this should be a natural fit. Does anyone have a short starter example of code (both server and client) that they would be willing to post/share that would show Ajax/JSON usage with CGI::Application? Thanks much. Lyle Brooks # 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] Authentication/Authorization prerun interaction
I am attempting to use both
CGI::Application::Plugin::Authentication
and
CGI::Application::Plugin::Authorization
and when I attempt to restrict a runmode to require authorization (and
authentication), it produces a result I find counter-intuitive.
I was wondering if anyone had similar experiences.
The conditions occurs when I restrict a runmode to an authorized
group, and attempt to access it the first time (without authenticating).
What I think should happen is that when I attempt to access the
runmode, I should be redirected to a login form to be authenticated.
However, what actually occurs is that I get a Forbidden page.
When I dug down into the code, it seems this is due to how the Plugin
modules interact with the prerun mode.
When the request comes in, the prerun_callbacks that the Authentication
and Authorization registered are called before the requested runmode
code is executedall good so far.
The Authentication plugin will set the prerun_mode to authen_login
by default. The effect of this, as I understand it,
is to substitute the authen_login runmode for the requested runmode,
which effectively requires the user to authenticate. So far so good.
Then the Authorization plugin callback is run. In this section
of code, it checks get_current_runmode() which returns the original
requested runmodenot the authen_login runmode set by the upstream
authentication plugin.
And at this point, the authorization plugin judges the request to
be unauthorized, and it will then make a call to the redirect_to_forbidding
runmode which returns the Forbidden page I mentioned earlier.
So the Authorization plugin ends up taking action, before the prerun_mode
(set the the Authentication plugin) can be acted on later down the
request cycle.
So if the login form (instead of a forbidden page) should be returned,
what should be the appropriate remedy?
Should setting the prerun_mode() also set $self-{__CURRENT_RUNMODE}
inside of CGI::Application?
or
Should CGI::Application::Plugin::Authorization::prerun_callback be
modified to check the setting of prerun_mode() before get_current_runmode()?
I hope that is understandable. Any ideas other could share would
be appreciated.
# 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] Authentication/Authorization prerun interaction
Quoting Cees Hek (cees...@gmail.com):
On Wed, Jan 11, 2012 at 5:40 AM, Lyle Brooks bro...@deseret.com wrote:
I am attempting to use both
CGI::Application::Plugin::Authentication
and
CGI::Application::Plugin::Authorization
and when I attempt to restrict a runmode to require authorization (and
authentication), it produces a result I find counter-intuitive.
I was wondering if anyone had similar experiences.
The conditions occurs when I restrict a runmode to an authorized
group, and attempt to access it the first time (without authenticating).
What I think should happen is that when I attempt to access the
runmode, I should be redirected to a login form to be authenticated.
The problem here is that Authorization does not necessarily have
anything to do with Authentication. You could authorize someone based
on the IP address that they came from for instance.
Yes, I can understand that point. However, I would think that the
case where Authorization is used in conjunction with Authentication
would often be a far more prevalent 'use case'. No hard data to back
this up...just my gut feel.
However, what actually occurs is that I get a Forbidden page.
When I dug down into the code, it seems this is due to how the Plugin
modules interact with the prerun mode.
When the request comes in, the prerun_callbacks that the Authentication
and Authorization registered are called before the requested runmode
code is executedall good so far.
The Authentication plugin will set the prerun_mode to authen_login
by default. ?The effect of this, as I understand it,
is to substitute the authen_login runmode for the requested runmode,
which effectively requires the user to authenticate. ?So far so good.
Then the Authorization plugin callback is run. ?In this section
of code, it checks get_current_runmode() which returns the original
requested runmodenot the authen_login runmode set by the upstream
authentication plugin.
And at this point, the authorization plugin judges the request to
be unauthorized, and it will then make a call to the
redirect_to_forbidding
runmode which returns the Forbidden page I mentioned earlier.
So the Authorization plugin ends up taking action, before the prerun_mode
(set the the Authentication plugin) can be acted on later down the
request cycle.
So if the login form (instead of a forbidden page) should be returned,
what should be the appropriate remedy?
The quick solution is to short circuit your code so that authorization
checks are only executed when a user is authenticated. You didn't
provide any code so I can't be sure if that is easy or not...
There's not much code to provide. I pretty much use the modules by
taking all the defaults.
For Authorization, I use the HTGroup driver.
For Authentication, I use the HTPasswd driver and the Session store.
I add a user_id to the group file like so...
admin: user1 user2
Then I have a very basic Application module with two runmodes, one that
displays a form (the 'display' runmode) and another runmode that processes
the form data (the 'process' runmode)
In the Application's cgiapp_init() method I have two calls..
$self-authen-protected_runmodes( qw( display process ) );
$self-authorization-authz_runmodes(
display = 'admin',
process = 'admin',
);
Should setting the prerun_mode() also set $self-{__CURRENT_RUNMODE}
inside of CGI::Application?
I am sure this is something that has been discussed in the past and
was avoided for some reason that I can't remember... Have a look
through the archives. I can't immediately see a problem with doing
this and it makes a certain amount of sense, but I may be missing
something.
or
Should CGI::Application::Plugin::Authorization::prerun_callback be
modified to check the setting of prerun_mode() before get_current_runmode()?
This seems reasonable enough, but I am hesitant to just make that
change without knowing what consequences that might have for existing
users.
I hope that is understandable. ?Any ideas other could share would
be appreciated.
My suggestion would be to try and handle this in your own code as I
mentioned above. If your authorization checks depend on someone being
logged in, then only run the checks when someone is logged in.
Seems to me in this very basic case, that an unauthenticated user
should be given the opportunity to authenticate. As it now stands,
the Forbidden page is returned...and the user (even one who would
be authorized to access the runmodes) is never the opportunity to
authenticate...and hence then be judged to be authorized).
This is why I argue that a change should be made to allow the
authentication (via the prerun mode) be given precedence over the
authorization's Forbidden response.
From my reading of the CGI::Application's documention on the
use of prerun_mode(), its purpose is to allow for a new runmode
Re: [cgiapp] Authentication/Authorization prerun interaction
Quoting Cees Hek (cees...@gmail.com):
On Thu, Jan 12, 2012 at 5:18 AM, Lyle Brooks bro...@deseret.com wrote:
Quoting Cees Hek (cees...@gmail.com):
On Wed, Jan 11, 2012 at 5:40 AM, Lyle Brooks bro...@deseret.com wrote:
I tend to do authorization the following way:
__PACKAGE__-authz('group')-config(
DRIVER = [ 'Generic', sub {
my ($username,$group) = @_;
return MyApp-user($username)-in_group($group);
} ],
);
# Only administrators can access anything in this module
__PACKAGE__-add_callback('prerun', sub {
my $self = shift;
return $self-forbidden unless
__PACKAGE__-authz('group')-authorize('administrator');
});
-or-
# Only administrators can run this runmode
sub admin_something {
my $self = shift;
return $self-forbidden unless
__PACKAGE__-authz('group')-authorize('administrator');
...
}
Authentication is handled in Apache using Apache2::AuthCookie which is
probably why I can't come across this problem before.
Thank you for those examples...that may help me work around the
issue.
From my reading of the CGI::Application's documention on the
use of prerun_mode(), its purpose is to allow for a new runmode
to supercede the requested runmodein which case, it seems
like it should as a byproduct also set $self-{__CURRENT_RUNMODE}
In CGI::Application::prerun_mode() replace the line
$self-{__PRERUN_MODE} = $prerun_mode;
with
$self-{__PRERUN_MODE} = $self-{__CURRENT_RUNMODE} = $prerun_mode;
(which I think would address my issue).
You could test that easily by copying the prerun method into your
application and adding your patch.
Yes, I did copy the prerun_mode() code from CGI::Application
to my derived package and applied my patch to the copied code. It
worked the way I envisioned.
I think this is probably the most appropriate way to solve this issue.
The plugin should be able to ask CGI::Application 'What is the
runmode that you are about to execute, without having to do multiple
checks.
I agree completely. I tend not to advance solutions that have
non-obvious side-effects, but this one seems to make sense (and
if it is documented sufficently, it should be acceptable).
I don't what impact that would have on existing code written
for CGI::Application.
Neither do I, but I would suspect it would be minimal (does anyone
else have any comments on this?)
If that approach turned out to be inappropriate, then I would
in CGI::Application::Plugin::Authorization::prerun_callback()
the line
if ($rule = $auth-is_authz_runmode($self-get_current_runmode)) {
be replaced with something like...
my $candidate_runmode = $self-prerun_mode() ||
$self-get_current_runmode();
if ($rule = $auth-is_authz_runmode($candidate_runmode)) {
This brings me back to my comment above. Why should the plugin have
to check in multiple places to find out what runmode is about to be
executed?
Agreed. This second approach I suggested would be less-optimal (IMHO).
than the first approach.
Thank you for taking the time to review my postings.
# 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/ ##
####
