I'm just curious on this one. An application I inherited at the new job is a big ( read: almost umwieldy ) piece of code with a web interface for creating "large database-driven forms" because, according to the owner of the (small) company, "programmers hate developing forms."

Maybe I've been spoiled a bit my taking advantage of Template::Toolkit's integration with CGI.pm, but I've never had an issue creating forms. A few database queries to get the defualt (already in the DB) values for a given form, to get the popup_menu() options, and pass it all into TT. Let CGI.pm handle the HTML for the form elements, like: 

[%  mycgi.popup_menu( 
    '-name'=>'areaIDs', 
    '-values' => AREAS.keys.nsort, 
    '-labels' => AREAS,
    '-default' => THIS_PAGE.area_id,
    '-multiple' => '1', 
    '-size' => '5' ) %]

[download]
And I'm done with a form element. If I need a handful of them, I still only have one line of code in the form to generate another element ( and maybe another query to get the info for that particular form element ).

So, am I just going about things "the long way?" Is there some real benefit to a custom-rolled, DB-driven form generator that's only used for DB-based forms?

Replies are listed 'Best First'.
Re: "roll your own" form generator
by CountZero (Bishop) on Jan 11, 2004 at 19:45 UTC
    Well, the benefit of a "custom"-job is that it is ... well ... customized to the job.

    If it works well, it probably works very well and can be fully optimised for the job at hand (much more so than a more generally useful application), but it is probably less good than such general applications if the particular circumstances for which it was written change.

    Then it can be hell to adapt it. And of course if you "inherit" it, you will have a learning curve ahead.

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]
      If it works well, it probably works very well and can be fully optimised for the job at hand
      see, that's the thing ... it *doesn't* ... at least not yet. there are way too many unimplemented methods at the moment. i have to perform deletes of an element in the DB, not via the web interface ....

      Well, the benefit of a "custom"-job is that it is ... well ... customized to the job.
      well, it's really not. it's a brute-force loop through query results and build an HTML::Template-based form with really bloated HTML that i'm surprised even really works ... weird ROWSPAN and COLSPAN settings on  <td>, very vague CSS support, and i could go on.

      (one of my pet peeves is bloated HTML ... excessively nested tables full of 'spacer' transparent GIFs where CSS padding/ margin would do the job, but i digress )

      and trust me, there's a learning curve. i blew 2 days using "the old version" of it, blew another almost day trying to get a form to do multiple things only to be told that "we don't use the tool for those", etc .... grr.

[reply]
[d/l]
        we don't use the tool for those

        Sounds like the IT-dept. in the company I'm working.

        When I suggested to use Perl for the generation of the dynamic webpages, they said "no, we are not going to learn another language". When asked what languages they do use, it turned out they did not use any general purpose language at all but a score of "tools" for all kinds of "tasks". At least I "corrupted" one of them to use PHP and I keep happily programming in Perl for my own pages on the corporate website :)

        Seems to me that the cost to maintain any level of proficiency in all these tools must be much higher than learning one real language. Well, I'm not part of the IT-dept, so the logic probably escapes me.

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]
        Well in that case it is not a good custom-job and one better forgets about it, unless of course the PHB really wants you to use it ... It's his time and money you will be spending.

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]
Re: "roll your own" form generator
by kutsu (Priest) on Jan 11, 2004 at 20:01 UTC

    A custom made form generator has many good qualities, such as being completely designed around a company. But I would recommend using the same methods you have been. The main reason for this is, in my experience, companies tend to change their mind alot, esp. about form layouts, and so having to make changes to a custom script that was doing things completely opposite of the way now wanted, may be more hassle then it's worth. Whereas, most modules are more general and thereby easier to adapt. Using your current method would also make it easier on those who must debug it later, but that might not be an issue at the moment. Either way, good luck.

    "Cogito cogito ergo cogito sum - I think that I think, therefore I think that I am." Ambrose Bierce

[reply]

Back to Meditations