|
|
Posted by JDS on 04/17/06 23:02
On Mon, 17 Apr 2006 12:28:10 -0700, Debbie wrote:
> If the string arrives with no data for the submit button, then my
> custom code would know that it must have been the submit button that
> was pressed, not the reset button. There is no ambiguity in the data
> transmitted. Likewise, if the reset name/value pair is present then it
> can't have been the submit button being pressed: it must have been the
> reset button.
>
> I haven't read up on the issues regarding the enter key, which may
> explain why you'd need the name/value pair, but I know you certainly
> don't need a name for a submit button if it's the only button on the
> form.
Okay, now that makes sense. At least, the processing logic makes sense.
To me, however, and based on my experience, it is not a Good Idea(TM) --
apart from making sense or not.
Personally, I have found that it can be very hard to remember What You Are
Doing(TM) with respect to programing or scripting. I think that the logic
steps you discuss here can much more easily lead to losing track of What
Is Going On(TM) than can giving every form component a clearly
understandable name.
Personally, I try to give every variable, function, form component, etc.,
an easily recognizable name, and I am not afraid to make these names
rather long in the interest of clarity. I have been known to name things
like "process_the_form_component_for_submission_into_the_database()" or
"left_hand_navigation_component" rather than "process()" or "lhnc" or
similarly obtuse names.
My point is merely that even though you don't *need* a name, according to
your logic, you *should* use a name anyways.
Lastly, why are you even asking this question in the first place?
--
JDS | jeffrey@example.invalid
| http://www.newtnotes.com
DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/
Navigation:
[Reply to this message]
|