Sundman has agreed to make a doc tutorial explaining that data-
binding to XML attributes will not be order-preserving. PhilR showed
that simply by adding a few column declarations, you can get a
predictable order. There is no need to change anything in grid, so
long as people understand this issue. (The test case should be
changed so that we don't get false hits for regressions.)
On 2007-01-27, at 15:02 EST, David Temkin wrote:
Adam may be right that this isn't very useful for serious
development, but the maximum-effect-for-minimum effort case is part
of today's system.. It is useful in early exploration and demos,
and those aspects are quite important.
If it can be retained by modifying the grid component, fine.
On Jan 27, 2007, at 10:59 AM, Adam Wolff wrote:
The grid component has a feature to automatically grovel over the
attributes of the first element in its data to create columns if
none are
given. This makes the trivial grid case where the column names are
the
attribute names, and the column order is unimportant, a 1 liner in
lzx. In
practical terms, it's probably not that useful and we could even
consider
retracting the feature.
This isn't a bug in the runtime. I could be considered a bug in
the grid
component. The design center of the original components was around
minimal
configuration for maximal effect. I think that makes for some nice
demos,
but it's not ultimately that useful (e.g. the window sizes-to-
content/
has-a-fixed-size switch that doubles its complexity.)
I think we should ship this way. If it really bothers you, we
could add
code to sort the column names in the inferColumns method of basegrid.
A
On Jan 26, Jim Grandy wrote:
So the grid component creates attributes under the covers when it
is binding
against a dataset? I'm still confused about how attributes enter
into the
picture here.
On Jan 26, 2007, at 3:57 PM, Philip Romanik wrote:
(Somebody correct me if I'm wrong) The attributes are in a hash
table and
the order they are processed is browser/platform dependent. It
appears as
though the hash table is built in reverse order in legals
compared to OL3
(and swf iterates on a hash table in a predictable order).
What behavior would you like to see? Is it sufficient for the
behavior of
legals/swf to match OL3, or does it need to match legals/dhtml
as well?
Thanks!
Phil
Are we sure it is order of attributes? This is order of data nodes
during binding.
Either way, don't think we can just close this bug -- it's a
significant change in behavior from OL3.
jim
On Jan 26, 2007, at 12:44 PM, Philip Romanik wrote:
Thanks Henry! I'm going to document this in the jira report and
close it.
Phil
The grid component depends on an ordering of attributes? That's
not gonna work...they don't have any defined order.
On 1/26/07, Philip Romanik
<<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
wrote:
Hi guys,
I'm looking into a jira bug
(<http://jira.openlaszlo.org/jira/browse/LPP-3379>http://
jira.openlaszlo.org/jira/browse/LPP-3379) where the display
order
is reversed between swf and dhtml. Is there anything I can do
about the
ordering? The behavior of dhtml matches v3.3 (it displays
data in
the order
it's listed). It is reversed in swf. Here's an app that
demonstrates it.
I think this issue came up a while back. Do either of you
remember?
Thanks!
Phil
<canvas debug="true">
<dataset name="weather">
<forecast>
<day label="TODAY"
imageurl=" http://www.srh.noaa.gov/ifps/text/images/
hi_shwrs70.jpg"
desc="Rain Likely" temp="Hi 60°F "/>
<day label="Tonight "
imageurl=" http://www.srh.noaa.gov/ifps/text/images/nwind.jpg";
desc="Breezy " temp="Lo 34°F "/>
</forecast>
</dataset>
<grid bgcolor0="0xAA0000" bgcolor1="0x880000"
datapath="weather:/" contentdatapath="forecast/
day" />
</canvas>
--
Henry Minsky
Software Architect
<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
![http://www.srh.noaa.gov/ifps/text/images/nwind.jpg"](http://www.srh.noaa.gov/ifps/text/images/nwind.jpg"){kind=link}