The most confusing scenario I've found that occurs a lot (for me, anyway,
depends on the kinds of pages you build) is where there's a check box on the
page that should be initialized to "checked" the first time the person gets
to the page, and obviously preserve the value if they submit the page and it
reloads with whatever calculation/result.
The trouble is that there's no good way of knowing if they submitted the
form with the checkbox unchecked, or if they just loaded the page for the
first time, since in both cases there's no item being passed for it. But in
one case, it should be considered checked (first visit) in the other case,
unchecked (explicitly submitted unchecked).
Picture it as a GET, with nothing but a checkbox to control, say, level of
detail of the data displayed. The checkbox is "summary", which should be
the default state... checked.
So the first time you get there, the URL is:
http://mysite/infopage.cgi
You want it to show summary information, and the checkbox should be checked.
Now if the user leaves the checkbox checked, and submits the form, the URL
will look like:
http://mysite/infopage.cgi?summary=1
And the back end should render exactly the same data (presumably with
updated data, perhaps it's a log viewer or something)
If the user *un*checks the checkbox, and submits the form, the URL would
again show up as
http://mysite/infopage.cgi
But this time, it means that they wanted details, and so we need different
information.
I realize this sidesteps the question of "how does the form get submitted"
which is valid, since presumably there would be some kind of submit button
parameter on the query string, which could distinguish between "just got
here" and "submitted from the page", but I' trying to simplify the problem.
In a sufficiently modular system, I don't want to have to rely on some other
arbitrary cruft coming in on the request to be able to tell what state this
request is in. I should be able to look at one parameter and know where I
stand. At least that's my take on it.
Also, a simple semantic reversing of the meaning of the checkbox and label
would solve this problem neatly (label it "details", and then the default
state is unchecked), but you know how users/clients are... they want it just
so.
Hm, this has turned into a somewhat off-topic rant. I apologize. I just
happen to have had to deal with this again recently, so I thought I'd share.
And you're all the lucky beneficiaries :-)
thanks for your patience philipp
> -----Original Message-----
> From: Alex Brelsfoard [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 26, 2005 10:51 AM
> To: Philipp Hanes
> Cc: '[EMAIL PROTECTED]'; [email protected]
> Subject: RE: [Boston.pm] Empty radio and checkboxes not passed to perl
> scr ipt
>
>
> Thanks. It's good to know that someone else has noticed this oddity.
> Sad to say that mny of my user turn off javascript. So I'm
> am going to
> have to deal with this on the perl side.... I've created a script to
> build a hidden field for me that lists all the non-hidden
> form fields. So
> for the moment I will be using that. I also plan on creating
> a module for
> my script that will go to the requesting page and read the HTML and
> decipher all the appropriate fields. But this feature will have to be
> used sparingly. Just seems like a lot of work for something
> that should
> have been handled by the browsers.
>
> --Alex
>
> >> The following ideas are options I would _not_ like
> >> to follow if possible:
> >> - set a default checkbox or redio button (so something is
> >> always filled in).
> >> - use a hidden field to list of all the fields in the form.
> >> - have the perl script read the HTML code from the page and
> >> make its own list.
> >> - javascript
> >>
> >> I kinda understand why the browser doesn't send this
> >> information (no value
> >> to hold onto), but there HAS to be a solution for this.
> >> Seems frightfully
> >> stupid not to have an easy option out there for something
> like this.
> >
> > No solution other than the ones you mentioned, that I'm aware of.
> > What we've done is generally a hidden field that gets
> fiddled with via
> > JavaScript when the checkbox is changed. Then the back-end
> code just
> > looks
> > at the hidden field, and can be totally oblivious to what's
> really going
> > on
> > in the HTML.
> > Yup, seems stupid to me, each time I run into it again, too.
> > I'd be curious if someone has come up with something better.
> > Doubtful, though.
> > good luck philipp
> >
>
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
