Open
Bug 68306
Opened 24 years ago
Updated 6 years ago
Trees with remote RDF need to be rebuild in order to display correct data
Categories
(Core Graveyard :: RDF, defect)
Tracking
(Not tracked)
NEW
Future
People
(Reporter: mik, Unassigned)
Details
Attachments
(3 files)
Trees with remote RDF need to be rebuild in order to display correct data.
This means that when having a tree with remote datasource (HTTP, in
particuluar), attached to it, it is required to do
tree.builder.rebuild in order to show correct data.
In the attached case server return a little different tree each time, and
clicking reload button one can see empty lines in the tree.
Looks like during the reloading tree display correct data, but when reloading
ends it draws empty lines.
Build ID: 2001020820
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
Reporter | ||
Comment 3•24 years ago
|
||
Reporter | ||
Comment 4•24 years ago
|
||
I discovered the reason for such a behaviour:
Let's assume we have and RDF resource where titles of an items are changing.
So, titles are connected to nodes via assertion ....#title
When doing refresh of source nsIRDFRemoteDataSource issues a set of modification
on a data source.
The problem is in the order of assertions/unassertions.
Now, datasource first asserts new title, and then unasserts old one.
So, tree first displays new value, but then it receives unassert notification
and _removes_ corresponding line.
The first solution here can be to change the order of modification -- do
unassert first, and assert after.
Secound solution can be to do change instead of assert/unassert.
Updated•24 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.0
Comment 5•24 years ago
|
||
That sounds plausable. The relevant code is in nsInMemoryDataSource::Mark() and
nsInMemoryDataSource::Sweep(), if you want to beat me to looking at the bug. ;-)
Comment 6•24 years ago
|
||
...actually, thinking about it a bit more, I bet this is a bug with
nsXULTemplateBuilder.cpp. It should know better. (Ideally the
nsInMemoryDataSource would issue OnChange() notifications in the case you
describe, but the template builder shouldn't fall over if it doesn't get 'em
that way...)
Reporter | ||
Comment 7•24 years ago
|
||
Well, tis is acrtually two issues -- yes, trees should behave OK with such a
changes in the datasource, but also yes, datasource should do Change in such a
situation.
Both issues are very important for Mozilla The Platform.
BTW, making tree understand such a situations is not so easy.
Here we have a time terion when TWO titles exist at the same time, and this is
OK from the datasource point of view. What should tree do when it deals with
two titles?
Comment 8•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Updated•23 years ago
|
Target Milestone: mozilla1.0.1 → Future
Reporter | ||
Comment 9•22 years ago
|
||
Looks like new tree (outliner) behaves well without rebuild.
I'll try to check better this and also how <listbox> behaves.
Reporter | ||
Comment 10•22 years ago
|
||
Ops... This is still the case with both <outliner> and <listbox>.
It's still an issue...
Comment 12•21 years ago
|
||
waterson left the building
Assignee: waterson → nobody
Status: ASSIGNED → NEW
QA Contact: nobody → core.rdf
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•