Status

Core Graveyard
Java APIs for DOM
P1
enhancement
RESOLVED FIXED
17 years ago
6 years ago

People

(Reporter: Brian Satterfield, Assigned: edburns)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
Ed,

per our telecon...

there are elements of the html dom that should be exposed to webclient (since
there are no plans to move forward with the api).  For instance, the method
getValue() on the interface org.w3c.dom.html.HTMLInputElement

the org.w3c.dom.html.* interfaces are currently all shipped with webclient.

Brian

Comment 1

17 years ago
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

17 years ago
I have an implementation for this that requires minimal code on my side.
Brian, please tell me if this meets your requirements.

Assumption: you already have some way of discovering which
org.w3c.dom.Node instances belong to the set of form elements your care
about, let's call it the special set, (1).

The fix I'm about to attach will allow you to call the existing
Node.{get,set}Value() methods on Node instances belonging to the special
set.  

(1).  I need to know up front, the complete and exhaustive HTML elements
in the special set.  I will be very loath to adding elements to this set
once we agree to it.  My answer to such a request will probably be:
"wait for blackConnect to come out".  So...here's your chance.
Currently, the only HTML elements in the special set are: INPUT,
TEXTAREA.  Are there others?
Status: NEW → ASSIGNED
(Assignee)

Comment 3

17 years ago
Created attachment 33952 [details] [diff] [review]
cvs diff -u of easy fix for this bug, first iteration
(Reporter)

Comment 4

17 years ago
I guess the short answer is "any element that a user can change or modify the
value of".

I went back to the HTML spec and found the following tags:

INPUT
BUTTON
OPTION <-- not 100% sure on this, basically looking for whatever node
type will contain the currently selected value (Ed?). There are also SELECT
and OPTGROUP tags but from what I can tell they don't provide that
information.
TEXTAREA

Ed, Henry...did I miss anything?

(Reporter)

Comment 5

17 years ago
we'd like to add ISINDEX for backward compatibility even though it's been
deprecated.

we're also unsure about the SELECT element.  If SELECT always holds the
currently selected value for an option list or option group then it would make
sense to add SELECT and remove OPTION.  However, I don't see an indication of
that in the HTML spec but javascript seems to work at that level when accessing
list values.

current list is {INPUT, BUTTON, SELECT, OPTION, ISINDEX, TEXTAREA}
(Assignee)

Comment 6

17 years ago
Created attachment 34127 [details] [diff] [review]
cvs diff -u of fix for this bug, second iteration, using macro
(Assignee)

Comment 7

17 years ago
My latest attachment doesn't support ISINDEX.  I'm working on it.
(Assignee)

Comment 8

17 years ago
Brian, after a little investigation, I can't see how to {get,set}Value from 
ISINDEX.  Can you ask JST about it and post to the bug?

Comment 9

17 years ago
Looks good. ra=ashuk.
(Reporter)

Comment 10

17 years ago
jst said there's no facility in the current api for getting the value of
ISINDEX.  So, I guess we'll have to do without it.  
(Assignee)

Comment 11

17 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 12

17 years ago
How easy/hard would it be to get this macro to work for {get,set}Checked()?

Reason being...that for radio buttons and checkboxes, just getting the value is
not enough information to know what a user has selected.
(Assignee)

Comment 13

17 years ago
Not hard.

Can you tell me how to differentiate between an INPUT that is a text field and 
an INPUT that is a radio button?  Do I ask for the value of the TYPE attribute?

(Reporter)

Comment 14

17 years ago
yes, type={radio,checkbox}
(Assignee)

Comment 15

17 years ago
Reopening, customer is requesting new functionality.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 16

17 years ago
a
Status: REOPENED → ASSIGNED
(Assignee)

Updated

17 years ago
Severity: normal → enhancement
Priority: -- → P1
Hardware: PC → All
(Assignee)

Comment 17

17 years ago
Created attachment 38016 [details] [diff] [review]
cvs diff -u of fix for this bug, takes changed requirements into account: RADIO and CHECKBOX
(Assignee)

Comment 18

17 years ago
Ashu, can you please review my patch from today?

Comment 19

17 years ago
Looks good. ra=ashuk.
(Assignee)

Comment 20

17 years ago
This checkin adds the following behavior:

On GetValue, if a checkbox or radio button, it returns "CHECKED" 
or "UNCHECKED".  

On SetValue, any string not equal to the empty string causes the checkbox
to be set.
FIX CHECKED IN.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
Component: Java APIs for DOM → Java APIs for DOM
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.