I've been reading a lot of posts lately on the CGI::App mailing list about using CGI::Application::ValidateRM (RM == Run Mode); I finally went and checked it out.CGI::App::ValRM uses Data::FormValidator in order to do its magic. Interestingly, D::FV is built much like how I've buit our formHandlers library at work -- you specify a list of required fields, and a list of fields that need to be validated against criteria, then provide the criteria. It goes exactly how I would have done our libraries had we been working in perl -- supplying the constraint as a regexp or anonymous sub in a hashref for the field.
Anyways, it looks like the combination of CGI::App::ValRM with CGI::App could greatly simplify any form validations I need to do on the site, which will in turn make me very happy!
I had some success last night with the My::Portal CGI::Application superclass I'm building -- I actually got it working with CGI::Wiki::Simple (after I debugged the latter to fix some delegation issues!). Now that I know the "proof-of-concept" works, I'm ready to start in on some other issues.
The first issue is: how can I specify different directories for different applications to search for templates, while retaining the default directory so that the superclass can build the final page? I could always simply keep all templates in a single directory and simply prefix them, but that seems inelegant, somehow. I'll need to explore how HTML::Template integration works with CGI::App.
Second, and closely related: how do I want it to look, in the end? I could see keeping the design we have -- it's clean, simple, and yet somehow functionally elegant. Okay, I'm exaggerating -- it's your standard three-column with header and footer. But it goes with the idea of blocks of content. I need to think about that.
I saw a design idea for a WikiWikiWeb today, though, that totally changed my ideas of how a Wiki should look. I hadn't been to Wikipedia for some time, but a Google link to Gaston Julia showed up on Slashdot as it shut down a site in Australia, and so I visited it. I like the new design -- it separates out the common links needed into a nice left menu, and puts a subset of that at the top and bottom of the main column as well, using nice borders to visually separate things. I much prefer it to PhpWiki's default style, as well as to anything else I've really seen so far relating to Wiki layout.
So, I'm a bit of an idiot... it's been so long since I looked at CGI::App, and yet I felt I had such a grasp on it, that I overlooked the obvious step: look at the manual!
In particular, there's a whole series of methods that are used to tailor CGI:App to your particular needs, and these include cgiapp_init(), cgiapp_prerun(), and cgiapp_postrun().
In addition, you could specify in the superclass that you're using CGI::Simple for the query object (using the cgiapp_get_query method), or you could rewrite the load_tmpl() method to use Template::Toolkit or some other templating system, etc.
Doesn't look so crazy anymore...
I've been wanting to redevelop my home website for some time using CGI::Application. The last time I rewrote it from PHP to perl, I developed something that was basically a subset of the things CGI::App does, and those things weren't done nearly as well.
The problem I've been running into has to do with having sidebar content, and wanting to run basically a variety of applications. I want to have a WikiWikiWeb, a photo gallery, some mail forms, and an article database/blog; CGI::App-based modules for each of these all exist. But I want them all to utilize the same sidebar content, as well -- and that sidebar content may vary based on the user.
My interest got sparked by this node on Perl Monks. The author tells of an acquaintance who goes by the rule that a CGI::App should have 10-12 states at most; more than that, and you need to either break it apart or rethink your design. And all CGI::Apps inherit from a common superclass, so that they share the same DB connections, templates, etc.
So, I've been investigating this problem. One node on PM notes that his ISP uses CGI::App with hundreds of run modes spread across many applications; they created a module for session management and access control that calls use base CGI::Application; each aplication then calls use base Control, and they all automatically have that same session management and access, as well as CGI::Application.
Another node mentions the same thing, but gives a little more detail. That author writes a module per application, each inheriting from a super class: UserManager.pm, Survey.pm, RSS.pm, Search.pm, etc. You create an API for that super class, and each CGI::App utilizes that API to do its work.
This also seems to be the idea behind CheesePizza, a CGI::App-based framework for building applications. (All pizzas start out as cheese pizzas; you simply add ingredients.) The problem with that, though, is that I have to learn another framework on top of CGI::App, instead of intuiting my own.
But how do I write the superclass? Going back to the original node that sparked my interest, I found a later reply that described how you do this. The big key is that you override the print method -- this allows you to customize the output, and from here you could call functions that create your sidebar blocks, and output the content of the CGI::App you just called in a main content area of your template.
Grist for the mill...
One thing I've wondered about is the syntax of the robots.txt file, where it's placed, and how it's used. I've known that it is used to block spiders from accessing your site, but that's about it. I've had to look into it recently because we're offering free memberships at work, and we don't want them indexed by search engines. I've also wondered how we can exclude certain areas, such as where we collate our site statistics, from these engines.
As it turns out, it's really dead simple. Simply create a robots.txt file in your htmlroot, and the syntax is as follows:
User-agent: * Disallow: /path/ Disallow: /path/to/file
The User-agent can specify specific agents or the wildcard; there are so many spiders out there, it's probably safest to simply disallow all of them. The Disallow line should have only one path or name, but you can have multiple Disallow lines, so you can exclude any number of paths or files.