in reply to "roll your own" form generator

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

Replies are listed 'Best First'.
Re: Re: "roll your own" form generator
by geektron (Curate) on Jan 11, 2004 at 19:58 UTC
    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.

      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

        sounds like really big fun.

        this place is going to be a challenge in more ways that one. it's a 2-man shop ( a programmer/sysadmin and a designer ) where some things are Perl/mod_perl, some things are Java, other things are PHP, and, as noted earlier, no documentation.

      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