Add isDirectory or isLeaf attribute to rdf:files datasource

RESOLVED FIXED in mozilla0.9.8

Status

--
enhancement
RESOLVED FIXED
17 years ago
3 months ago

People

(Reporter: pwilson, Assigned: tingley)

Tracking

Trunk
mozilla0.9.8

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
If you look at bug #76369 you will see that it is not currenlty possible to 
correctly display a directory tree using the rdf:files datasource. Directories 
and files appear in alphabetical name order. Instead, the directories should be 
sorted first, followed by the non-directories . What is required is some way to 
add isDirectory or isLeaf to the sorting criteria. Could they be added as 
attributes to the file datasource?

The correct sequence could then be obtained with:

<treecol  id="FilenameColumn" 
resource="http://home.netscape.com/NC-rdf#IsLeaf^http://home.netscape.com/NC-rdf
#Name" sortActive="true" sortDirection="ascending" persist="width"/>

Asssuming #Isleaf has values "true" or "false"
(Assignee)

Comment 1

17 years ago
confirm.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
(Assignee)

Comment 2

17 years ago
This is easy. -> me.
Assignee: waterson → tingley
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
(Assignee)

Comment 3

17 years ago
Created attachment 62089 [details] [diff] [review]
fix

Having the property arc to literal "true" or "false" strikes me as slightly
bogus, but for sorting it may be preferable to a "filetype" arc.  Anyways,
here's some code I wrote last night.
(Assignee)

Comment 4

17 years ago
Forgot to mention that the property added is |NC:IsDirectory| (seemed more
intuitive than |NC:Leaf|).

rjc, care to review?
Keywords: patch, review

Comment 5

17 years ago
In general, I disapprove of code that FORCES users to see all directories before
all files.  Remember: while some platforms do display items that way, other
platforms don't... so, its best to make it optional; give the user the default
for their platform, and allow them to change it if they prefer.

That said, Chase, your code looks fine, although if I'm reading the diff
correctly, the last code block... which should be for HasAssertion() {...} ...
doesn't appear to handle the negative case properly, that is:
    HasAssertion(fileWhichIsNotADirURL, kNC_IsDirectory, kLiteralFalse, PR_TRUE)
should return true.

That is, asking if a file is not a directory should also return true.
(Assignee)

Comment 6

17 years ago
Yeah, the HasAssertion() implementation currently screens out all queries for
negative assertions, so even if my block handled it right, the function would
still throw logic to the wind.

I can clean this up.

Comment 7

17 years ago
No, its not a negative assertion (in RDF-speak), it won't be skipped.  [Note the
PR_TRUE as the final parameter.]
(Assignee)

Comment 8

17 years ago
Comment on attachment 62089 [details] [diff] [review]
fix

oops, you're right, i misread that example.  new one tonight.
Attachment #62089 - Attachment is obsolete: true
(Assignee)

Comment 9

17 years ago
Created attachment 62201 [details] [diff] [review]
now with fewer logic bugs

thanks for catching this, rjc.
Comment on attachment 62201 [details] [diff] [review]
now with fewer logic bugs

r=rjc
Attachment #62201 - Flags: review+

Comment 11

17 years ago
Comment on attachment 62201 [details] [diff] [review]
now with fewer logic bugs

sr=waterson
Attachment #62201 - Flags: superreview+
(Assignee)

Comment 12

17 years ago
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 13

17 years ago
The IsDirectory property is working correctly. The sorting order provided by 
nc:IsDirectory^nc:Name puts the directories at the end of the listing (as true 
collates after false). The IsLeaf property is still required to establish the 
correct order where IsLeaf = (!IsDirectory). I.e. nc:IsLeaf^nc:Name would sort 
correctly.
The problem is that the current sorting facility does not give fine enough 
control over the ascending/descending order of multi-part sort keys.
(Assignee)

Comment 14

17 years ago
Oh crap, you're right.  The sort service lets you specify a primary and
secondary key property, but only one direction.  I had thought that the choice
between isDirectory and isLeaf was more or less arbitrary, but since you can't
sort the primary key one way and the secondary key another, it actually matters.

Hmm, I wonder if you could work around the problem by inserting a separator
between the directories and files, and then do a normal sort within the
divisions.  I'm not sure if that will fly, though.
(Reporter)

Comment 15

17 years ago
Two solutions:
1. Add IsLeaf
2. DirectorySort = int:0 if directory else int:1.
Question: what happens in other natural languages. Do boolean values get 
translated so that potentially the sort order could get reversed in some 
language? Pharsi, Hindi, Japanese - who knows? Solution 2 may be better.
(Assignee)

Comment 16

17 years ago
The RDF service doesn't understand "booleans" -- they're just a pair of strings
literals.  Since they're all low ASCII, I *think* they can be safely localized
without changing the sort order.  But that doesn't make this not cheesy.

The unlisted 3) option is allowing separate sort directions for primary and
secondary sort properties.  This might be overkill, though.
(Reporter)

Comment 17

17 years ago
Just a final comment:
The http://www.mozilla.org/rdf/doc/wrapper.xul document describes how to wrap an 
rdf datasource. I have not tried this yet but it looks straight forward to 
create a directorySort property from the isDirectory property. This can then be 
used to sort the rdf elements, The problem has a (very general) solution.
This technique should allow multi-key sorting or sorting based on some arbitrary 
function. 

Comment 18

16 years ago
tever is not RDF QA anymore
QA Contact: tever → nobody

Updated

3 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.