On Tue, 25 Nov 2003, Peter Foti wrote:
[color=blue]
> "David Pautler" <dp_bluegreen@yahoo.com> wrote in message
> news:266e2e09.0311251521.1cb8e214@posting.google.c om...[color=green]
> > I'm creating a web-based authoring tool where one form encompasses
> > several sections for editing. I'd like each section to have its own
> > reset button, so that use of that button affects only that section.[/color][/color]
The only real solution to this is a server-based one, IMHO.
Irrespective of whether you stay with the single form, or break it up
into parts and transfer the information between the parts, the only
way that can be made to work for everyone is by implementing it on the
server side.
Once that has been done, you might consider a more convenient option
for users who consent to execute javascript, but in a WWW context I'd
have to counsel you to design this as an option, rather than making it
an essential part of using the form.
[color=blue][color=green]
> > I can't find anything in the 4.0 spec about how to do this, and the
> > only mention in this group I found is from 1998 below (CERN blocked my
> > email to Alan).[/color][/color]
Sorry, I don't have control over that. But anyway, it's better to keep
the discussion in public here on usenet, except perhaps where you're
just trying to clarify a personal detail that would be unlikely to
interest other readers.
[color=blue][color=green]
> > I've tried wrapping each section in its own fieldset, but that had no
> > effect.[/color][/color]
Some of the best-organised form-and-script combinations are based on
having the server re-write the form, for example the server filling-in
the details that have been accepted so far, prompting the user for
something more, or showing where they have input something
unacceptable, and taking them on to the next stage.
If you have that sort of structure, then you can easily have a button
that submits to the server with a request to re-initialise a field,
and the server then write a new form. It isn't technically a "reset"
in the HTML forms sense, but from the user's point of view that is
essentially what it does.
Sure, I agree, server-side takes extra time to respond, and involves
server load, but at least it's under your own control in a way that
javascript never can be (think: version incompatibilities and bugs).
Quite apart from also working for users who got their fingers burned
by some malicious javascript, and resolved never to enable it again...
[color=blue]
> It's not possible with pure HTML only.[/color]
Well, in any case, a form is not of very much use in a WWW situation
without a server script to evaluate it. Most of the work of designing
a form really goes into designing the evaluation of what's submitted.
By comparison, the writing of a few HTML tags is fairly trivial, if I
might say so.
[color=blue]
> However, you could implement a
> Javascript solution, using an input with type="button".[/color]
You're jumping out of the frying pan into the fire here...
[color=blue]
> The onclick event would trigger some code that would walk through
> the items and clear them out, but even this approach requires that
> you know exactly what items you want to walk through. And of
> course, the down side is that it wont work for those people who have
> Javascript turned off.[/color]
Right. And worse, the implementation of the "button" element is not
good in general, and severely broken in MSIE (who have the affrontery
to state on their developers' page that the button element is in the
HTML4 standard, while saying nothing about the fact that what they
have implemented doesn't follow that standard.)[1]
So you might be well advised to limit the use of <button>s to
javascript-generated content (DHTML), where it can do its onclick
thing for the JS-enabled users while staying completely out of the way
for those who have JS off.
[color=blue]
> An alternate solution might be to split the form into 3 different pages.[/color]
Indeed; or just three different forms on the same page; but you still
need the server-side scripts to drive it, right?
NB the above was all just tentative. Without knowing more about what
is really supposed to happen, I couldn't start to make recommendations
about which kind of approach I'd want to follow in practice. But I
stand by my principle that there must be a (basic) working server-side
script behind it all, and any Javascript conveniences offered should
be optional extras.
hope this helps.
[1] at the foot of the page:
http://msdn.microsoft.com/workshop/a...cts/button.asp 
