O wise monkeys of the monastery...

I am in the process of evaluating Maypole (2.09) at the moment. As has previously been discussed, I find myself halfway between genuinely feeling that this can save me a lot of work by building on technologies I am already very familiar with and being genuinely frustrated.

I'd like to acknowledge at this point that I have not yet fully grasped the inner magic of Maypole. Perhaps notably the stuff in Maypole::Manual::Workflow

Specifically, I am stuck on the integration of Class::DBI::AsForm(2.41) and its attendant behaviour. From the documented description (emphasis mine):

This module helps to generate HTML forms for creating new database rows or editing existing rows. It maps column names in a database table to HTML form elements which fit the schema. Large text fields are turned into textareas, and fields with a has-a relationship to other Class::DBI tables are turned into select drop-downs populated with objects from the joined class.

Except they're not, at least not for me.

I have a column in my database table called resourceText, declared as a NOT NULL TEXT field. Having run into problems generating the forms I want in Maypole, I knocked up a quick test script to generate a hash from Class::DBI::AsForm's to_cgi() method and then use Data::Dumper to print the hash and see what it output. Here's the relevant bit (tidied up a little):

'resourcetext' => bless( {

  'name' => bless( {

    'name'    => 'resourceText',
    '_groups' => {

      'All'   => 1
    },
    'mutator'     => 'resourceText',
    'placeholder' => '?',
    'accessor'    => 'resourceText'
  }, 'Class::DBI::Column' ),

  '_tag' => 'input',
  'type' => 'text'     # I'm expecting 'textarea'
}, 'HTML::Element' ),
[download]

So what's all that about, then? Are the docs wrong or is it me? I figured that the next step was to take a look at the source for Class::DBI::AsForm. Mercifully, it's nicely laid out. The critical point where the output type decision is made is in the to_field method. I reproduce the bit I'm on about below:

# Right, have some of this!
eval "package $class; Class::DBI::Plugin::Type->import()";
my $type = $class->column_type($field);
return $self->_to_textarea($field)
  if $type
    and $type =~ /^(TEXT|BLOB)$/i;
return $self->_to_textfield($field);
[download]

...which looks fair enough to me. Next step, then, is to determine what Class::DBI::Plugin::Type(0.02) is returning for my columns that doesn't match /^(TEXT|BLOB)$/i.

print My::ClassName->column_type('resourceText'), $/;
[download]

...prints `blob' to my term. Well, I double-checked and I can tell you it's not. Taking a look at what Class::DBI::Plugin::Type is doing, I spotted this bit:

#if ($caller->isa("Class::DBI::mysql") and $caller->can("column_type")
+) {
#  return; # My work here is done
#}
[download]

Noting that if I uncommented this (since I am inheriting from Class::DBI::mysql) I could use the column_type() method in that package, which uses MySQL's DESCRIBE TABLE facility (I presume). Now it returns `text' but, either way, the result matches /^(TEXT|BLOB)$/. Readers should be aware that making this alteration will cause their Maypole app to fail under warnings with the following message: scriptname.cgi: Use of 'column_type' is deprecated at /path/to/lib/Class/DBI/AsForm.pm line 98. Use 'has_a' instead

Deciding that the solution was not forthcoming, I turned my attention again to the docs for Class::DBI::AsForm to confirm that one can use the to_field() method to modify the HTML::Element that is produced.

I also note that in the famous BeerDB example, this problem has been overcome. Indeed, I had the pleasure of watching Simon Cozens deliver his lightening talk on setting up this example at YAPC::Europe last year and I don't recall him having this problem.

Maypole::Manual::View mentions the possibility of modifying a hash called classmetadata to include a suitable HTML::Element on a per case basis. Presumably this is done via the to_field() method mentioned above.

I realise now that I've gone on a bit and the solution is almost certainly greater study but here's my current problem summarised:

• I want TEXT fields to be displayed as <textarea>s in Maypole forms
• Maypole depends upon Class::DBI::AsForm for form generation; a module that, while it does not work as expected (for me), allows you to override its decisions
• The Maypole docs confirm that this behaviour is available to the Maypole-based app developer
• But I'm unable to work out how

Any specific advice or general discussion on the area would, at the very least, make me feel less alone in all this.