Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Maypole: customising forms

by matthewb (Curate)
on Mar 06, 2005 at 12:21 UTC ( #437030=perlquestion: print w/replies, xml ) Need Help??

matthewb has asked for the wisdom of the Perl Monks concerning the following question:

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' ),

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);

...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'), $/;

...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 #}

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/ 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.


Replies are listed 'Best First'.
Re: Maypole: customising forms
by Scarborough (Hermit) on Mar 08, 2005 at 14:44 UTC
    I'm sorry to say I can't help on this one but I wonted to say thanks for openning up an area of research for me if Maypole does what it says I could have hundreds of uses for it. I will be watching this space with egar anticipation of some answers.
    Maybe I will catch up as I intend to download and tryout Maypole for myself.
    Thanks again.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://437030]
Approved by Corion
Front-paged by davidj
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (3)
As of 2020-09-24 09:42 GMT
Find Nodes?
    Voting Booth?
    If at first I donít succeed, I Ö

    Results (132 votes). Check out past polls.