|Problems? Is your data what you think it is?|
Maypole: customising formsby matthewb (Curate)
|on Mar 06, 2005 at 12:21 UTC||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):
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:
...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.
...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:
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:
Any specific advice or general discussion on the area would, at the very least, make me feel less alone in all this.