Hrm, good point. I forgot about more complicated datapaths. I kinda
figured this wasn't the best approach, but I wanted to get some
feedback.
I'll check out your patch. Thanks. :)
On Nov 6, 2007, at 6:53 AM, André Bargull wrote:
Not approved!
The xpath-processing is a bit too simple. What about xpaths like:
"ds:/root/[EMAIL PROTECTED]'foo']/leaf" ?
I prefer a more simple xpath-processing, just like it's done in
"basegrid": wait for the "ondata"-event of the dataset!
I've attached another approach for this bug.
+ fixed nullpointer-bug in DHTML for "defaulttext"
+ removed my own comment ("local-dataset-modification by senshi")
and the debug-output
+ added temporarily a debug-warning for illegal indexes in
"basedatacombobox#_updateSelectionByIndex(..)"
Change 20071105-jcrowley-a by jcrowley at
DoctorManhattan.mshome.net <http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
> on 2007-11-05 14:07:01 EST
in /Users/jcrowley/src/svn/openlaszlo/trunk-g
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: Find source of basedatacombobox-based components
with selectfirst="false" emits Debugger warnings
New Features:
Bugs Fixed: LPP-4704 : Find source of basedatacombobox-based
components with selectfirst="false" emits Debugger
warnings
Technical Reviewer: henry
QA Reviewer: max
Doc Reviewer: (pending)
Documentation:
Release Notes:
Details: This is a workaround for an issue involving
xpathQuery() calls from an oninit handler.
Basedatacombobox kept getting "p is null"
warnings because it was requesting data
before the data was actually there, and because
it doesn't itself have a datapath, but rather
string attributes like "itemdatapath" that it
uses in xpathQuery() calls, I couldn't just
move things from oninit to ondata.
My solution, then, was to add a private
datapointer. The basedatacombobox sets the
datapointer's xpath to the first node of
itemdatapath, so that it's listening for at
least the initial data call. The ondata
handler for this datapointer then makes the
calls to the method that has the various
xpathQuery() calls that had been getting called
too early.
The "p is null" errors are expected in
situations where calls like this are made, but
we shouldn't be generating them from our own
base components.
I'm not sure if this is the best possible
solution, necessarily, but it fixes the
issues while not seeming to break anything.
Tests: The example attached to the bug. Notice there
are no "p is null" warnings. (You can compare
with an unmodified branch, if you'd like.)
Also, run:
test/components/base/lzunit-basedatacombobox.lzx
It operates as before, minus the "p is null"
warnings.
Files:
M lps/components/base/basedatacombobox.lzx
Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20071105-jcrowley-a.tar
--
Official OpenLaszlo-Committer ^_^
<patch.zip>
