Closed Bug 79427 Opened 23 years ago Closed 23 years ago

java html dom api

Categories

(Core Graveyard :: Java APIs for DOM, enhancement, P1)

All
Linux
enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bsatterf, Assigned: edburns)

Details

Attachments

(3 files)

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
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
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?

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}
My latest attachment doesn't support ISINDEX.  I'm working on it.
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?
Looks good. ra=ashuk.
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.  
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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.
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?

yes, type={radio,checkbox}
Reopening, customer is requesting new functionality.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
a
Status: REOPENED → ASSIGNED
Severity: normal → enhancement
Priority: -- → P1
Hardware: PC → All
Ashu, can you please review my patch from today?
Looks good. ra=ashuk.
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
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: