Axel Hecht wrote:
Michael A Nachbaur schrieb:
I'm creating an nsIRDFInferDataSource object as per the recommendation of Axel Hecht (see http://xrl.us/ei89 for the discussion) over on the XPFE mailing list. This was an awesome recommendation because my application is much cleaner as a result. However, I'm having some problems implementing the nsIRDFDataSource interface that I was hoping to get some help on.
I'm using my datasource to drive XUL templates (not in threads this time), and while it works to a point, I have some strange issues I'm unable to debug.
Basically, I create one instance of my datasource for each other RDF datasource I inspect. This I then add to the composite datasource bound to a XUL template, and then rebuild the tree. I can see from my debugging code that the XUL template requests all the appropriate statements from my datasource. However, when I add a second datasource to the composite, the XUL template only queries up to a point the required statements.
XUL code: http://xrl.us/ei9d JavaScript for the interface: http://xrl.us/ei9e JavaScript for the RDF datasource: http://xrl.us/ei9f Log of the debugging output: http://xrl.us/ei9g Screenshot showing the problem: http://xrl.us/ei9h
The problem is really exhibited near the very end of the log output. In the test, I load the first file (file:///home/nachbaur/foaf.rdf). This loads successfully. Then I load the second file (in this instance, file:///home/nachbaur/projects/scampclient/install.rdf). The XUL template processes the necessary statements, but when it gets to the point where it calls GetTarget on the "Watch", "StatementCount" and "DataSourceType" predicates, it queries against the first datasource in the composite (the foaf.rdf object) and not the second.
Does anyone have any ideas as to why this might be? I suppose I'm implementing my GetTarget method incorrectly, but I don't know what is wrong. I apologize in advance for the verbosity of the above URLs...if anyone would like clarification on anything, please let me know.
This stuff is designed to have one infer datasource working on the composite datasource, triggered by a infer="rdfinspector".
I haven't seen this in any documentation anywhere. Looking at nsXULTemplateBuilder.cpp, it seems that the infer attribute specifies the contract ID that the template builder then uses to QI the datasource.
Now, what I think you're doing is giving each of your DSs in the composite ds its own infer DS, and of course, it will ask the first for a target from the template builder and bail there somewhere.
Yes, this is whats happening. In pseudo-code:
var ds1 = new RDFInspectorDataSource(url1); var ds2 = new RDFInspectorDataSource(url2); tree.database.AddDataSource(ds1); tree.database.AddDataSource(ds2);
However, since in the above pseudo-code, the GetTarget method is not returning any nodes for the requested arc, the composite datasource should AFAICT query the second datasource.
At least, it works for the "URI" arc, which is how the second item in the tree shows up at all. However, the other two arcs are not. The interesting thing here is that they are defined in the XUL template as bindings, whereas the URI is defined using a <triple/> element. I had considered changing my XUL template to use all <triple/>s, but I wanted to solve the problem in my datasource rather than the symptom.
Not really sure how to solve this, but this is still an xpfe question to me, and not a xpcom one.
Well, looking at the requirements of my project, I actually don't strictly need to implement this as an nsIRDFInferDataSource, but rather I probably should just implement a standard nsIRDFDataSource object. In this case, the inference-specific XUL template code wouldn't really apply (at least, this is the way my code is turning out in any case).
Do you think because I'm implementing the nsIRDFInferDataSource interface, the XUL templates are behaving differently with my datasources?
Try a little more digging, I'm out for food.
Same here. I really appreciate your help. I would like to do my best to document what I find here as I work on this project, since there's a lot about some of the XPCOM interfaces that aren't yet. Therefore things like http://dev.mozref.com/reference/interfaces/nsIThread are in the works (though my stylesheets for XPCOM interfaces is very new)
-- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc _______________________________________________ Mozilla-xpcom mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-xpcom
