Subject: suggestions/opinions for inital displayed value, onChange?
Newsgroups: gmane.comp.web.dojo.devel
Date: 2007-09-14 02:43:52 GMT (1 year, 42 weeks, 16 hours and 55 minutes ago)
Hi all,
I want to get input about a few controversial dijit features/behaviors.
1. converting canonical value to displayed value on page load
For something like
<input dojoType=DateTextBox value="2006-06-07">
"value" is a canonical format use for initialization, sending the data,
and serialization/deserialization, different than the displayed value
(ex: 6/7/2006 in America).
Similarly for FilteringSelect there's a canonical value attribute:
<select dojoType=dijit.form.FilteringSelect
store=sqlServerStore
value="AZ"
></select>
which is different than the displayed value (in this example,
"Arizona"). But (assuming a client-server data store) this requires a
roundtrip to the server to convert "AZ" (the key) into "Arizona" (the
displayed value).
This is a nice clean design, especially given the idea of
serializing/deserializing forms, but of course has performance implications.
There are also issues with InlineEditBox but I've asked Doug to
rearchitect InlineEditBox (in particular deferring creation of the
editor until it's actually needed) so probably best not to think about
those for now.
Opinions?
Note that both Tree and Table widget (when we get it checked in) will
also require round trips to the server to display their initial data.
Eugene suggested a data-store enhancement to cache some values in the
initial page, like:
<div dojoType=MyFavoriteStore href=...>
<script type="dojo/method">
this.cache = { seed the cache with these values };
</script>
</div>
or maybe:
<div dojoType=CachedStore>
<div dojoType=MyFavoriteStore href=...></div>
<script type="dojo/method">
this.cache = { seed the cache with these values };
</script>
</div>
which seems like a good idea, although we need a good way to tell the
cache that "this is the result you will get from a given query" or
"these are the first 30 items that will be returned from this query".
--------
2. onChange
Currently, the onChange event for form widgets fires on page load (or in
the case of FilteringSelect, after it figures out it's initial display
value). This needs to be changed since most people expect onChange only
to fire when the value changes .
But should we make that configurable, and/or have a separate onLoad
event for widgets for when the displayed value is determined? (I guess
it relates to Q1).
Bill