On the first hand, when you have only a hammer, everything looks like a nail.

  ...And maybe those objecting believe the task you've addressed is a screw (or maybe you do have other tools, readily at hand).

OTOH, when searching for wildlife in Kansas, you're not likely to succeed if you're focused solely on giraffes.

  ...But if you're hunting for giraffes, the objection to your focus misses the point that your "location" is probably ill-chosen.

So, on the proverbial third hand, you may be getting the "yeuchs" from folks who can't get past the "separate" meme (and, as this reply suggests, this 'umble pilgrim is NOT convinced that meme deserves the status of Gospel).

For my money, aside from my trivial concern (YMMV) about excessive indenting, (and without testing it, tho I don't see a problem, "off hand,") your sample is acceptable if it does the job.

Conveniently bypassing the whole code/design argument, the only thing I'd do differently is to factor out the repeated code bits (i.e., I'm Lazy about typing, as well.)

sub lbl {
    my $args = { -class => 'small', -for => $_[0] };
    label($args, $_[1]);
}

sub txt {
    my $name = shift;
    my $args = { -name => $name, -id => $name };
    %$args = (%$args, %{$_[0]}) if $_[0];
    textfield($args);
}
[download]

...which would make the invocations look like this:

# Instead of
# label({-class=>'small', -for=>'ff_job_id'},'FaultFinder ID')
lbl('ff_job_id','FaultFinder ID')

# Instead of
# textfield({-name=>'searchby_status',-id=>'searchby_status'})
txt('searchby_status')

# Instead of
#textfield({-name=>'searchby_date_start',-id=>'searchby_date_start',-o
+nchange=>"checkDate(this)"})
txt('searchby_date_start', {-onchange => 'checkDate(this)'})
[download]

It's just a nitpick, but I have A Thing about retyping code.

Update: changed the usage/syntax of "txt" to be more like the usage of CGI (i.e., used a hashref instead of an arrayref); keeping the interface the same is a better methodology and leads to less confusion.

-- 
Human history becomes more and more a race between education and catastrophe. -- HG Wells

I'm not sure of the question but if it's only CGI html methods versus heredocs ... I think I would vote for CGI html methods.

heredocs don't break when you update CGI.pm

hmmm ... good point ...

-derby

Believe me, I know that mixing logic/design is a bad thing, generally. I fully agree. But a) the powers that be don't like templating and b) this will never get redesigned once it's finished. It's a purely internal app for use by a test team.

A local app for local people, if that's not too locale-specific a reference :)

I'm a bit concerned by the "iieeek" aspect of your crossed out answer, though... is it really that bad to look at? I personally think it's better than big ugly blocks of HTML all over my lovely script :)

While it certainly breaks the logic/design separation ideal, so long as it works and can be modified if need be - (never say never) - and is acceptable within any other constraints then why not?

However, it doesn't have any dynamic variables in so it could simply be written as an HTML form. I assume it's encapsulated further with a start_html() ... end_html() somewhere?

There are no variables in that chunk, no. But that's just a random grab.

I've justified it to the guys here by pointing out that doing (for example)

table(
Tr(td(["c1","c2","c3"]))
)
## with better spacing and comments, of course
[download]


means you absolutely cannot forget to close a tag, so your output should be proper parseable XHTML.

Forgetting the whole separate design from code question, incidentally.

You can't really do that, being a programmer. It isn't so much a question of design/code, but of dynamic/static.

Stitching together static text dynamically via costly sub calls (yes, subroutine calls in perl are costly) every time you output the same chunk of data is unwise and inefficient, no matter whether your usage of the underlying module to do that is efficient or not.

Then there's the question of maintainability. Inserting another row of label/text fields is tedious at the same level as with plain html code, so nothing gained here either. I'd use at least a structure like

# Table data
my @rows = (
    ['FaultFinder ID',  [{ id => 'ff-job-id' }]      ],
    ['Username',        [{ id => 'searchby-user'}]   ],
    ['Status',          [{ id => 'searchby-status'}] ],
    ['Time',            [
                          {
                            id          => 'searchby-date-start',
                            label       => 'begin',
                            onchange    => 'checkDate(this)',
                          },
                          {
                            id          => 'searchby_date_end',
                            label       => 'end',
                            onchange    => 'checkDate(this)',
                          },
                        ]
    ],
    ['',                [
                          {
                            id          => 'right_submit_button',
                            type        => 'submit',
                            onmousedown => "checkForm('searchForm')",
                            value       => 'Go',
                          },
                          {
                            id          => 'submitted',
                            type        => 'hidden',
                            value       => 'get_existing_ff',
                          },
                        ]
    ]
);
[download]

to hold the relevant data, document that structure and organize my code to deal with that structure. That way if you ever were to insert a row containing e.g. a database identifier against which to run the search (or such), you haven't got to go through your code to find the right place, but just add an element to that array.

update:

The generating code could be in terms of CGI, or something else. I prefer HTML::Writer to produce templates or static HTML files.

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Sorry for the delay in replying. I've been a very busy WeeDom today!

The person who mentioned abstracting it off - yep,done that where possible.

Separating code/design being gospel, perhaps inappropriately - I agree. For internal webby tools it's not always worth the effort. But for a bigger web-project, particularly public-facing where design can become dated - always separate.

Indenting - I like indenting. Indenting is good, unless you're using a console-based editor where excessive indenting causes weird wrapping. But why would you? At the risk of getting flamed, there is always/almost-always a GUI alternative.

heredocs: hate 'em, hate 'em, hate 'em. Ugly things. But that's an opinion, not to be confused with a statement of fact.

My conclusion from all your comments (and thanks very much for participating in the discussion!) is that (apart from the buggy thing,and I've found the bugs and had to resort to quoted HTML to get around them) there's nothing wildly wrong with what I'm doing. My final justification is this - if you've absorbed the cost of compiling CGI.pm - why not use it? Why only use it for param() or Vars()?

Cheers,
WeeDom