Re: [cgiapp] Titanium won't install
On 2/28/11 2:32 AM, "Gurunandan R. Bhat" wrote: >>From the extract you have posted the problem appears to be that >Test::WWW::Mechanize (a prerequisite for ::CGIApp) failed to install >since the test t/contact_lacks.t failed. I have reported this to the WWW::Mechanize mailing list without response: http://groups.google.com/group/www-mechanize-users/browse_thread/thread/c64 c3dd296008f05 I went ahead and created a bug report just now: http://code.google.com/p/www-mechanize/issues/detail?id=199 -- David Steinbrunner # 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] size of scripts and dependencies
Richard Jones wrote: > P Kishor wrote: >> Hi Richard, > >> I am not sure what you are telling me above. If you are telling me how >> to install a persistent environment, I already know that. If you are >> trying to convince me that it is not difficult to install a persistent >> environment, well, then I don't agree. I think it is difficult and you >> think it is not difficult. That is a perception, and removing that >> perception is half the battle. Let alone the fact that for some >> reason, given seemingly exactly the same environment, mod_perl >> installed perfectly easily on my laptop, and just does not do so on my >> server (everything is Mac OS X). I say "seemingly" exactly as a > > No, not trying to instruct you at all, just offering my experiences with > mod_perl installation, for anyone who's shied away from trying it, and > not realising you were using OS X. So not so much a difference of > perception but of experience. I would like to be able to offer some > suggestions why it doesn't install on your server, but cannot as I've no > experience with OS X (and wouldn't dispute yours). Reminds me of the bad > old days of development on Windows. I believe mod_perl has has always been compiled and ready to use in each Mac OS X release. The only change was that recently it was not enabled by default in the Apache 2 conf when they moved to it so you just need to add: LoadModule perl_modulelibexec/apache2/mod_perl.so These are just my observations from experience. I realize this is not a Mac help list but I thought I should lessen the drama. -- David Steinbrunner # 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 Testing Methodologies
Jason Purdy wrote: > My advice would be to factor your code such that the code is separated > into a testable module. If your delete_customer function works as > expected, then all the layers above should work as well since those > layers are independently tested. My awareness of testing is that there are two main types, what I'll refer to as unit testing and functional testing. Unit testing is what Jason is talking about above. Having a strong base on which to build applications on gives you confidence and is a must if you are serious about automated testing. The thing is, if you are dealing with a MVC (Model-View-Controller) system then you only have your model accounted for without coverage for the V and C bits. Functional testing is where you test at the level of what the user interacts with and deals with test cases your customer could specify. For instance, your customer wants to make sure when x is selected y can not also be selected with out the form returning an error. Using Test::More and WWW::Mechanize, maybe a dash of HTML::TreeBuilder, you can automate that type of test. Of course, there is a little bit more to it since many applications these days have lots of JS logic and you application likely deals with data from a databases that you will want to have be consistent for your tests but you can handle those for the most part if you get creative. It also appears that Selenium is getting a lot of attention by developers for functional testing but I have yet to use it. A search on CPAN shows lots of results for Selenium, too. In any case, I just wanted to make sure that the idea of testing both from the bottom and the top in an automated fashion was talked about together. -- David Steinbrunner # 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] how to use C::A::Dispatch with FastCGI ?
Silent wrote:
> has anyone use C-A-Dispatch with FastCGI ?
> 2. after search from google, I tryed:
>
>
> #!/usr/bin/perl
>
> use lib ".";
> use CGI::Fast qw(:standard);
> use APP::Dispatch;
> while (my $q = CGI::Fast ) {
> APP::Dispatch->dispatch(
> args_to_new => { QUERY => $q },
> );
> }
Looks comparable to code I have working with the exception of a new on the
CGI::Fast call:
while ( my $q = CGI::Fast->new ) {
I'm also sending a value in the default param of dispatch. For you that
value would likely be 'User'.
Beyond those thoughts you might want to look into the debug param and work
with it to see if any light can be shed on things.
--
David Steinbrunner
# 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::Displatch v2, and CGI uploadInfo wierdness
Dan Horne wrote: > However, when I upgrade to CGI::Application::Displatch v2, my file upload > code fails as CGI's uploadInfo is empty. > > When I downgrade the problem goes away. > > Most of the application runs under FastCGI, but the fileuploads run under > standard CGI so as not to hit FastCGI's timeout limits. I have a system running under lighttpd/CAD v2/FastCGI/OpenBSD and file uploads work for me. My file uploads are small and hence have not run into any timeout issues so the upload processing runmode runs just like all my other runmodes. -- David Steinbrunner - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI to FastCGI (mod_fcgid) (using CA::Dispatch)
Giannis Economou wrote: > I have an application running as plain CGI which is using CA::Dispatch. > I want to use FastCGI (especially mod_fcgid) from now on. > Do you have any considerations or suggestions in mind that someone > should pay attention to when doing the switching? > Should I do something special or changing the apache handler should be > enough without any changes to the source code? Giannis, I started an thread on this subject and issues I had regarding it not to long ago on this list. I found that subclassing a CA::Dispatch method resolved the issue I was having but it was more of a short term hack than a fix. That then spawned an off list discussion between Timothy Appnel, Michael Peters and myself. Timothy created a patch that I then contributed to. We are now at the point that we need to bring that discussion back to the list and make the patch available for more to test. Your post is timely. The original thread is here: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/msg05773.html Hopefully Timothy, Michael or myself will be able to get the results of the off list discussion to the list real soon like. -- David Steinbrunner - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application::Dispatch and FastCGI
Dan Horne wrote: > Hmm, I had a similar problem while back, where previous GET and POST data > would seem to reappear. Upgrading CGI (and hence CGI::Fast) made it go away > for me... The box I'm using was built recently and I made sure to update used modules, so that should not be an issue. Here is the version if on related modules: # perl -MCGI -e 'print $CGI::VERSION, "\n"' 3.25 # perl -MCGI::Fast -e 'print $CGI::Fast::VERSION, "\n"' 1.07 # perl -MFCGI -e 'print $FCGI::VERSION, "\n"' 0.67 # perl -MCGI::Application -e 'print $CGI::Application::VERSION, "\n"' 4.06 # perl -MCGI::Application::Dispatch -e 'print $CGI::Application::Dispatch::VERSION, "\n"' 2.03 I don't think it matters but the OS I'm using is OpenBSD 3.9. -- David Steinbrunner - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] CGI::Application::Dispatch and FastCGI
Hello all,
Has any one before me Mixed Dispatch and FastCGI?
It seems that the query object is getting cached. To elaborate, I can start
up the web server, submit a form and it works but using that same form any
number of times after that ends up using the values from the first submit.
If I use Data::Dumper to check the query object before it is passed into
Dispatch, it shows fresh data but when I dump $self from within a runmode
the __QUERY_OBJ values are stale.
I'm unsure if I'm just not doing something right or if I have run into a
bug. I'm also ruining this under lighttpd if it might matter.
Here is what my the main bit of my handler looks like:
#
#!/usr/bin/perl
use strict;
use lib "/usr/local/www/lib";
use CGI::Fast qw(:standard);
use Dispatch;
while ( my $q = new CGI::Fast ) {
eval {
Dispatch->dispatch(
args_to_new => { QUERY => $q },
default => 'Register',
#debug => 1,
);
};
if ($@) {
&errorHandler($@);
}
}
#
I am sub classing CGI::Application::Dispatch so that I can get custom error
handling behavior. I don't think it has any thing to do with the issue but
here it is regardless:
#
package Dispatch;
use strict;
use CGI::Application::Dispatch;
@Dispatch::ISA = qw(CGI::Application::Dispatch);
sub http_error {
my ( $self, $e, $url ) = @_;
die "[Dispatch] ERROR: '"
. $e->error
. ( $ENV{REQUEST_URI} ? "' for request '$ENV{REQUEST_URI}'" : "' " )
. "\n";
}
1;
#
Any help/feedback would be appreciated.
Thanks,
--
David Steinbrunner
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] "Best free DB for a web-based Perl app" response results...
Strong wrote: > Two questions: > > . I didn't know much on those DB-types used in MySQL. Can You tell me, > how I can find out, What is the DB-type I'm currently using, doing my > stuff with MySQL-4.1.11-2? SHOW TABLE STATUS http://dev.mysql.com/doc/refman/5.0/en/show-table-status.html Look to the Engine column for the storage type. > . It has been said that for the concurrent DBs in MySQL and many users I > got to use InnoDB, as it more reliable. Starting with which number of > concurrentting users I should develop my DBs with InnoDB? This may not be the type of answer you are looking for but the following book details the storage types and describes when it is best to use them, among other things: High Performance MySQL http://www.oreilly.com/catalog/hpmysql/ -- David Steinbrunner - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] ANN: Plugin for HTML::Template::Compiled
Jesse Erlbaum wrote: > >> - die_on_bad_params has been removed (yay!) > > Does this mean that you can pass any bad param into the template and it > doesn't die? For me, this is the template equivalent of "use strict". I agree with Jesse. I know many people do not like it but for me it is very helpful because I don't want to go without knowing that a template var has been miss spelled or the like. -- David Steinbrunner - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: "Best free DB for a web-based Perl app" response results...
Robert Hicks wrote: > "... if i only needed MySQL, i'd use SQL Lite." > > Really? I think that would be a poor choice and I like SQLite. ; ) SQLite is an embedded database or at least that is how it is primarily used. Both Apple and RealBasic are using SQLite as a part of there latest persistence engines and I'm sure there are more companies solving client side data issue that have done the same. At a recent previous job, we created a web based system that installed both the web server and database on a desktop/laptop. The system requirements for the system needed to be low enough to run on a windows 95 box with 64 MB of RAM. The system was a derivative of another complete system that ran on top of MS SQL and I was able to port it to SQLite with little effort to greatly reduce installation and licensing issues along with system requirements. If you are planning on creating a system that will have low concurrent usage you will be well served by SQLite but if you plan on making something that will be hit hard then you will likely need to move to a bigger database package. -- David Steinbrunner - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
