[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: HTML forms
From:       Lars Knoll <Lars.Knoll () mpi-hd ! mpg ! de>
Date:       2000-04-11 11:35:09
[Download RAW message or body]

On Tue, 11 Apr 2000, Dirk A . Mueller wrote:

> On Mon, 10 Apr 2000, Waldo Bastian wrote:
> 
> > "inital value" as well. Shouldn't the RenderFormElements store the "initial 
> > value" in addition to the actual "value"? 
> 
> Yes and no.  when ::attach()'ing a Render*FormElement the RenderFormElement
> should get it's default value set (TextArea and Select can't be handled that
> way because their default values are not known at that place) as current
> value. 
> 
> from that time on the Render*FormElements contain the current value and the
> HTMLInput*Elements contain the default value. retrieving the other is done
> by querying the object (both objects have pointers to each other). 

I think that was about what I proposed in my last mail.

> > Currently HTMLInputElement::setDefaultValue() and 
> > HTMLInputElement::setValue() both set the same thing.
> > 
> > The difference becomes visible when you "reset" the form. In that case the 
> > "initial values" are supposed to be used.
> 
> that's why the ::reset() functions in the render-tree set their state
> according to the attached object from the object-tree. 
> 
> I'm not yet completely sure how that behaviour needs to be redone for the
> Javascript support. JS should probably be able to both change
> the default value and the current value I think. or can JS only change
> current value?

The DOM (and thus jscript too) support both. There is a 
HTMLInputElement::setValue() and a HTMLInputElement::setDefaultValue().
At the moment both act like a setDefaultValue() (as specified in the DOM
specs). That should be changed, but the fix is not too hard to do.

Just change HTMLInputElement::setValue(value) to call
impl->setValue(value), and add an
HTMLInputElementImpl::setValue() which sets the actual value in the 
rendering object.
Same for the retrieval function.

Cheers,
Lars


> > *hm* Something else: RenderTextArea calls reset() from within layout(). That 
> > means that resizing a page resets the textarea. (render_form.cpp:796) 
> > RenderSelect calls reset() and layout() from within close(). Should 
> > RenderTextArea do the same?
> 
> That's right. It's a left-over from older code. I'll fix it. 
> 
> > Trying to find my way in khtml :-)
> 
> If you're working on forms, could you please give me a quicknote on which
> areas you work on so that the work doesn't get duplicated?
> 
> There are quite some things still to do: 
> 
> a) DHTML bindings (::blur(), onClick() etc etc)
> b) supporting more form elements (input file, hierarchical select, HTML4
>     BUTTON)
> the last one is a bit complicated because I need to make it act just like a
> normal block element with inline childs.  
> c) CSS support (overwriting widget sizes, setting/storing/retrieving the
> widget colors)
> d) remaining layouting issues 
> 
> BTW, the http cache is still terrible broken. Do you intend to fix it?
> 
>  
> Dirk
> 
> 

-- 
Lars Knoll                                 knoll@mpi-hd.mpg.de
  PGP pub key [6DADF3D5]: finger knoll@pluto.mpi-hd.mpg.de 

[prev in list] [next in list] [prev in thread] [next in thread]