Re: Revisiting the persisting of attributes on thecombo_box widget

How about we just put a srcNode member in any widget instance,
which is its constructor node?

If you just want to deal with the attributes in the original inline
constructor (including ones that are not html attributes),
then you can then do
    var val = my_widget.srcNode.getAttribute('some_att');
or
    var atts = my_widget.srcNode.attributes;
    val = atts['some_att'].nodeValue;

That is if your goal is just implement your own semantics, independent
of NW and independent of html.

The idea behind inline_copy_atts was to copy html attributes over
from srcNode to domNode. You are correct that in some widgets it
is probably not going to do the right thing, since it may
be some descendent of domNode that should really be getting it.
I don't have any great suggestions about that, which are generic.

-mda

Michael Flanagan wrote:

> Ok, I've finally sync'd my code tree w/ nw cvs head and have been 
> testing this change out.
> 
> The attributes are being coppied through to the domNode property on 
> every NW_componentObj. This isn't always the visible or active on-screen 
> component.
> 
> For instance, if you copy through the tabindex attribute and we're 
> dealing with an instance of a combo_box_widget, that's not going to help 
> put focus into the input box which is the main visual component of the 
> widget.
> 
> We almost need the ability to specify the target for where the attribute 
> should be coppied to (ie. active onscreen component / container / etc).
> 
> I would still like to have a getAttribute() and setAttribute() method on 
> every nw_ComponentObj. That way I can do 
> nwAppId.getAttribute("table_name") and/or 
> nwAppId.getAttribute("colum_name").
> 
> The current implementation actually adds the attribute to a dom node to 
> persist them. Do you feel there's somthing inherintly wrong with having 
> an attribute[] on every widget that would get accessed through a 
> getAttr/setAttr method? We could even have both mechanisms.
> 
> Although I don't need support for both methods, it's possible that 
> someone might actually want the attribute to be on the domNode vs. just 
> in an attributes array they could query. Having things in a attributes 
> array should be faster than having to query the domNode.getAttribute() too.
> 
> --Michael
> 
> Mark Anderson wrote:
> 
>> Ok, i've just checked this in to environ_core.js
>> Except it is NWconfig, not nwConfig. Don't ask :).
>>
>> We might think about removing the accesskey and tabindex from 
>> text_expander
>> and combo_box widgets, and just make the default value of 
>> inline_copy_atts
>> to be ['accesskey', 'tabindex'].
>>
>> Note that nothing here does anything about widgets created 
>> programmatically;
>> this feature is only for inline constructors.
>>
>> -mda
> 
> 
> 
> 
> _______________________________________________
> The netWindows developers list: [email protected]
> http://netwindows.org/mailman/listinfo/devel_netwindows.org


_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org