use Perl

The first developer release of Titanium has now been
uploaded to CPAN and should be available shortly.

Titanium is a next generation web framework based on CGI::Application.
Titanium is designed to provide the underlying strength and flexibility of the
CGI::Application framework, while being more user-friendly to deploy and
develop with.

To this end, several useful plugins for CGI::Application are bundled by default
with CGI::Application and are documented directly in Titanium.

Several practices are specifically recommended and documented, such as using
URI dispatching, while details for alternative and advanced functionality for
CGI::Application are not included here. Those advanced docs remain available in
CGI::Application.

Several useful development and testing tools are installed along with Titanium as well.
Here's the full list modules that come with it:

CGI::Application::Dispatch
CGI::Application::Server
CGI::Application::Plugin::ConfigAuto
CGI::Application::Plugin::DBH
CGI::Application::Plugin::DebugScreen
CGI::Application::Plugin::DevPopup
CGI::Application::Plugin::ErrorPage
CGI::Application::Plugin::FillInForm
CGI::Application::Plugin::Forward
CGI::Application::Plugin::LogDispatch
CGI::Application::Plugin::Redirect
CGI::Application::Plugin::Session
CGI::Application::Plugin::Stream
CGI::Application::Plugin::ValidateRM
CGI::Application::Standard::Config
Module::Starter::Plugin::CGIApp
Test::WWW::Mechanize::CGIApp

my $a = my $b;

I've started using Google Code Search to turn up prior art.

In this case, I quickly discovered that, Yes, that's valid, and people are actually using it.

Remember to include lang:perl to restrict a search to Perl.

H.Merijn Brand, the Text::CSV_XS maintainer has been dicussing possibilities for adding parsing rows as hashrefs to that module through this RT ticket.

As fate would have it, our efforts to implement it crossed paths, and we now both have fairly complete but somewhat different patches for the feature. A couple points to get feedback on:

Which you do find clearer for setting the column names to use as the hash keys:


column_names()
or
hr_keys()


I have already been confused about whether "hr" stood for "header row" or "hashref", so I vote for the former.

The second point, which is currently in neither patch, is "how you design the interface to automatically setting the column names from the first row of the CSV?"

Parse::CSV uses new( fields => 'auto' ), but involving new() won't work for Text::CSV_XS.

I was thinking of perhaps:


$csv->column_names_from_line($io);


Which would simply mean:


$csv->column_names( $csv->getline($io) );


We would leave it up to documentation to make sure users called this first thing.

Alternately, you could have a function that stores the current file position, rewinds and reads the first row, and then returns to the current position. That seems more fragile to me, and I can oly imagine there are some non-rewindable filehandles out there for which it wouldn't work.

You can leave feedback here and/or in the RT ticket.

Thanks!

      Mark

I spent some time today learning some Haskell.

Here's an example of how I defined a function to perform addition in Haskell, and a second function that builds on the first to increment a number by one:


  add x y = x + y
  inc = add 1


The Haskell syntax here is especially compact and readable. In Perl, the same exercise would be much longer and noisier, as commonly written:


    sub add {
            my ($x,$y) = @_;
            return $x + $y;
    }

    sub inc {
            my $y = shift;
            return add(1,$y);
    }


(Yes, Perl could more even more terse, at the expense of readability)

Haskell provides further invisible benefits. If you give 'inc' too many arguments, or try to increment a character instead of a number, Haskell
helpfully dies with an error to tell you that you are attempting something that
doesn't make sense.

Perl will less helpfully ignore too many arguments, or pretend it can usefully
increment the character 'b'. In both cases, Perl "successfully" returns answers
of little use.

Keep in mind in that Pugs, an implementation of Perl 6, was written in Haskell, so I dare say Perl 6 shows some influence from Haskell.

Perhaps someone fluent in Perl 6 could leave a comment illustrating how Perl 6 could more elegantly these two simple functions. (Without using the built-in increment operator, of course! )

use.perl.org journals currently have very unfortunate <title> tags. Every journal entry I create has an <title> like

"journal of markjugg (123)".

It should really be something like:

"Witty Journal Title | markjugg's use.perl blog"

The current state of things reduces search engine rankings by not having the key words from the title in the tag, and produces pitiful entries in search engine results when you do find them, as seen here:

Even though the results are for specific journal entries, you just see:

Journal of sam (123)
Journal of mark (456)
Journal of foo (765)

Ugh. I've submitted a bug to Slashcode, if anyone is able to fix this.

I've now submitted a patch to T.J. Mather for HTML::FillInForm which overhauls the interface and docs to be simpler.

It boils down to two things:

1. You can skip the call to new().

2. You no longer have to declare what format your HTML or data is in, the module just figures it out. Gone are the days of trying to remember whether you needed "fdat" or "fdata", "fobj" or "fobject", "scalaref" or "scalarref"... you don't need any of them!

        In summary, this:

        my $fif = HTML::FillInForm->new;
        $fif->fill( scalarref => \$html, fdat => \%data );

        Has become:

        HTML::FillInForm->fill( \$html, \%data );


All the original syntax remains supported for backwards compatibility.

I'll try post another update once the final release happens.
i

A new module has been released for Data::FormValidator, Data::FormValidator::Constraints::MethodsFactory

For a quick overview, when I inherited maintenance of Data::FormValidator, it came with a ConstraintsFactory module. It has always seemed unwieldy, and I have hardly ever used and it mostly ignored it, despite being the current official maintainer of it.

For example, to express that you would like one constraint or another to be used, you would use:

make_or_constraint( $c1, $c2)

Where $c1 and $c2 are constraints.

Graham TerMarsch upgraded this whole system in two important ways with his module release. First, all of these factory methods are now "constraint methods", meaning that the constraint now has access to the Data::FormValidator object, allowing much greater flexibility.

Second, he fixed the unwieldy names that bothered me so much. So the above example would be expressed more directly as:

FV_or( $c1, $c2)

If you mean "or", you should just able to say "or"!. It's sort of a wart that it includes the "FV_" prefix, but that's consistent with other parts of DFV, so I think that's for the best.

Enjoy this new form validation tool!

        Mark

By looking at the guts of Catalyst, I found not one, but two modules that could be easily refactored out of Catalyst for shared use. Those are now File::Monitor::Simple, to monitor the application directory for changes, and HTTP::Server::Restarter to handle controlling that process and actually restarting the web server.

I also needed to patch HTTP::Server::Simple to have better signaling handling. But the result is that this now works:

    HTTP::Server::Restarter->monitor;
    HTTP::Server::Simple->new->run;

While there are options you can give to monitor(), the defaults should work fine for Catalyst and possibly others as well.

I'm currently in discussions with catalyst-dev to see about the best way to get this code published and the possibility of Catalyst being refactored to use the extracted modules as well.

The way that Catalyst currently handles this is a bit novel. Instead of sending and receiving a HUP signal, Catalyst sends a (non-standard) RESTART HTTP request from a user-agent to the server, with some some protection that this command comes from the localhost.

CGI::Application now has related tools as well, which builds on the work done by the Catalyst team. See CGI::Application::Dispatch::Server and Test::WWW::Mechanize::CGIApp, which both provide enough of a real web server to let you work on your CGI::Application project.

Jesse was just blogging offline web applications. For applications where it's feasible to share the web-code with the client, Perl's solution with Catalyst and CGI::Application has largely solved the problem, leaving only the database sync'ing issue to remain. Some kinds of database sync'ing are simply not practical-- Think of incrementing the a sequence value in both locations and trying to reconcile!-- but for other applications like PDAs, and groupware clients, we know from example there are feasible solutions.

I foresee more web developers using these techniques to deploy desktop applications that are really locally run websites with built-in webservers. It's not too difficult to envision a browser toolkit that provides an interface that looks more like a standalone application than a web browser.

I'm glad Catalyst has helped these tools evolved, but just as I was playing with these offline web servers, as I was reminded why I prefer CGI::Application: The default Catalyst application benchmarked with a virtual memory footprint of 17.4 megs, while an empty application with CGI::Application::Dispatch::Server application benchmarked at 8.8 megs-- almost half the memory usage! Now, that's not a "real world" comparison, but it does illustrate the different philosophies: CGI::Application is the center of more an à la carte framework, while Catalyst has more functionality built-in.