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

Hello o' wise ones!
I was reading some articles and tutorials on .NETs DataGrid object, and i said wow! thats kinda cool! And i wanted it for myself!

But i wanted it to do more, to make it more data driven.

Looking at how i have been coding recently, i have observed a few patterns.

I have a data object. A class, containing fields. These fields have types, restrictions, etc.
Now what do i generally do with this object?
1) I render it to screen (via html), in a variety of formats(a brief view, a detailed view, etc)
2) I validate the field data (max length, ensure they are ints and of proper ranges, ensure the email is typed the same in both fields, etc)
3) I edit the data object fields (some of them) via html forms
4) I load the data object from some persistant storage mechanism (mySQL)
5) I save the data object to some persistant storage
6) create perl scripts from the command line which also loads, validates and saves to/from the same data object. I use this for data cleaning, creating quick and dirty reports, etc.

After doing the above a few times, i have found that performing the above is quite tedious, error prone, and boring. Kind of reminds me of coding in C/C++.

I thought of creating some text file which describes the data fields, enough so that all the above operations can be performed, without writing any additional code.

so the only code you would need to code up would look like this...

my $object = new datagrid("myDataTextFile.txt");
$object->render();  # kicks out html form code
if ($object->isValid())
{
   $object->save();
}

as you can see, the code is kinda abstract, and isnt hard coded to your data. All the information regarding your data is in the text file supplied in the constructor. The text file would contain dbase field names, types, restriction info, rendering info, text descriptions, etc

by creating a generic datagrid perl class, i think all my needs could be met, making this boring task trivial! (i hope).

I was wondering, has this already been done? Please, tell me to download module XXX on CPAN, and that it does everything you wanted and more.

and if it hasnt been done, would anyone like to write one with me? Have suggestions? feature wishs?

I thank you for your time!
--rob

Replies are listed 'Best First'.
Re: DataGrid in Perl
by valdez (Monsignor) on May 26, 2004 at 13:36 UTC
Re: DataGrid in Perl
by Solo (Deacon) on May 26, 2004 at 11:39 UTC
    CGI::FormBuilder, CGI::Form, and WWW::Form come to mind as starting points.

    --Solo
    --
    You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
Re: DataGrid in Perl
by toma (Vicar) on May 26, 2004 at 15:21 UTC
    Data::Table covers much of this functionality. Remaining features could be added with inheritance.

    I wrote an article about how to use inheritance to add functionality to Data::Table, see Using Inheritance in Perl.

    Data::Table used to have some quirks that have since been fixed.

    It should work perfectly the first time! - toma
Re: DataGrid in Perl
by dimar (Curate) on May 26, 2004 at 18:14 UTC

    Hi robdog,

    Although I can't say I am perfectly clear on your specific requirements, this sounds at least roughly like a case where using a spreadsheet (ie MSFT Excel or OpenOffice Calc) would simplify your work.

    A spreadsheet makes it easy to: do mass changes; validate for valid integer, string, or other formatted data; process statistical metadata; sort and so forth. In other words it has most of the wheels that one would want to avoid re-inventing. (Unless part of the excercise is the enjoyment of do-it-yourself, which is a valid consideration).

    the hard part

    The main problem, of course, is how to map arbitrary text files of any arbitrary syntax format into the neatly-arranged cells of a spreadsheet, and then *back* out to the arbitrary text files, once you are done 'munging' them in the spreadsheet. I've written some apps that allow me to 'munge' multiple text files into and out of Excel, but it is pretty specific to my own work.

    I could not gather from your post: what language you are coding in; how you are persisting your objects; and whether you are directly manipulating text files. Therefore, your approach may be dissimilar from what I have done using spreadsheets.

    Nonetheless, this general type of problem solving seems like a productive path to consider, as it does simplify many tasks. Therefore I'd be interested in whatever you're able to find that addresses your needs.