Re: [cgiapp] CGI::Application status update from the maintainer
On 08/28/2012 11:27 PM, Mark Stosberg wrote: I look forward to being conversation with you all more about this. I'll set a goal to release the first code-as-draft for my proposal within a week, and look forward to your feedback to sculpt it into a releasable form. I agree with just about everything you've mentioned here Mark. I've been thinking myself that C::A needed to be reinvented as something more modern but that still had the same flavor. My only advice is that since you'll really only have this one time to make a break like this from the past, don't feel bad about breaking backward compatibility. From your email it doesn't seem like you do, just wanted to make sure that you knew we'd support something like that. And like Gabor said, avoid the word CGI :) I know we've been down the naming rabbit hole before and it makes all the bikeshedders come out, a good unique, google-able name would be nice. And naming writes go to the man who does the work, so enjoy :) -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CGI::Application:Dispatch problem
On 03/14/2012 07:43 AM, Jiří Pavlovský wrote: So there must be something I'm not getting about the interaction between dispatch/apache/mod-perl Dispatch uses the PATH_INFO environment variable. And unfortunately sometimes some weird things can interact with Apache to change what value it sets for this. What is your PATH_INFO? -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CGI::Application:Dispatch problem
On 03/14/2012 10:56 AM, Jiří Pavlovský wrote:
If I add dispatch_path to my dispatch module
No need to do that just yet. We're trying to figure out what
CGI::Application::Dispatch thinks the path_info is, not change it.
and print $ENV{PATH_INFO}
from there it has the first element cut off.
Is that what you meant?
Without doing anything with dispatch_path() (which overrides what
CGI::Application::Dispatch does by default) what does $ENV{PATH_INFO}
say? If it's not what you think, then somehow Apache isn't setting it to
what you think it should be.
This could be because of a lot of different things (like which
directories are on the filesystem, how apache is configured, etc).
--
Michael Peters
Plus Three, LP
# 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] Anyone using Chrome's Javascript?
On 12/18/2011 08:14 PM, Ron Savage wrote: Is anyone using Chrome's Javascript [1]? Or heard of anyone using it? It's used in some server-side javascript frameworks like node.js -- Michael Peters Plus Three, LP # 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] interrupt run process in base class ?
On 07/14/2011 02:18 AM, silent wrote:
also I do not want Admin.pm override defined cgiapp_prerun in Base.pm.
Can it extend it?
In Admin.pm
sub cgiapp_prerun {
my $self = shift;
# this runs Base.pm's cgiapp_prerun()
$self-SUPER::cgiapp_prerun();
# do what I need to do here
}
--
Michael Peters
Plus Three, LP
# 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] Sessions leaking with FastCGI
On 06/17/2011 12:42 AM, Mark F wrote: I've got a feeling you'll see the same problem with another persistent environment. If fastcgi were mixing up sessions, I think there'd be more talk about it. :) I agree. It sounds like it's a bug in your code that a persistent environment exposed. It most likely would have happened no matter which persistent environment you chose (FastCGI, mod_perl, Starman, etc). Look for global variables or package variables. You should avoid those for anything that changes per-request (or really changes at all). -- Michael Peters Plus Three, LP # 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] Open source applications written using CGI::Application
On 06/14/2011 02:49 AM, Gabor Szabo wrote: Is there any plan to upload it to CPAN? It's not a simple matter of uploading it to CPAN. Krang handles it's own dependencies including Apache and mod_perl and bundles/builds it all together. It would take a lot of work to make it work as a normal CPAN distribution and probably not worth it since you still can't specify exact module version requirements for CPAN installs. I tried to install it on Strawberry Perl 5.12.3. It pulled in lots of CPAN modules including Class::DBI (I thought it is not in fashion any more :) It isn't in fashion anymore, but it was still used when Smolder was started and I haven't felt the need to change that since it works just fine. and some of the prereqs had to be force installed but in the end Smolder refused to install: I sent the failure to the RT queue. It'll probably sit there for a while. Smolder's never been run on a windows machine and I don't have one (nor the inclination really) to help out with that. Patches would be welcome though as long as someone else is willing to maintain them. -- Michael Peters Plus Three, LP # 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] Open source applications written using CGI::Application
On 05/30/2011 04:30 AM, Gabor Szabo wrote: - Krang http://www.krangcms.com/ was last touched 2 years ago (is it still used?) We've been really bad about keeping the website up to date. We actually just made a new release 2 months ago. -Smolder - if I am not mistake in is using CGI::Application but it is not listed Yes, it's CGI::Application based. -- Michael Peters Plus Three, LP # 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 lazy-load runmodes
On 05/24/2011 07:34 AM, gvim wrote: Whilst a FastCGI solution improves startup time it doesn't address the memory footprint. I'm comparing deploying an app with CGI::Application vs. CGI with separate Perl scripts on a VM with a modest amount of mempory. From the what I'm learning about CGI::Application it seems that the memory footprint will skyrocket if your codebase has, say, 15 Perl scripts each containing over 300 lines of code as you now have 15 x 300 lines of code running instead of 300, no? You're concerning yourself with irrelevant details until you know it's a problem. As Ron Savage pointed out earlier in the thread, if you split your run modes out into specific modules and then used C::A::Dispatch to dispatch between them then you'd basically have lazy loading. But the key here is that you're worrying about memory usage before you know it's a problem. Perl abstracts a lot of the details about memory is used from you and any guesses you take about how much things will be will likely be wrong. 300 lines of code is nothing, memory wise. Data takes up a lot more space than code. So my advice, write the application in a way that is the most maintainable and easy to adapt for the developers. Then do some profiling and find out if you are within your memory parameters and then (and only then, after you know it's a problem) do some memory tunings. BTW, just some free advice from my experience: having a persistent (mod_perl, FastCGI, Starman, etc) environment will actually save you memory on linux. Forked processes will do copy-on-write (COW) memory so they will physically share the same memory even though logically they have their own memory space. -- Michael Peters Plus Three, LP # 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] [OT] Shopping carts and shipping costs
On 03/11/2011 08:43 PM, Ron Savage wrote: The problem is they started by specifying a shipping cost per item, but of course various items can be jammed into a single package. I think in general places calculate shipping cost by weight. These days, with single cost shipping for certain package sizes this will probably end up being an estimate rather than an exact cost. I'd probably estimate on the high side too since no one likes to lose money on sales and it does take time and effort to do the shipping. -- Michael Peters Plus Three, LP # 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] Calling redirect under CA::Dispatch and mod_rewrite
On 11/26/2010 04:07 PM, Gurunandan R. Bhat wrote: Is there something about using redirects under CA::Dispatch that I am missing? I use CA::Dispatch and redirects all the time. Although not from CAP::Redirect. I instead use the header_type and header_props combo. -- Michael Peters Plus Three, LP # 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] Software caused connection abort - CGI::Application::Plugin::Stream
On 10/27/2010 07:41 AM, Mike Tonks wrote: Error executing run mode 'download': Software caused connection abort at /usr/share/perl5/CGI/Application/Plugin/Stream.pm line 91 The download works fine for me, and nothing showed up in testing, but I've had quite a few errors logged on and off - so some users are obviously having trouble. Anyone seen this before / got any ideas? That seems like someone is pressing the stop button. That would kill the connection and your server wouldn't notice until it tried to write to that connection, thus the error. -- Michael Peters Plus Three, LP # 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] hook question
On 07/29/2010 05:58 PM, Todd Ross wrote:
I understand the distinction between compile time and run time (as phases),
but
I'm not fully appreciating the impact here; I'm still a little lost.
You indicate that method calls happen at runtime. Assuming that these qualify
as method calls ...
__PACKAGE__-add_callback('prerun', \hook_prerun);
Private::Webapp-add_callback('prerun', \hook_prerun);
Yes those are method calls and they happen at run time. So they happen
after you've already created and run your application.
... isn't the only time they can be processed during compile time? They're
not
in a method that can be invoked at run time.
No, they aren't any different than the methods you invoked to create
your application object (new) nor the method you invoked to run it (run).
Even if the package were placed into a separate .pm file, you indicate that
the
usepackage statement is going to be processed at compile time, which seems
like the same phase they're processed in in my existing example. Why would
the
behavior change?
use will find the package, compile it and then run it, returning the
value of the last operation in that package (which is why you always see
Perl packages with a 1; at the bottom, so that it has a successful
statement to run that returns a true value).
In your case the same basic things happen except that there is no use
to compile and run the package before you create and run your
application object. So perl compiles that script (including your web app
package) and then starts executing the script. And you create and run
your application object before you run those callbacks, so you never see
them executing.
--
Michael Peters
Plus Three, LP
# 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] Running a plain CGI::Application as FastCGI / PSGI
On 07/30/2010 11:50 AM, Jani Hurskainen wrote: I think I got the idea of Plank/PSGI (a specification and middleware for web framework developers) but I don't quite understand what benefits my CGI::App based webapp gets using mod_psgi instead of mod_fastcgi ? It's Plack not Plank :) The benefit is that once your application works with PSGI then you can move it between mod_cgi, mod_perl, fastcgi, Starman, Tatsumaki, Twiggy, etc. It's not tied to a particular web server since there are Plack adapter layers that can be used to make a PSGI application run on any of those. Most web frameworks try to abstract away most of this already, but they all do it in different wants. PSGI is meant to standardize all of these so there's not so much wheel reinvention. Also it allows people to write middleware components that can be run for any PSGI application. So a catalyst app running under mod_perl can use the same debugging toolbar as a CGI::Application app running under Starman. -- Michael Peters Plus Three, LP # 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] hook question
On 07/29/2010 05:16 PM, Todd Ross wrote:
#!/usr/bin/perl
use strict;
use warnings;
my $webapp = Private::Webapp-new();
$webapp-run();
package Private::Webapp;
use base 'CGI::Application';
# Neither of these work -- why?
__PACKAGE__-add_callback('prerun', \hook_prerun);
Private::Webapp-add_callback('prerun', \hook_prerun);
You're confusing runtime and compile time. Some things (like package and
use statements) run at compile time. Other things (like any method
calls) happen at run time. So your package is compiled and methods
added, but those hooks won't be added until after $webapp-run() has
already taken place.
But if you put the package into it's own file you wouldn't have this
problem since the runtime code in the package is run when the use
Private::Webapp statement is run.
--
Michael Peters
Plus Three, LP
# 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] Anyone tried param validation with Brannigan.pm?
On 07/26/2010 08:51 AM, Jason Purdy wrote:
After giving Brannigan a cursory glance, it looks pretty nice, but what
does this offer that Data::FormValidator doesn't?
From the opposite point of view, here are some things that Brannigan
doesn't do that DFV does do and that I can't live without:
1) Validations can't be stacked. In my applications I like to give error
messages depending on what's wrong, not just a simple blanket didn't
pass kind of thing. So if I have an email field that must be less than
255 characters, all ascii chars, must be a valid email address, with a
valid MX message and must not already exist in the database, then I want
a separate error message for all of those. I can do this with DFV with
custom constraint routines. This is an example that's almost exactly
like what I have in an existing application:
my $profile = {
required = ['email', 'name'],
constraint_methods = {
email = [
string(max = 255, ascii_only = 1),
email(check_mx = 1),
unique(table = 'person', column = 'email'),
]
},
};
Then with the resulting Data::FormValidator::Results object I can check
not only which fields, but which constraints. And those custom
constraint methods can set flags (like the name of the constraint
failure) which help me determine if, for instance the email() constraint
failed because it wasn't an email address or if that MX record was bad.
2) Built-in validation methods get special treatment. In DFV the only
difference between built-in methods and custom methods are the package
you import them from. All of them are higher-order subs which return
subs that interact with the Data::FormValidator::Results object.
It seems to me from looking at the Brannigan docs that built-ins get
extra keys to make them easier to use but custom validation methods use
the validate keyword. This means that it you can't distinguish between
multiple types of failures in custom validation routines (see #1 above)
3) No filters. With DFV you can have filters like trim(), alphanum(),
etc. These can be applied to all of your input fields or just certain
ones. Brannigan looks like it can do single fields with the parse
attribute, but I don't see any way to do that for every input.
4) Taint-handling. Almost all the time if I've validated some input it
should also be considered non-tainted. And if it shouldn't I can turn
that off selectively. But it's almost always what people want.
5) Better group handling: In DFV we have require_some, dependencies and
dependency_groups. Not used in every form but really nice to have when
you need them.
--
Michael Peters
Plus Three, LP
# 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] use persisten instance of cgiapp with cgi::fast?
On 07/19/2010 07:16 AM, Dietrich Streifert wrote: As the method implies a new instance of my cgiapp is created for every request. With speedy_cgi I used to only create a cgiapp instance once and reuse it on request. I consider my cgiapp to be a big one and it would benefit a lot from being instantiated once and the instance reused often. Are you sure? Have you benchmarked it? It doesn't matter how much code is in your application or how many modules you are pulling in since that's a one time compilation hit at startup. The only thing I can think of one reason to not want to call new() on every request and that is if you are doing something intensive at init or setup time. -- Michael Peters Plus Three, LP # 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] use persisten instance of cgiapp with cgi::fast?
On 07/19/2010 10:09 AM, Dietrich Streifert wrote: I think most of the performance penalty comes from the DBI-handles which are not kept open between the requests. Every instance opens two DBI-handles which are used frequently during runmodes. You really should benchmark it to see where the time is spent. I think is a bad way to go about performance improvements :) I'm almost always surprised to find out what my real bottlenecks are. Having said that, DB handles may or may not be real problems. MySQL for example can create new DB handles quickly and with very little overhead. Oracle on the other hand is very expensive. If you do find (Devel::NYTProf, hint, hint :) that you application would benefit from persistent DB handles take a look at DBIx::Connector. It handles that for you and would fix the problem of stale DB handles that people usually encounter when they try to do it themselves. There are also some big hashes being initialised Can you move this to compile time and initialize them at the class level? as well as more than 50 runmodes being setup each time. A hash of 50 items is almost negligible in the time it takes to initialize. Additionally there is a reopen of STDERR into a file in cgiapp_init which is called on every new instance but only once if the instance is reused. I don't know how much of a speed hit that would be but I doubt it's much. Again, profile, profile, profile and you'll most likely be surprised where your real bottlenecks are. -- Michael Peters Plus Three, LP # 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] FormKeys / Nonce
On 07/16/2010 02:19 PM, Todd Ross wrote: 1) Are there existing Nonce solutions that I might be overlooking? 2) What's the best way to integrate the concept into CGI::Application? (Plugin?) For both of these you should look at the CGI::Application::Plugin::ProtectCSRF module. It might not be exactly what you're looking for, but it should give you at least a basis for your own solution. -- Michael Peters Plus Three, LP # 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] Graceful Error Handling in CGI::App (compile / init stages)
On 07/07/2010 05:16 AM, Mike Tonks wrote:
1) So and so CPAN module is not found
2) Config file not found (ConfigAuto - in cgiapp_init)
currently these produce an ugly 500 Server Error and loeave you
searching in the apache log for the problem.
For 1) is there a better way than:
use Data::Dumper;
use XML::Simple;
use Date::Manip;
use HTML::FromText;
It's verbose, but the only thing I know of is:
BEGIN {
eval { require Data::Dumper; Data::Dumper::import() };
die Can't find Data::Dumper module: $@ if $@;
}
repeated for each one.
that will safely try to load the modules needed and allow me to report
via a nice formatted error page what's wrong?
Btw, it's not a good idea to show detailed error messages on your
website. It's a security concern as it gives out more information to
attackers than necessary. So it's not a good idea to start.
Error logs are your friend. Learn them and learn to love them.
2) If I hit an error in cgiapp_init, is there a way to redirect to an
error page, as per prerun_mode() ?
There doesn't appear to be. There's the error_mode() but that only seems
to work for run modes, not other stages.
--
Michael Peters
Plus Three, LP
# 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
Just a note that you can also use CGI::Application::Dispatch to implement a REST interface as well. -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CGI::Application::Dispatch problem
On 04/27/2010 03:12 PM, Brad Van Sickle wrote: [Tue Apr 27 11:58:35 2010] -e: [Dispatch] ERROR for request '/dispatchperl/': Can't locate object method new via package public::Packages::PublicSite at /usr/lib/perl5/site_perl/5.8.8/CGI/Application/Dispatch.pm line 702. [Tue Apr 27 11:58:35 2010] -e: You've told Dispatch that your module name is public::Packages::PublicSite when in fact it's just PublicSite. -- Michael Peters Plus Three, LP # 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] C::A::P::Routes
On 03/04/2010 10:04 AM, Brad Van Sickle wrote: Maybe CGI::Application::Dispatch or CAP::Routes is a better/more powerful way to do this... but I don't see how. Which is why I'm asking. There are pros and cons to both ways (using mod_rewrite or Dispatch) and I frequently use them both, even in the same project. The main reasons I like (and wrote) Dispatch is because I wanted pretty URLs with more meaning (REST-ish). This makes things slightly more sane. But by doing it all in the proxy with mod_rewrite means that you need to change your httpd.conf every time you change your application. If these rules are in a proxy then it's definitely a violation of concerns when your proxy server needs to be intimately familiar with your applications URL structure. It also makes it harder to move the application around to a different server setup or different proxy software. And using Dispatch makes certain things way easier than mod_rewrite. Off the top of my head: + Dispatching based on HTTP request type (GET vs POST) + Dispatching based on + Easier to understand and write. Compare '/app/:rm/:year/:month/:day' vs RewriteRule /app/([^/]+)/([0-9]+)/([0-9]+)/([0-9]+) http://server/app.pl?rm=$1year=$2month=$3day=$4 [P,L] Now try to imagine how much crazier that regular expression needs to be if you wanted to do something like this: '/app/:rm/:year?/:month?/:day?' + Easy to pass different parameters to your application's new() method. Imagine for example a situation where you have a single application (same code) but you need to customize that application depending on the URL that was accessed. Maybe it's a beta version, or a different client, etc. -- Michael Peters Plus Three, LP # 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] C::A::P::Routes
On 03/03/2010 05:58 PM, P Kishor wrote: I do use CAD in another application, and yes, that works rather well. For a number of reasons, I want to explore CAPRoute. In fact, one thing I don't like about CAD is that it breaks the (to me) established formula of extending a CA application's functionality via a plugin. In fact, there are lots of C::A related modules that aren't plugins: CGI::Application::FastCGI CGI::Application::PSGI CGI::Application::Server And you'll note that they're all concerned about what happens before your application module begins to do it's thing. Dispatch has to happen outside of your application module because it in fact picks which application module to run based on the URI. I don't want all that routing table stuff in my instance script. I want it in my App.pm, along with all the run modes. This will only work in very simple situations where you only have a single application module. I try to not have more than a dozen run modes in any application file, and all but the simplest of applications will have more than that. -- Michael Peters Plus Three, LP # 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] Keep connection alive for request that takes long time to run
On 02/10/2010 10:38 AM, Shao, David (NIH/NLM/NCBI) [C] wrote:
I use CGI::Application for my web app. The app sometimes takes longer to run
than the timeout limit set by the apache server, which results in a 'Bad
Gateway' page at user side. My web admin suggested I need to implement
something similar to 'heartbeat' to keep the connection alive. My
interpretation to this is, while my app is running, it needs to send a
'keepalive' packet to the client in short intervals (i.e. shorter than the
timeout limit), to prevent the server from dropping the connection. I am
fairly new to CGI::Application, and my questions are if this feature already
exists (but I can't find it in documentation), or if it is not, is it
possible to implement using CGI::Application?
The is similar to what the C::A::Plugin::Stream does. Basically you tell
C::A not to send headers and then you print your own response. The
difference being that you don't want to send actual content while your
app is working, but just empty data to hold the connection. Something
like this:
$self-header_type('none');
my $not_done = 0;
while($not_done) {
print \0; # send null byte to keep the connection open
... # do some work
}
If the long running task you want to do can't be broken up into chunks
such that you can print a null byte, then you need to rethink your
architecture. Probably best to think about having a job queue which does
the work and a URL that your page contantly hits to figure out if the
job is done. When it's done you can then redirect the client to where
you want them to go.
--
Michael Peters
Plus Three, LP
# 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] proposal for new cgiapp hook: loaded_html_tmpl
On 11/11/2009 10:46 AM, P Kishor wrote: I use it exclusively, under the assumption that, like 'use strict', it is just best practice, But a real question I have is, should designers (who are the ones creating these, or at least that's one of it's benefits is that they can) be burdened with strict when the environment they operate in (HTML, CSS) is inherently not strict. may make my code faster I seriously doubt this. Especially if your code has to do lots of $tmpl-query() stuff to make sure that a variable is present before doing a $tmpl-param(). and less error-ridden, The only error I know that this catches is a misspelling on the programmer's side. Which I'll admit is a real problem. But in most of my cases, it's a problem that's easily seen because the data does not show up where it should. and may endow me with good looks and untold riches Maybe if you rub Sam Tregar's belly. But I'd be careful, he's got a mean right hook :) -- Michael Peters Plus Three, LP # 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] UTF-8 output
On 11/02/2009 12:43 AM, Michael Lackhoff wrote: Without the header_add I get a HTTP header with an ISO-8859-1 charset definition so the browser thinks it is latin1 and even a meta http-equiv=content-type content=text/html; charset=UTF-8 / in the template won't help. That's very strange. Does it happen the same across all browsers? The meta tag should be equivalent to the HTTP header. And is there no better way for the template output than to post_process the whole template? Is there no way to get the output of tt_process as UTF-8 so that there is no post_processing necessary? I have a patched HTML::Template that reads in the templates as UTF8, my db connections are all UTF8 and I decode the CGI params as UTF8. As long as all your inputs are UTF8 decoded then you don't need to explicitly encode the output. -- Michael Peters Plus Three, LP # 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] plugin for recaptcha
On 10/20/2009 08:45 AM, Jason Purdy wrote: I'm not sure you need a plugin for reCAPTCHA. The Captcha::reCAPTCHA CPAN module looks like it's pretty easy to fold into a runmode or a FormValidator constraint method. And just to plugin my own module, you can use the Mollom service (http://mollom.com/) and Net:Mollom. -- Michael Peters Plus Three, LP # 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] TestApps
On 10/17/2009 04:31 PM, Alex wrote: Even if I would delete the file, the namespace I had chosen for the .pm test file would be registered for me. This is totally dependent on where you put your modules. Most people put testing modules that are only useful for your specific module inside t/lib/ so that they aren't indexed like the things in lib/. -- Michael Peters Plus Three, LP # 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] another oddity installing CGI::Application::Dispatch
On 10/15/2009 08:10 PM, P Kishor wrote: What I don't like about the above is that the build script tried to futz with my Apache conf file (setting ulimit, which, on a Mac OS X machine, actually is problematic), and then tried to restart my Apache server (if I am reading the above output correctly). Dispatch runs under normal CGI and mod_perl (and needs to do different things under each) so it needs to run it's tests against mod_perl. This is done with Apache::Test, which does all it can to start Apache w/mod_perl (hence the ulimit juggling). In any case, C::A::D did not install under ~/perl, as is evident from the above. What gives? It failed the tests. This usually means something is strange with your mod_perl setup. Can you run the tests under verbose to get more output? Also, there's this line: [ error] error running tests (please examine t/logs/error_log) So looking in there would also reveal more information as to why it failed. -- Michael Peters Plus Three, LP # 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] another oddity installing CGI::Application::Dispatch
On 10/16/2009 09:47 AM, P Kishor wrote: Another thing -- perhaps a prompt would be advised here saying that We are going to change your Apache conf file, and your Apache server is going to be restarted. Type [restart] to continue, or [cancel the test] to skip the test. The default should be [cancel the test]. It doesn't really work like that. Apache::Test doesn't change your apache config, it just uses the existing apache/mod_perl binary with it's own config file. -- Michael Peters Plus Three, LP # 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] Streaming Status Updates for a Long-running Run Mode
On 10/07/2009 10:33 AM, eric.b...@barclayscapital.com wrote: How can I update my web page with status from this run mode while the subprocesses are running? There's a couple of different ways this can be done. The best is definitely not the easiest but it means creating a separate offline job queue that can run these processes and keep their status in a shared location (like a DB, etc). Then your rm just adds a job to the queue and returns. Then when you're checking on the status via Ajax you need to have another rm that simply checks on the status of the job and returns a flag that could mean success, failure, or try again later (still working). Unfortunately, since you are using Ajax, you can't use the standard NPH approach and just periodically print something to the browser while it's working. Ajax requests don't return (in the javascript) until the entire request is done and it will probably timeout on you. -- Michael Peters Plus Three, LP # 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] Streaming Status Updates for a Long-running Run Mode
On 10/07/2009 11:35 AM, eric.b...@barclayscapital.com wrote: The approach I'm working on now is to have a global status hash for each file being processed, which I'll update as I run each subprocess and when each completes. Then I've thrown in a quick run mode that simply sends that hash back as JSON and I'm putting some logic into my page to periodically make a request for this runmode so I can update the page with current status info. I really wouldn't do that. Don't tied up your web server for long running tasks just so that you can wait to show a status to the user. Even something as simple as Unix at for a simple queue would be better. On a related note, is there a way to have cgiapp send content back to the client during the processing of a run mode instead of at the end when the rm returns? No, not for Ajax. And it's not a limitation of cgiapp, but of HTTP/Ajax. For non-Ajax you use Non-Parsed-Headers (NPH) which means you tell C::A to not send headers and you then instead print them yourselves. And then periodically print more things to the client (like some JS that updates a progress bar, etc). But like I said in the other email, this won't work for Ajax. -- Michael Peters Plus Three, LP # 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] Streaming Status Updates for a Long-running Run Mode
On 10/07/2009 12:24 PM, eric.b...@barclayscapital.com wrote:
I wouldn't do that either, but I've had no end of issues with running
subprocesses from Apache2.
Me: Doctor it hurts when I try to run subprocesses from Apache2.
Doctor: Don't do that :)
What I try to do is have an external process which looks for jobs to do
and then does them. Then my web app simply puts things in the job db
table and the job queue picks them up and processes them, putting the
status (complete, failed, working, etc) back in the db table. Then my
web processes that check the status of jobs checks to see if it's done
and then shows that in the browser.
Almost all web applications that I know have some things that should be
delegated to an external job queue. Even something as simple as sending
an email shouldn't be done from the web processes (could get stuck on
DNS lookups or SMTP waiting, etc).
I just ran across the 'at' solution, which I like quite a bit, however
it turns out that we do not receive the email for the users that the web
server runs under and 'at' sends error and other confirmation
information via email, so I have no idea at this point why my
subprocesses aren't running.
If you want to go the at route instead of writing your own queue (or
using an existing queue) then have at call a Perl script that wraps
around the real process doing the work. Then it could set a failed
status and error messages in the DB or something that you could have
access to. Obviously if this wrapper fails it would have the same
problems, but that should be pretty infrequent since your wrapper could
be really simple.
Understood that you can't do this with Ajax, but how would you do it
with cgiapp in a non-ajax context?
Something like this rough code should work
$self-header_type('none');
print Content-type: text/html\n\n;
$print $main_content; # but don't close the html tag yet
while($not_done) {
# do some work
...
# periodically print so the browser doesn't close the socket
print \0;
# or print some progress that the already printed document knows
# how to deal with
print script type=text/javascriptupdate_progress(10)/script;
}
print /html;
return;
--
Michael Peters
Plus Three, LP
# 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
On 09/18/2009 09:33 AM, P Kishor wrote: But, now that we are done comparing our overweight weight to a morbidly obese weight, how about CGI::App on its own? To my completely uninformed mind, loading 40,000+ lines to create a small web page sounds like a lot... and, that doesn't even include the web server and the Perl interpreter! But that's not what you tested. You tested Titanium which is not CGI::App. It's an opinionated framework based on CGI::App and it's plugins. If you just want to create something that makes small web pages then just load CGI::App and it's dependencies. Also, let's look at those numbers: DBI - 7824 CGI::Simple - 3900 That's 1/4 of all those lines just right there. And if you're going to use a database you need DBI. And if you're going to make a web app you need a CGI interface module (like CGI.pm or CGI::Simple) so I don't see a way to remove those. Also, you're counting just raw lines which means you're counting comments and whitespace (which penalizes modules which are well commented). I'm not saying your criticism isn't valid, I'm just saying that your data is too flawed to support that criticism :) -- Michael Peters Plus Three, LP # 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] Output an excel file
fREW Schmidt wrote: Now I'm shooting for a little more refinement - creating an Excel spreadsheet using Spreadsheet::WriteExcel - and I can't seem it to get to print it out from the file handle. In that case, I'd change somethings about your setup. Instead of creating the whole spreadsheet in memory, you should either write it out to a file and them stream it when finished (using CGI::Application::Plugin::Stream helps here, but you'd still need to clean it up afterwards, but really every web app should have a temp directory that periodically gets cleaned up) or print it as you create it (which means making the FH STDIN instead which might be trickier under mod_perl or maybe not). And then remember to close your workbook when it's done. -- Michael Peters Plus Three, LP # 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] Output an excel file
Michael Peters wrote:
And then remember to close your workbook when it's done.
Also remember to send the right content type and other headers:
$self-header_add('-type' = 'application/vnd.ms-excel');
And if you're not going with CAP::Stream, then also mime-type, content-length,
and content-disposition/attachment. But really CAP::Stream makes this whole
thing so much easier. And you can probably do the cleanup in your teardown method.
--
Michael Peters
Plus Three, LP
# 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-based code and web servers
Ron Savage wrote: And, what do people feel about these modules? Smolder uses H::S::S (via CGI::Application::Server) and it worked great for development but when it was deployed it would just hang several times during the day. So I needed to restart it all the time. Smolder now uses H::S::S + Net::Server::Prefork which not only performs better but also seems to be more stable (but I did receive a report of it crashing after about a week of running). So if you go this route, definitely use N::S::P with it, but don't expect the stability or performance of what you'd get from Apache. The big benefit though is that they are Perl and can be installed from CPAN, which means that now Smolder can be installed from CPAN. -- Michael Peters Plus Three, LP # 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-based code and web servers
George Hartzell wrote:
When you use H::S::S + N::S::P, are you still using C::A::S on top of
them, or is there something else in the mix?
Not for Smolder, it just used C::A::S (which is a H::S::S subclass) and then we
have
sub net_server { 'Net::Server::PreFork' }
--
Michael Peters
Plus Three, LP
# 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] Tasks after fork()'ing a CGI::Application
Gurunandan R. Bhat wrote: I would like this to be as robust as possible. Currently, all I do in the child before launching the long-running process is close STDOUT. Is there any other tasks I must perform? Make sure you don't have have any other file handles in use. This includes sockets and database handles. Is there a CPAN module that might help clean up things in the child better than this? I tried Proc::Daemon but that closes all file descriptors inherited from the parent(including a few datafile descriptors that I need access to). I can of course re-open them from well know locations. You really should re-open them. Strange things can happen when your system gets under a decent load that aren't apparent when testing or under a light load when you share file handles/sockets across processes like that. Any advice on making this method more robust would be hugely appreciated. I would actually suggest that you don't fork your web process to do background tasks. The problem is that your web processes are generally much heavier than you need which means wasted resources. It also can cause scalability concerns if you suddenly have lots of background tasks to perform. I'd suggest you look into having a dedicated job queue. You could use one of the existing frameworks like Gearman or TheSchwartz, or you could write you own using something like POE or Proc::Daemon+Parallel::ForkManager. -- Michael Peters Plus Three, LP # 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] Tasks after fork()'ing a CGI::Application
Gurunandan R. Bhat wrote: Thanks. I did seriously consider TheSchwartz and gearman. I have two features that I want to implement: First, I want to pass some feedback to the user who queued the task indicating progress. I normally use a custom job queue for more flexibility and store the jobs in the database (as serialized data structures). Then my web processes can query the DB to see if the job in question has finished and thus give a progress report to the user. Second, I must be able to schedule it at a future time. I am currently using Schedule::At to do this. Again both are fragile and as you correctly pointed out, will suffer when scaled. My queue also allows this, but I'm not sure how TheSchwartz or Gearman handle that. -- Michael Peters Plus Three, LP # 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: error subclassing CGIApp
P Kishor wrote:
So, I think I have discovered an answer to my problem -- seems like I
can't have setup in BaseCGIApp.
Sure you can. You just need to make sure that you call your base class's setup()
method in your child classes if you're overridding it. This is pretty standard OO:
sub setup {
my $self = shift;
$self-SUPER::setup();
# now do my own stuff
}
--
Michael Peters
Plus Three, LP
# 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] very huge file modes
Paul Miller wrote: ... but you're saying that what I'm doing will indeed work, it's just better written with CAP::Stream? You were using the correct idiom for dealing with large files. Don't read it all in memory at once, but instead chunk it. -- Michael Peters Plus Three, LP # 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] packages autouse?
Porta wrote:
I saw it, but unless I use the superloader, it still need to define the
names of the modules I want to use.And, regarding the superloader, I'm lazy
enough to want to use all the packages within a given folder, but not just
every possible module in the world...
Still, a good suggestion.
I usually do something similar with some of my mod_perl programs to preload them
into memory but you could probably do something similar. You could use it like:
use MyProject::AutoUse;
And it could look something like:
package MyProject::AutoUse;
use File::Find qw(find);
BEGIN {
find(
{
wanted = sub {
return unless m/\.pm$/;
return if /^\.?#/;# skip emacs droppings
my $module = $1;
$module =~ s/\//::/g;
my $pkg = MyProject::$module;
eval use $pkg;;
die Problem loading $pkg:\n\n$@ if $@;
},
no_chdir = 1
},
'/path/to/project/lib/MyProject'
);
}
caveat: not tested but should give you the general idea.
--
Michael Peters
Plus Three, LP
# 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] CAD, dispatch table and config file
Porta wrote: Anyone solved having the dispatch table for CAD on a external config file instead on the dispatch package itself?If yes, which config file format? There's no support for that directly. If you wanted to do it you'd have to code up something manually. You'd also need to make decisions like + should it load the config file on each request? when the file has changed? or never? + what format will the config be in? I personally just leave my dispatch table in my code and rarely need to edit it. I only usually have 3 or 4 lines in my dispatch table anyway so it's not really a burden. -- Michael Peters Plus Three, LP # 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] Redirect Question
Stephen Carville wrote: The login page POSTs to a new URL for authorization check. Depending on the results, The authcheck routine then redirects to the splash page or an error page. This keeps the history clean but seems to require I append the ?rm=runmode to the redirect URL. You could just not do a redirect (which uses HTTP and makes the browser go fetch another URL). You could instead just return the run mode you want. Something like this: return $ok ? $self-splash : $self-error; Is there way to avoid this? Maybe make the redirect to send the runmode as a POST instead of a GET? No, the request that follows an HTTP redirect are always GETs and you can't force the browser to do something else. -- Michael Peters Plus Three, LP # 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: Testing Methods
Mark Stosberg wrote: In addition to using CGI_APP_RETURN_ONLY, you can also create a tiny sub-class of CGI::App-based module, so that html_tmpl_class returns 'HTML::Template::Dumper'. Then you'll get back a data structure of template instead of an HTML page, and this makes testing the values you send to the template easier. Not to take too much away from this, but it doesn't test your template logic. Now most of my templates are very simple, it's still logic and can therefore have bugs. -- Michael Peters Plus Three, LP # 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: 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. We could also consider a commodity platform like a Google Group or similar. I'd be ok with either of those. I don't care if it's all a single system as long as there's a simple place to put the links to all the things we care about. Which features are important to you? Are there particular services you recommend? Things I want: + Reliable + Easy to use + A more common SCM system (not darcs). SVN is popular and tolerable. Git is nice and fast (and with something like github forking and fixing things becomes more a community thing than just patches in an RT ticket). + Web-based posting (but still keeping the email list) is nice because you don't have to join the group to participate with just a short quick question. I'm already subscribe to too many lists so whenever I can ask a quick question without having to subscribe again it's a win. Things that make me go meh: + I'm not too big on RSS feeds for mailing lists, just seems kind of redundant. + Archives don't need to be built into the system since other systems do archiving and do it really well (http://www.markmail.org/) -- Michael Peters Plus Three, LP # 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
Porta wrote: +1 Mantle +1 -- Michael Peters Plus Three, LP # 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
Michael Peters wrote: My biggest beef with Titanium is the name. It has these problems: Another reason to not use it: It's already been taken. http://snook.ca/archives/html_and_css/titanium -- Michael Peters Plus Three, LP # 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
Lee Carmichael wrote: How about 'Mantle'? http://en.wikipedia.org/wiki/Pearl, http://en.wikipedia.org/wiki/Mantle_(geology) A couple of positive meanings, easy to say and type, short I like that actually. And if we ever wanted to make it more special we could just change the spelling to something like mantul or mantl, but mantle is good too. and not used much beyond geology. Well, and fireplaces with a split spelling change :) -- Michael Peters Plus Three, LP # 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] LinkIntegrity vs ValidateQuery plugin?
Mark Stosberg wrote: Anyone here using LinkIntegrity? How are you doing lightweight query validation? To be honest, I don't do lightweight query validation. For projects that I work on I normally just have 1 validation framework (based on D::FV) and any place that's important enough to validate I just use the same framework. Also, I normally don't care about users changing links and getting ISE's, I consider that their own fault. And if by changing a URL they can see something they aren't supposed to see, I consider that a security design flaw and usually fixed a different way. -- Michael Peters Plus Three, LP # 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
Mark Stosberg wrote: Lyle Hopkins has generously worked with me to prepare this proposed redesign for cgi-app.org. I'm interested in your feedback before moving forward: http://cosmicsitedesign.com/cgi-app/ I like the general look and feel. 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). 2) It's not memorable. While titanium is a nice strong lightweight metal, it is kind of overused in pop-culture, at least imho. 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 :) 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. -- Michael Peters Plus Three, LP # 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] Ajax and JSON recipe
Lyle Brooks wrote:
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?
The client is just Javascript and it's best to pick a framework to handle all
the messy browser details for you. I use Prototype, but I like JQuery as well.
The details of how to use them depend on the framework, so I won't put those
examples in here. And then for the backend, using CGI::Application::Plugin::JSON
makes it really easy.
Also, there are several ways to JSON in your application. You can just return
full JSON structures as the body of their reply.
return $self-json_body({ foo = 1, bar = 2});
Sometimes it's nice to return HTML in the body but with some extra information
in your HTTP headers as JSON:
$self-json_header({ valid = 1 });
return $html_tmpl-output;
And then there is JSONP (http://en.wikipedia.org/wiki/JSON#JSONP) which is
basically returning Javascript that executes over some JSON. Really nice and
simple for mashups, etc.
--
Michael Peters
Plus Three, LP
# 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] Proposal: CGI::Application::Plugin::ValidateQuery
Mark Stosberg wrote: This means we had to find some other way to interrupt the flow and return our error page. The solution is to write a suicide note and then pull the trigger. Or rather, in validate_query(), if validation fails, we do a just-in-time setting of error_mode(), and then die, which interrupts the flow and triggers the error_mode to be called. Now that I've thought of this approach, it makes me want to apply to to the ::ValidateRM interface. Anyone see a reason not to take this approach for this plugin, or ValidateRM? Some people feel that exceptions shouldn't be used for flow control (I'm not usually one of them) but some of them are very opinionated. Just wanted to bring that up. -- Michael Peters Plus Three, LP # 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] Can I override CAP::Dispatch::dispatch_path() ?
silent wrote: but it seems not work, all the request goto the default app default run_mode. You don't show where you're using Mydispatch or how your using it. -- Michael Peters Plus Three, LP # 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] New to working with CGI::App and OO perl. Testing under mod_perl. The old inconsistent data with reloads problem.
Derek Walker wrote: I'm running into the old chestnut of a problem of how to properly 'wrap' a perl application under mod_perl to avoid the shared global variable issue (that I only partially understand at this point) The basic idea is don't use globals (to make things simpler, my package scoped variables are the same as globals in this email). The problem is remembering that your package won't be recompiled on every request so anything you put in a global will stick around for every request. Sometimes this is what you want (say for a configuration object which doesn't change between requests) but in others it's not. I see you have a $user and @roles. Those are definitely per-request kinds of things and should never be globals. Also, you really shouldn't put a database handle as a global either since that could timeout and then you'll get strange problems at 6am when people start using your app again in the morning after it's been sitting for hours without any use. Under mod_perl Apache::DBI takes care of giving you a nice peristant DB conection without you having to worry about things like timeouts. -- Michael Peters Plus Three, LP # 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] Krang 3.05 released
The Krang development team is proud to announce the release of version 3.05. Krang is an open source CMS, particularly well suited for high-volume magazine-style web sites. And because it has an extremely flexible addon system, developers can customize it to create a CMS that is specific to your industry. Originally developed in 2003 by Primedia, Krang is used by many well-known web sites including New York Magazine, Motor Trend, and Soap Opera Digest. Screenshots available at https://sourceforge.net/project/screenshots.php?group_id=103045 This release mostly includes small features and bug fixes. For full details please see the change log located at https://sourceforge.net/project/shownotes.php?release_id=668591group_id=103045 -- Michael Peters Plus Three, LP # 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] getter behavior for -start_mode() ?
Terrence Brannon wrote: $app-forward( $app-start_mode ); # would be nice! Are you saying that start_mode() doesn't return the start mode? It should. -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CGI::Application::Dispatch
Lyle wrote: Which is way, way more SEO friendly. Really? A .html extension makes it easier for Google (the only one that really matters http://www.codinghorror.com/blog/archives/001224.html) to find it? What evidence do you have for that? If someone knows the Apache config to get this down to:- yourdomain.com/run_mode.html If you don't actually have any .html files then you can probably use a FilesMatch + mod_rewrite to change the URL to yourdomain/index/run_mode.html behind the scenes. But I'd worry about that situation because you're not including the modlue/application name in that URL. If you only have 1 application module then you probably don't need Dispatch to begin with. And if you do add more later then you're going to have problems since you'll need to change all those urls, so hopefully no one has them bookmarked. -- Michael Peters Plus Three, LP # 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
Steve wrote: A little bit off topic to the HTML::FillInForm discussion (or maybe not). But does anyone know of a module like HTML::FiF that would allow me to fill in other things such as: span id='error_firstname'/span Check out this patch from Sam Tregar: http://use.perl.org/~samtregar/journal/35037 -- Michael Peters Plus Three, LP # 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 always being called twice
kropotkin wrote: I have a form post to a url. The 'runmode' is passed as a form field. The 'instance script' is called and it instantiates its class. The subroutine/runmode is called. Twice. Do any obvious causes occur to anyone? It's being called twice? Once by C::A during and once by your module? I'd use Carp::cluck in your run mode to get a backtrace of where exactly your method is being called from. -- Michael Peters Plus Three, LP # 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] Re: CAP::JSON and UTF8
Mike Tonks wrote:
Hope it's ok to mail you directly.
Yeah, that's fine, but I'm cc'ing the C::A list so that others can benefit from this discussion.
Also, sorry for taking so long to get back to you on this.
I recently added your
CGI::Application::Plugin::JSON module to my project, and was very
pleased until I noticed my french language stuff with utf8 characters,
accents and so on, was mangled in the output.
I have temporarily abandonned the plugin and replaced the code as follows:
# send the JSON in the document body (removed)
#$self-json_body( $data );
# Signal to JSON::Any to use utf8
$ENV{JSON_ANY_CONFIG} = utf8=1;
my $j = JSON::Any-new;
my $json = $j-encode($data);
return $json;
Since CAP::JSON uses JSON::Any and it calls encode() then you should just be able to set
$ENV{JSON_ANY_CONFIG} = utf8=1 in your application somewhere (probably in the prerun or init stages).
Just wondered if you had come across this and had any thoughts or suggestions.
But since the JSON_ANY_CONFIG thing isn't documented anywhere, it's probably best to use something
else. How about $self-json_args()? It would just keep the args around and pass them to JSON::Any's
new() method. So in your init/prerun you'd do something like this:
$self-json_args(utf8 = 1);
And now that I think about it, all these json_* methods are kind of annoying. I probably should have
gone with $self-json-* instead. Oh well...
--
Michael Peters
Plus Three, LP
# 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?
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. -- Michael Peters Plus Three, LP # 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 do I access CGI.pm methods?
Justin Wyllie wrote: How do I access CGI.pm methods like request_method() from my CGI::Application? $self-query returns a CGI object. So just say $self-query-request_method. -- Michael Peters Plus Three, LP # 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] Turning off Template output for AJAX
kropotkin wrote: How do I stop C:A outputting a template from a run-mode? This is for a method which serves an AJAX call. C::A doesn't output a template by default. You must have some other plugin loaded that does that. Besides, what does an AJAX call have to do with not using a template? -- Michael Peters Plus Three, LP # 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] Turning off Template output for AJAX
kropotkin wrote: I see - yes; I found the place in postrun where we are loading the layout template and I just turn it off. I suppose you could use a template for AJAX but since the body is no more than the AJAX response text I'm not sure I can see the point It depends on how complicated the output of the AJAX response is. Some are very small HTML snippets, but others are more complicated (lots of tables or forms, etc). So a template is very appropriate. -- Michael Peters Plus Three, LP # 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] add_callback problem when using Plugin::JSON
kropotkin wrote:
't locate object method add_callback via package MyPackage at
/usr/lib/perl5/site_perl/5.8.8/CGI/Application/Plugin/JSON.pm line 232
This is my code:
use CGI::Application::Plugin::JSON ':all';
$JSON::Any::UTF8 = 1;
return$self-json_body({text = 'test', fail = (my $filefail ?
'fail' : 'ok')});
You need to use a CGI::Application::Plugin::* module within a CGI::Application based object.
Otherwise it can't add the appropriate methods or callbacks.
--
Michael Peters
Plus Three, LP
# 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] add_callback problem when using Plugin::JSON
kropotkin wrote: I am. my Class inherits from CGI::Application. All the other CGI::Application methods work. Your answer feels right but my class really is based on CGI::Application. Any other ideas? The show us your real code. Obviously that snippet you showed us isn't real, so we can't really diagnose the problem. My initial thought is that you're loading CAP::JSON before you set your base class to be CGI::Application. -- Michael Peters Plus Three, LP # 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] Turning off Template output for AJAX
kropotkin wrote: Alright. I take the point that it is consistent design wise - but I am outputting JSON so a template isn't really necessary in this case. You're right, JSON doesn't need a template. HTML, Text and sometimes XML are good use cases for templates. But does the C:A JSON plugin require me to be using a template? No, not at all. -- Michael Peters Plus Three, LP # 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: + 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. No, I'm saying that your simple regex approach whould change the JS code on the page, which is *not* what people would want. + 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? If it were me, the answer would be no. A minor template change could break your application in mysterious ways. I'd rather not have an HTML::FillInForm replacement than one that works sometimes and not others. -- Michael Peters Plus Three, LP # 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: 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. 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. -- Michael Peters Plus Three, LP # 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] getting C::A::Dispatch to ignore certain URLs
P Kishor wrote: How can I make C::A::Dispatch ignore URLs that point to anything in the server/img/ directory? Let's try re-phrasing that question... How do I make my webserver not call C::A::Dispatch for anything under /img? Even if Dispatch had a way of ignoring certain urls, what would it do? Exit? What does that accomplish? The webserver itself needs to serve that content and since Dispatch runs under lots of different web servers there's no way for it to tell that server that it has decided it now doesn't want to handle that object after the server has passed control over to Dispatch. The webserver needs to make the decision as to whether or not Dispatch should serve it, not Dispatch. -- Michael Peters Plus Three, LP # 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: 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) + HTML comments? + targetting specific forms? Dealing with HTML requires a parser. Anything else won't make people happy. On a side note, get a hosting provider that gives you a compiler, gee wiz! -- Michael Peters Plus Three, LP # 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] calling another runmode
Terrence Brannon wrote: Can I simply do $self-logout_confirmation_runmode to 'internal redirect' to another runmode? Yes. If you don't have anything that depends on what the value of current_runmode() is, then that's the simplest (and fastest) approach. If you do need current_runmode() to be updated then look at C::A::Plugin::Forward. If you need any cookies to be updated between run modes then you'll need to go back to the client and then come back. Pretty easy and even easier with C::A::Plugin::Redirect. -- Michael Peters Plus Three, LP # 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::Dispatch help
fREW Schmidt wrote: Ok, I have changed some things around in the hopes that it will fix my issues, but I am still not having much luck... If you're still having problems, post the debugging output from Dispatch. -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CGI::Application::Dispatch [post] runmode not working
P Kishor wrote:
CGI::Application::Dispatch-dispatch(
prefix = '',
default = '',
debug = 1,
table = [
'' = { app = $App, rm = 'view' },
'find' = { app = $App, rm = 'find', },
'view/:p?/:o?/:s?' = { app = $App, rm = 'view', },
'edit/:p/:o?'= { app = $App, rm = 'edit', },
'other_pages/:p/:o?' = { app = $App, rm = 'other_pages', },
'create/:p/:o?' = { app = $App, rm = 'create', },
'save[post]' = { app = $App, rm = 'save', },
'/:p?/:o?/:s?' = { app = $App, rm = 'view' },
],
args_to_new = {
..
},
},
);
The 'create' runmode presents a form with 'method=post' and
'action=index.cgi' and a [submit] button named 'rm' with
'value=save' but the debug switch in the C:A:D table sends messages
to the log that show that the 'save' rule is never matched.
Dispatch dispatches based on the URL. In your case that URL is going to be index.cgi. Change the
action to be /save, keep your method as post and remove the name rm from that button (nameless
buttons are pretty common in web forms).
--
Michael Peters
Plus Three, LP
# 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::Dispatch help
fREW Schmidt wrote:
If you're still having problems, post the debugging output from Dispatch.
Ok, so I changed the match from '/' to '' and it didn't change
anything. I am pretty sure the issue is with apache as the
ENV{PATH_INFO} does not include the junk directory I typed in. This
is the output I get (I added PATH_INFO) for the url:
http://locahost:8080/frew/controller_station/awesome
What is your document root? And what is your actual directory structure like
under that root?
--
Michael Peters
Plus Three, LP
# 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::Dispatch help
fREW Schmidt wrote:
#{{{ Aircraft Ducting
VirtualHost *:8080
ErrorLog C:/Documents and Settings/frew/My
Documents/Code/aircraft_ducting/logs/error.log
Perl
use lib 'C:/Documents and Settings/frew/My
Documents/Code/aircraft_ducting';
$ENV{MODE} = 'development';
/Perl
ScriptAlias / C:/Documents and Settings/frew/My
Documents/Code/aircraft_ducting
DocumentRoot C:/Documents and Settings/frew/My
Documents/Code/aircraft_ducting
Location /
SetHandler perl-script
PerlHandler ACD::Dispatch
Order allow,deny
Allow from all
/Location
/VirtualHost
#}}}
I think the Location probably tramples the DocumentRoot and
ScriptAlias directives.
Maybe not. What happens if you change them. Also, why are you using a DocumentRoot or ScriptAlias
directive when you're handling everything under '/' with that Location?
--
Michael Peters
Plus Three, LP
# 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::Dispatch help
fREW Schmidt wrote: Maybe not. What happens if you change them. Also, why are you using a DocumentRoot or ScriptAlias directive when you're handling everything under '/' with that Location? If I remove ScriptAlias OR DocumentRoot nothing happens. If I remove both it stops ignoring the junk directory that I put in the url, but it adds it's own static directory to the beginning (so instead of localhost/frew/bar/baz yielding /bar/baz I get /htdocs/frew/bar/baz). Well, I'm not sure why, but Apache is doing something weird here. Is this a Windows problem (did someone else in this thread point out that it works right on Ubuntu)? You could try just putting in your own dispatch_path() method in your Dispatch class to strip out the first directory part of the PATH_INFO. -- Michael Peters Plus Three, LP # 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] questions about C::A::Server
I'm experimenting with moving Smolder over to C::A::Server (to remove the dependency on Apache and make it CPANable and thus easier to package for distributions). Things are going ok so far, but I have a few questions. 1) Is there a way to control the HTTP response codes? I used to send a 401 response along with the forbidden page when someone tried to access something they shouldn't. I'd like to continue that if possible. 2) C::A::P::Stream seems to have issues when run under C::A::Server. It seems that the HTTP headers it's trying to set are being interpreted as being part of the file. So I loose the content-type header and my file is corrupted. 3) It prints to the screen a lot of information, that while useful for developing, I will eventually want to turn off for distribution. I'm planning on daemonizing it, so I guess I could just redirect that output, but that's what I was planning on doing for the error log, and having all those urls, etc in the error log would be a bit much since they aren't errors. Thoughts? -- Michael Peters Plus Three, LP # 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: 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 a good way to leave yourself vulnerable to CSRF attacks. If you prevent CSRF attacks in other ways (using referer, single use submission tokens, etc) then you're probably ok. Maybe I don't get it. Just tell people to get a decent browser that remembers those things for them. Then they can worry about the security of their own machine and you won't be responsible if they lose their credentials. Besides, if you were doing your passwords correctly, you wouldn't even be able to fill in the form since you wouldn't know what it is, only they would. -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CGI::Application::Dispatch help
fREW Schmidt wrote:
I am a little confused about how CAD is supposed to work I guess.
Let's see if we can help...
First off, I have a directory, call it abc.
That right there is kind of a red-flag. Not that you're doing anything wrong, but Apache has a weird
notion of PATH_INFO when a real directory exists. And Dispatch relies on PATH_INFO for parsing. You
can check what Apache thinks it is by printing the $ENV{PATH_INFO} in your Dispatch.pm.
I think this is all you might need to see from there:
Directory c:/path/to/abc
SetHandler perl-script
PerlHandler ACD::Dispatch
AllowOverride None
Order allow,deny
Allow from all
/Directory
Why are you using a Directory for this? I'm not sure if that affects what Apache does with PATH_INFO
or not, but I usually use a Location. Especially since your not serving things out of that directory
directly (instead you're using ACD::Dispatch to provide a virtual directory).
Ok, so here is what has been happening:
Go to:
localhost/abc/
Get:
Home, welcome
What is PATH_INFO here? I would expect it to be ''
Go to:
localhost/abc/fdjksalfdsafdsa
Get:
Home, welcome
What is PATH_INFO here? It looks like it should be 'fdjksalfdsafdsa', but Dispatch looks like it's
behaving with a PATH_INFO of ''.
Go to:
localhost/abc/jkfldjskljfdkls/home_othercontroller
Get:
Error'd
Again, PATH_INFO looks like it should be 'jkfldjskljfdkls/home_othercontroller' but Dispatch behaves
like it's home_othercontroller
Go to:
localhost/abc/jkfldjskljfdkls/home_othercontroller/some_rm
Get:
Home/OtherController, some_rm
Similar to the above.
So I guess my questions are: why is it ignoring that first directory?
I think you've hit on a weirdism of Apache changing the PATH_INFO if the real directory (in this
case abc) exists. Try changing the directory name to something else and see if that changes anything.
And
do I actually have to put the startrunmode in the dispatcher? It seems to
be ignoring the one set in OtherController.pm.
No, the start run mode should be executed if no run mode is given in the PATH_INFO. Try turning on
debugging and see if you can get any more information.
--
Michael Peters
Plus Three, LP
# 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?
Lyle wrote: 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. For me, the safest way to do it is to let the browser remember. All the major browsers know how to remember usernames and passwords now a days, so why duplicate that feature. Saving the username and password in cookies wouldn't be secure, so I guess some kind of cookie ID. Storing an encrypted username and pw would be ok. 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. You're right that if someone checked remember me on a public computer then someone else could come by later and recover the username and password of the last person to do that. But that's the risk that happens when people tell public computers to remember their private information. -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CGI::Application::Dispatch: Apache vs. IIS
Jason A. Crome wrote: mpeters: If I sent you a CGI::Application::Dispatch::IIS subclass, could you (or Mark) incorporate it into the CA::Dispatch distribution? Or, if you don't want to mess with it and wouldn't mind another co-maintainer, I'd be happy to maintain this bit of it. I'd be happy to have it along. The easier it is for others to use the better. No need for them to go hunting all over CPAN for it. -- Michael Peters Plus Three, LP # 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 do I implement this pattern: Resume interrupted POST after login
Clayton Scott wrote: I went as far as freezing the query and stuffing it into the session. Short of using LWP to rerun the POST what are my options? That's actually a pretty good option. You can't just pass the extra POST params to the authentication request since they might mess it up (think of having a New User form where you fill out a new user's username, then that get's passed to the authentication program and fails...) also since you're using some other 3rd party for authentication there's no guarantee that they'll pass those extra params back to you. So you need to serialize and store the params (you could use Storable and a session for this) and then when redirected back check if there's something stored to replay, and if there is then do it. You don't necessarily need to use LWP. If you're using mod_perl you could do a subrequest, or if just plain C::A you could figure out what module you're going to run and just call it's run() directly after setting up a CGI.pm object with your thawed POST params. -- Michael Peters Plus Three, LP # 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] Testing harness for non-CGI::App code
Ron Savage wrote: Is Test::WWW::Mechanize the most appropriate harness for testing CGI (but not CGI::Application) code? I love T::W::M (used with Test::HTML::Content). But why limit yourself to just normal CGI and not CGI::Application code? IMO it's not only important to test the C::A code, but also the environment you're running it in. If you run your tests just via the module but your application runs under Apache, then there will be bugs that your tests don't catch. -- Michael Peters Plus Three, LP # 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] run mode issues when posting data
Michael De Soto wrote: I had a little bit of trouble passing the POST parameters to the login run mode. This was solved by stashing them in the app's param during cgiapp_init. I assume this is how we handle POST parameters. All the docs I read didn't differentiate between GET and POST. I found out the hard way that GET parameters were always available to the app, while POST had to be handled with kid gloves. Any wisdom regarding POST and best practices would be greatly appreciated. I simply do the following: For normal name/value pairs there is no difference between GET and POST params when handling them in your application. You can get both from $self-query-param(). Something else is wrong with your application. -- Michael Peters Plus Three, LP # 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 + javascript + http server + icons
Arsen Hayrapetyan wrote: When I am running my application, it does not see the image files. Firefox plugin shows that the following file is requested: * URL_base/cgi-bin/app-images/bullet.gif* I.e., my application sees *cgi-bin* instead of *htdocs*. This is an apache configuration issue not really related to C::A. You might get more help on an apache specific mailing list. But just for kicks, what does you httpd.conf file look like? I tried also other ways of referring to the image files in js code, such as: */app-images/bullet.gif*,* htdocs/app-images/bullet.gif*, but none of them worked. If your document root is in htdocs/ then that's where all of your media assets belong (image files, css, js and .html). And you reference it without mentioning the document root using an absolute path (like /images/bullet.gif). This should work and if it isn't then something's amiss in your apache configuration. Putting the images under *cgi-bin* (bad idea by itself) didn't work also, as httpd server recognised the image files as scripts and tried to execute them. That's probably because you have it set up to execute anything in cgi-bin/ which is probably not what you want anyway. -- Michael Peters Plus Three, LP # 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] Benchmark of CGI::Application, HTTP::Engine, Catalyst, Mojo and others when used in a CGI environment.
Mark Stosberg wrote: No big surprises, but perhaps interesting to take a look Well, I think it goes to show all those people using CGI::Simple just to save .2M and .03s are wasting their time :) -- Michael Peters Plus Three, LP # 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] Benchmark of CGI::Application, HTTP::Engine, Catalyst, Mojo and others when used in a CGI environment.
Michael Peters wrote: No big surprises, but perhaps interesting to take a look Another surprise for me is that Titanium has a startup time of .14s where C::A has .21s. Isn't Titanium just C::A under the hood? How can it be faster? Also you don't mention how many times you ran each benchmark and whether you averaged those times. It's possible that OS caching of files, etc could help Titanium startup faster if it was 2nd and both were run only once. -- Michael Peters Plus Three, LP # 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] cached DBI connections with cgiapp/fastcgi
Benjamin Hitz wrote: So - I hope this is a useful summary for people who are still trying this - and also I am hoping that someone has some insight on why my $dbh goes stale. It was my understanding that $self-dbh_config would reconnect if the handle went bad but probably I am misunderstanding something. It will probably reconnect if the handle isn't there. But not if it goes bad. I don't know for sure since I don't use that plugin. But it's a common problem when dealing with persistant DB connections. If you want to see how mod_perl folks handle, take a look at Apache::DBI. Look at it's connect() method and particularly how it uses ping(). A lot of it is magic so things just work under mod_perl and so you don't need to wrap your DBI calls. You could make a similar FastCGI::DBI module if you wanted to (and put it on CPAN so others can use it too), or just wrap all of your DBI-connect calls with something like this. It's not trivial to get it 100% correct and if you weren't using Oracle (which has such a high cost for creating connections) and instead using PostgreSQL or MySQL then I'd say don't bother. But since you are using Oracle it's probably worth doing. -- Michael Peters Plus Three, LP # 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: utf8 form processing
Mike Tonks wrote: Yes I tries the -utf8 switch for the CGI module, and while it didn't break the code in any way, it simply didn't seem to do anything. How were you doing this? Since CGI::Application loads CGI.pm by itself if your loading comes after that it won't override what was already done. Since you were using require it's quite possible that your -utf8 flagged was ignored since CGI.pm had already been loaded by C::A I did wonder if it could be the use of require instead of use, but I don't really understand the difference and / or how this affects C::A. Not to be too mean, but this is a pretty fundamental thing to understand. use == compile time require == run time This means that when you say use CGI it happens as soon as perl *parses* that statement. When you say require CGI it happens as soon as perl *executes* that statement. If you're using CGI on every request then there's no reason to do it via require. In fact unless you're conditionally loading a module there's no reason (unless you're doing something sufficiently magical) to use require it. -- Michael Peters Plus Three, LP # 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] [OT] Anyone using JSON::XS to output to a web page?
Peter Karman wrote: I believe using eval directly has security issues. Only if you don't trust your data source. If you control the JSON coming in, then it's not a problem to use eval, and in fact, it's much faster. But if you don't control the data source, then yes use something else. In this case it sounds like the OP controls his data source since he's having problems sending it. -- Michael Peters Plus Three, LP # 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] ($self vs $c) was: Re: New Plugin: RunmodeDeclare
Richard Jones wrote: Actually prefer $c these days as a) it's shorter and therefore quicker and less easy to mis-spell (I seem to type slef more often than self), but more importantly, having done a lot of work with Catalyst recently, that's the Cat standard also, so it's familiar to me. This actually came up in our discussions and we thought it would cause more confusion since in Catalyst the $c is not $self. It's a different object entirely. So calling it $c in C::A land might confuse the catalyst folks since it's really $self just shorter. Also, for folks playing with Titanium (which btw, does not have a friendly abbreviation :) do you plan on still using $c? Or will you go with $t? -- Michael Peters Plus Three, LP # 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: New Plugin: RunmodeDeclare
Rhesa Rozendaal wrote: As for the order in which arguments are fetched, I don't mind swapping $self-param and $q-param in the fallback order. I don't have a practical use case either way. I only use $self-param in this context when CA::Dispatch puts url components there. I thought you might sometimes want to override a url component with a form field, but I haven't seen that happen yet. This is actually a security problem with fetching in the order it does now. It's similar to the PHP bug where some config setting was turned on by default such that any query params automatically became real variables in your program. This was fine unless you used one of those variables for something else. This meant that anyone could craft a URL which would override a variable in your program. Nasty things can happen. -- Michael Peters Plus Three, LP # 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] Model design in C::A/Titanium
Joshua Miller wrote: Using autoloader to only require in the subclasses when needed will also keep memory usage down, as rarely used modules won't get loaded unless they're actually called. Are you running under normal CGI (do people still do that?). If not, and you're running on a good OS (one with copy-on-write memory) and you're using a forking environment (mod_perl, or most FastCGI implementations) you should pre-load all of you modules up front. This will actually decrease memory usage. Or course if you have a really, really rarely used module that is really, really big you might reconsider this advice. Unless I'm missing something? -- Michael Peters Plus Three, LP # 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 practice for CGI errors
Mark Knoop wrote: If one wants to return an error to the client because they have not included the correct parameters for the CGI request, should one use one of the HTTP status codes and if so which one? Generally I don't use the HTTP status codes unless there is an error on the HTTP level. So for HTTP redirection, general server problem, etc. But HTTP codes are not application specific codes. And then is it ok/sensible to include an error message in the body? For me application specific codes should be part of the application, so it's part of the response. Are you returning your response as structured data (XML, JSON, etc)? If so, I'd just define a part of the spec that lists your application specific error codes and what they mean. If your response is not structured data, then just put a human readable error in the response. -- Michael Peters Plus Three, LP # 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 practice for CGI errors
Mark Knoop wrote: ...while I am here (and acknowledging that this is slightly off topic but at the same time it is probably somehting that many of you have had much experience in 'real-world' scenarios) can I ask whether CGI::App users have any favourite ways to do it re 'web services' ie remote methods/apis that do something then return some data? SOAP, XML-RPC, bespoke XML/JSON/other in response to GET/POST with CGI params, any other approach? My methods and responses are very simple. For simplicity (speed, human readability, etc) you can't beat JSON. I love it. And if you allow some JSONP you can make it easy for people to use your service to build mashups. You can have your clients make submissions that are simple requests with a JSON document as part of the request or you can use normal CGI style parameters. Really up to you. I'd avoid SOAP if I were you. It's overly complex and there are a lots of different variations. Compatibility between systems is not given and can be a real big headache. It would be nice to have hassle free security already there - this was the one advantage to SOAP - the main disadvantage being a lack of understanding on my part... I could be completely wrong, but I don't see how SOAP provide security to your application? You still need to implement whatever security scheme you decide on and you can always use SOAP's basic security model for your own application if you want. But as far as security in web services goes I've had good success with the following: 1) username and passwords. Treat it just like other web stuff. The only difference is that you don't really use a cookie, you just make them send the username and password on every request. 2) crytographic token. Very similar to #1 but instead of passing a username and pw with each request it's just a simple token. You'd give each client a separate token which you can then verify on each request. You can also embed data into the token itself like client id, etc. You can even embed something like the origin IP address in there so that client can't give your tokens away to other people. -- Michael Peters Plus Three, LP # 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] ::Server vs ::Dispatch::Server: Worth having both?
Bradley C Bailey wrote: In CAD::Server it tries to serve files staticly first before sending to dispatch. I think the best solution would be to specify a way to mark an entry point in the CA::Server config to specify static content. This would also improve performance since static content is more common than non-static (each non-static page probably links to at least a dozen static files). -- Michael Peters Plus Three, LP # 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/ ## ####
