container == false for empty RDF containers in RDF/XML or InMemoryDataSource

VERIFIED WORKSFORME

Status

()

defect
P3
normal
VERIFIED WORKSFORME
20 years ago
11 years ago

People

(Reporter: jgrroberts, Assigned: waterson)

Tracking

Trunk
x86
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

When I create an empty container in the InMemoryDataSource or through RDF/XML,
the xul template builder does not recognize that it is a container and sets the
container property to false.  This happens because the template relies on
nsIRDFDataSource::ArcLabelsOut semantics which are not supported for those
datasources.

According to the xul template reference, it appears the solution is to change
the implementation of the ArcLabelsOut function.  I may be able to this for my
own datasource, but I don't see how that is a practical solution in general.

I am also seeing a number of problems using the simplified treecell syntax
(setting value="something"), even after I add contents to my container.  I'm
guessing here, with no real evidence, but I think something is having trouble
with the transition from container="false" to container="true".

To see this, put the following into a file named emptyContainer.rdf, in a
bin/bugs subdirectory:

<?xml version="1.0"?>
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

  <rdf:Seq about="NC:EmptyContainerContainer">
    <rdf:li>

      <rdf:Seq about="NC:EmptyContainer">

        <!-- Look! I'm an empty container! -->

        <!-- XXX --->

      </rdf:Seq>

    </rdf:li>
  </rdf:Seq>
</rdf:RDF>


Now display with the following xul:

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>

<window
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

  <tree datasources="resource:/bugs/emptyContainer.rdf"
ref="NC:EmptyContainerContainer" flex="1">
    <template>
      <rule iscontainer="true">
        <treechildren>
          <treeitem uri="...">
            <treerow>
              <treecell indent="true" value="Bucket"/>
            </treerow>
          </treeitem>
        </treechildren>
      </rule>
      <rule>
        <treechildren>
          <treeitem uri="...">
            <treerow>
              <treecell indent="true" value="Apple"/>
            </treerow>
          </treeitem>
        </treechildren>
      </rule>
    </template>

    <treecol/>
  </tree>
</window>


Notice that the word "Apple" appears.  I believe you should see "Bucket".  Add
the following to the rdf file, where the XXX comment appears, and you will:

<rdf:li>
 <rdf:Description/>
</rdf:li>
Assignee: trudelle → waterson
reassigning to waterson for triage
I think the answer here is perhaps to mark "NC:EmptyContainer" as "#instanceOf"
"#container" in the RDF file, and in the template builder when deciding whether
an item is a container or not, check for that arc triplet along with the other
checks we do.
Status: NEW → ASSIGNED
Target Milestone: M11
bulldozer to M12
spam: changing qa contact from ckritzer -> paulmac for xul bugs
*** Bug 20590 has been marked as a duplicate of this bug. ***
Target Milestone: M13 → M14
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
*** Bug 29777 has been marked as a duplicate of this bug. ***
cc'ing myself. this seems to be the bug that addresses the 'can't paste/drag/add items in any way to rdf folders that are empty' 
problem.
Summary: container == false for emtpy RDF containers in RDF/XML or InMemoryDataSource → container == false for empty RDF containers in RDF/XML or InMemoryDataSource
*** Bug 33031 has been marked as a duplicate of this bug. ***
Target Milestone: M14 → M15
Target Milestone: M15 → M16
spam, open xptoolkit qa contact moving over to jrgm
QA Contact: paulmac → jrgm
*** Bug 35461 has been marked as a duplicate of this bug. ***
This WORKSFORME (I see "bucket"), if the comment lines are removed from the 
sample RDF file:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Seq about="NC:EmptyContainerContainer">
    <rdf:li>
      <rdf:Seq about="NC:EmptyContainer">
      </rdf:Seq>
    </rdf:li>
  </rdf:Seq>
</rdf:RDF>

I get well-formedness exception from expat otherwise:

XML Error in file 'file:///d:/bugs/14449.rdf', Line Number: 10, Col Number: 19, 
Description: not well-formed
Source Line:         <!-- XXX --->
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
N.B. that the template builder code has been whacked quite impressively over 
the last six months, so I'm not sure when this *really* got fixed :-). Man, six 
months. Sorry it took so long.
I just filed a new bug for this <A HREF="show_bug.cgi?id=36184">(bug 36184)</A>
but dark@c2i.net pointed out the duplication. This bug seems to have shown up
multiple times in the specific case of bookmark editing. Here are some useful
bits from my other report:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m15)
BuildID:    2000041705
Reproducible: Always
Steps to Reproduce:
1.open Manage Bookmarks dialogue	
2.create new bookmark folder
3.drag bookmark into new folder

Actual Results:  bookmark appears as a peer of the folder

Expected Results:  bookmark should appear inside folder

*** Bug 36184 has been marked as a duplicate of this bug. ***
No, I think they're different bugs. rjc: could you read the above and let me 
know?
reopening as this still happens with 2000041809 builds (never saw it work actually)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This really does work, I swear. :-)

You could verify this by copying-and-pasting the stuff below into separate .xul 
and .rdf files, but since I've already done that, I'll just attach them to the 
bug for ya...
To verify, save the above files to your hard drive in the same directory, and 
then open using "file->open".
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
ummm so this works brightly, brightly and with beauty on all platforms with the 2000041909 builds. Just to make sure i wasn't 
crazy I went back and checked and it definitely didn't work with the 2000041809 build, btw.

Marking VERIFIED
Status: RESOLVED → VERIFIED
*** Bug 40276 has been marked as a duplicate of this bug. ***
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.