Multiple submit actions.

A

Alan J. Flavell

Alan J. Flavell said:
[...] I
find it well-tuned to producing the kind of HTML that's needed in and
around forms submission - which, after all, is what it's aiming at.

It would tend to break the separation-of-presentation principle,
though

I don't really see that, I'm afraid. If I'm generating structural
HTML with CGI.pm, I can apply a separate external stylesheet without
any kind of co-operation (nor interference, for that matter) from
CGI.pm.
(you'd have to refer back to your code to check if/where styles are
being applied on the input fields, for example).

If a style is being applied to unique elements of a specific form,
then I'd still prefer to simply name or id the element(s) in
question, and apply the style from a separated stylesheet, as a matter
of best practice. That way, re-styling is much simpler, without
needing any interference with the generated HTML.

(Of course that are also Q&D instances where I'd shove the styles
in-line, but my Q&D hacks are not really fit to be discussed in detail
here.)

I'm not saying that you're wrong; just that there are personal
preferences involved, and if the results fit the requirements then it
could just be a matter of personal preference how we get there. I
will of course concede that sometimes one starts on what seems to be a
simple problem using simple techniques, and later realises that one
has painted oneself into a corner, when a more-general approach may
have involved more work at the start, but produces a system that's
more easily extended and evolved. In that sense I accept that a well
thought out templating system rates to beat a solution which shovels
code and data into a single edifice.

(I mean to take some time to look at Gunnar's example before
commenting on that subthread. Apologies.)

all the best.
 
M

Matt Garrish

Alan J. Flavell said:
Alan J. Flavell said:
[...] I
find it well-tuned to producing the kind of HTML that's needed in and
around forms submission - which, after all, is what it's aiming at.

It would tend to break the separation-of-presentation principle,
though

I don't really see that, I'm afraid. If I'm generating structural
HTML with CGI.pm, I can apply a separate external stylesheet without
any kind of co-operation (nor interference, for that matter) from
CGI.pm.

I don't mean defining styles inline, per se. What I do mean is that the more
heavily you rely on CGI.pm to build the html, the more difficult it becomes
to maintain. There is always going to be some dynamic html generation
required when you're dynamically generating html, but again preference leads
me to minimize that as much as possible. Just as a quick example, I would
prefer to see this in my template:

<input type="text" name="username" class="inputfield" value="%% value here
%%" />

than something like this

%% username field here %%

In the latter you would have to refer to your code to see what class you
assigned to the field, etc. Again, I realize that inevitably you can't
always hope for something as nice as the former when dynamically generating
html, but forms do lend themselves nicely in most cases to that kind of
templating.

It also makes life easier, for example, when you have multiple people
working on a project. If your job is to write the code, and someone else's
to deal with the presentation (html + css), the more you can avoid
generating html in your code the better.

Matt
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,767
Messages
2,569,572
Members
45,045
Latest member
DRCM

Latest Threads

Top