Please don't use this module. It will be deleted eventually.
This module just saved me from insanity. I generally prefer to actually debug code rather than to stick glorified print statements all over my code. However when you need to peek inside code running in a server what else can you do? However this does a lot more than just give glorified print statements, and what it does it does well. For a start it is environment parameter controlled so may be if your test environment is set up so that the hooks need not carry across to production you can leave the stuff in place. Secondly there are a lot of associated plugins that provide logical and useful chunks of information.
I am sorry to say that in its current state I don't believe this module cuts the mustard. Real-world situations (for example XML sitemaps) require that one register a name space. This does not seem to allow that.
This solves a specific problem in that "eq" is not adequate for comparing JSON strings as a hash map one machine may JSONize differently on a different machine. So I don't really how anyone can write test scripts for JSON code without this. I was a bit annoyed at the function called "is_json". This is what you need to compare JSON strings but you would not know that from the name.
Invaluable tool and useful in the command line form especially. It's a shame it comes up with a lot of false positives (for example modules in the test area - even those that have skip logic in them).
Edit: I realize that is does support exclusions so you could make it one of your standard tests.
Yes it works. I'm not quite sure why module-starter does not include this by default.
I think it is such a shame that this module is not more widely known given that the problem it solves comes up so often. Excellent module.
I am finding this module invaluable for building medium sized websites - at least if you start from liking HTML::Template. I have to grumble however that I have found myself having to debug my way through it. I cannot pin point exactly what is going on here however. When I have discovered the problem, I have gone back to the documentation and found the issues explained quite adequately. So I suppose that that I simply found some of the conventions counter intuitive. Also a lot of the code is monolithic and poorly formatted - I think I must have spent half an hour working with one piece of code before I realized it was actually commented out. The most frustrating thing is that the "query" function has not been updated to keep up with the rest of the module. Because the "query" function had the old semantics and makes no allowance for the new conventions, was the reason I ended up needing to know the internals of these two modules.
Every module writer should use this. I can think of nothing more embarrassing than seeing one's spelling mistakes and typos in CPAN -- well I can think of more embarrassing things but I would be too embarrassed to describe them. It would be nice if it could see what spell checking programs were available and pick them in order of preference. Also some explanation of how to customize it for different languages (or if this is even necessary) would be nice.
Every module writer should use this module. There is nothing worse than uploading your beautiful module and seeing hundreds of test failures emailed back to you. My only complaint is that you actually have to temporarily edit the files to test with it. I rather suspect that there is no alternative but sadly I cannot give it 5/5 on ease of use on account of this.
I like the rebranding attempt and I like CGI::Application generally. However I guess this is a reasonable place to point out the results of a little experiment. I have a script that uses Titanium and HTML::Template. When I started using CGI::Simple instead of CGI, HTML::Template::Pro instead of HTML::Template and CGI::Application instead of Titanium the script speeded by 60%.
The documentation is appalling. The functions are not actually explained - you have to guess what they do or read the source code. An explanation of what "readable" is trying to do would be especially helpful. Also 99 open bugs is sort of scary. Apart from that it does what it says on the tin - it's just that the list of ingredients, countries of origin and healthy warnings, salt levels etc etc are missing.
Again I like this module. You can keep the password data (and its location) a long way away from the code by setting that as fixed parameters. By fixed parameters I mean using the features of CGI::Application::Dispatch to pass the parameters to the CGI::Application object. I cannot see any security downsides to this.
The previous reviewer just about got it right in my opinion. This is one of the best things about CGI::Application as far as I am concerned.
One gem that is worth mentioning is the "wildcard" rule and that use can rename the parameter that matches the wildcard. This is I feel very useful for building rules that handle multiple web pages.
I think it has to be admitted that this is a module for "hard core" or "old school" web developers rather than those who want to get up and running with the latest fad as quickly as possible. It offers the following advantages over new school approaches:
1.) It is sufficiently low-level that you can feel you really understand what is going on.
2.) It is very lightweight so it works well for shared hosted websites using suExec to protect the various clients from each other. (If I was writing a website for a large company on a dedicated server where mod_perl was available, I am not sure I could win a case for CGI::Application.)
3.) It works with a lot of modules and for every module that it works with there are one or two you could choose from.
The big disadvantages are as follows:
1.) There are a lot of details you need to deal with. Generating sitemaps for example.
2.) It is not clear which related modules are active and good.
3.) I don't believe that currently there is a good "model" component.
I am using this module and I like it but I can only give it three stars. I have the following criticisms:
1. Nowhere in the documentation for the more complex authentication methods is it clearly explained how you do the encryption.
2. We could do with more callbacks - I would like to be able to log successful and failed logins.
On the plus side the Dummy driver means you can easily set up all the visible stuff before you go onto the actual authentication. The generic driver saves the day because any monkey can at least set up a basic user/password system with that. I know it doesn't pass the highest security standards but horses for courses. There is a nice default login box (which as it happens totally clashed with my web-site's layout). Not a problem since only two options were required to change the style to fit in.
Overall I am both satsified and frustrated with this module - but it is marked as alpha software.
I like this module. It is simple to use and intuitive. It would be nice to see some performance comparisons against sprintf in the documentation however, as that could be fairly critical in some applications.