This one really has me stumped. The problem can be expressed in two parts:
(1) Given a document, the document's serialized source code, and a DOM node in the document, locate the node's equivalent source code within the document's source code.
(2) Given a document, the document's serialized source code, and a DOM node's source code within the document's source code, locate the corresponding DOM node as a descendant of the document node.
I've only a few ideas on how to do this:
Any sort of help you could provide would be very useful. A solution would be critical for editing XML via source code in a DOM-based editor (like Verbosio).
Hm. It's interesting that Netscape breaks something that's already pretty broken to begin with...
XML data islands, anyone?
(Don't take this entry seriously.)
Yesterday, I discovered QueryInterface executing on my component for nsIClassInfo and nsISecurityCheckedComponent.
Under the nsIClassInfo IDL, the getInterfaces() section is a bit intimidating. But a sample in nsExtensionManager.js is really simple.
So from JS, we're passed an object as an argument. We set a property of that argument, value, to be the length of the array we're returning. We return the array as we normally would, and everything works.
I really ought to write some of this up for devmo. Thanks to #developers for the quick answer to my question.
If you're interested in taking a look at works-in-progress, and in giving me developer feedback, I'd like to include you in Verbosio's design. Currently I have a model which could work. Extensibility is the highest priority behind Verbosio's design, so if I'm creating costly design flaws, I need to know about them now. (Verbosio, for those who haven't been following along, is my prototype XML editor.)
I'm asking for three or four technical reviewers to take a look at my design and intentions, and offer feedback. The only reason I don't just post them publicly for review is the complete instability of Verbosio, including the IDL files I've designed. I really want to consult with a few interested people and get their feedback on what I should be doing.
Abacus failed because it was a one-man show. I am at the point where I need help just for sanity-checking of the design.
Please comment if you want a "first look" and are willing to offer active advice.
UPDATE: Just to give you a snapshot of what my thinking is, here's an overview of Verbosio as a concept.
Whether you like Netscape or not, they've been pretty good about releasing source code under the MPL. (Back in the day, they pretty much kicked off this whole open-source-for-the-masses party.) For Netscape 7, they had the source out within a couple days of the release.
I hope they do the same this time. Specifically, I hope I can see how they were able to embed IE into a XUL interface. I may or may not use NN8 (probably not), but that's something I think would be interesting to see.
At least, I hope they're still using a XUL interface.
Cenzic, Inc. has decided to lay me off on Friday. Therefore, I will be seeking employment in the very near future.
I'll be applying at a few companies immediately:
I'm a bit lacking on ideas for other companies that do active work with Mozilla products, so any suggestions you have, I'd gladly accept.
I haven't finished updating my resume yet, and I'm still trying to figure out how to write an appropriate cover letter (especially for e-mails). I prefer long-term employment, but short-term contracts on Mozilla work are better than some places I've worked before.
One other possibility is writing documentation. The biggest reason I haven't responded with any docs for Deb Richardson yet is the need to prepare for my employment search. So if you want to hire a docs writer, that's fine too. I enjoy that as much as I enjoy writing code. I've done it before...
UPDATE: I have completed an update to my resume.
If you read Planet Mozilla or MozillaZine, then you already know about XTech 2005 in Amsterdam of the Netherlands. You might not have heard about the O'Reilly European Open Source Convention 2005 taking place later that year in the same city. (I don't know the hotel.)
I strongly encourage any European Mozillians to try to get into this convention -- either by giving a tutorial or session, or by showing up. I've really enjoyed OSCON USA the last three years, and will be returning to Portland, Oregon this year.
I've flamed out on the last two blog posts I've made. Each time someone came up with a better idea. So this time, I'm just going to outright ask for help, and it won't need any fancy engineering.
Just some basic RDF+XML.
Specifically, I'm looking for a RDF file organizing the most basic data we have about XML languages: their namespace URI's, their most common prefixes, URI's of the specifications which define them, DTD locations, XML schema locations.
I really don't care if the list is incomplete. I just need something I can experiment with.
Google turns up several items titled "xmldiff", and a couple under "domdiff". What I'm wondering is, how could that be done through XPCOM and/or JS? Ditto for patching.
I've never seen it done before for a DOM tree. But if it were, you could very easily implement undo/redo between a source-text editing mode and a WYSIWYG or DOM-based editing mode. Think Mozilla Composer. (The diff between two versions of the same document is usually much smaller than the document in either version.)
One possibility: xmldiff has apparently been done in Python. PyXPCOM component, anyone?
I'd be really grateful if someone would step up and implement diff'ing and patching of DOM trees and/or XML source (preferably the former) as a XPCOM component under MPL tri-license. I don't want to do it myself, even though I'm trying to figure out how. (Node.isEqualNode hasn't been implemented yet in Mozilla, and probably wouldn't be a good basis. From the spec, it looks recursive through descendants.)
Requirement: When you generate a diff transformation sequence, it should be easily undoable and redoable. Look up nsITransaction.idl for a nice interface. (Most of the work I'm doing uses an extension of nsITransaction.)
There's one big problem with XUL applications which expect overlays: the application must define a way for overlay developers to identify their content elements. The id attribute of XUL elements is particularly troublesome. After all, anyone could have this:
<vbox id="contentBox"/>
So if you have that in your overlay, and I have a similar element in my overlay:
<textbox id="contentBox"/>
Immediately one of us has a problem. The application should have defined for us a way to avoid ID collisions like this. At the very least, it breaks the DOM's getElementById method.
A few days ago, I blogged about a JavaScript scope registry. I thought to myself, "if we have a unique scope id for the scripts, I can reuse that as an attribute in the overlay."
So instead of relying on a single ID attribute to identify an element, I can rely on a two-part key: a scopeid attribute on an ancestor element, and a localid attribute on the target node.
Thus, I present a simple function for getting a node by this combination key:
document.getElementByAttrKey = function byAttrKey(aScopeId, aLocalId) {
var scopeElements = document.getElementsByAttribute("scopeid", aScopeId);
if (!scopeElements)
return null;
for (var ptr = 0; ptr < scopeElements.length; ptr++) {
var list = scopeElements[ptr].getElementsByAttribute("localid", aLocalId);
if (!list)
continue;
return list[0];
}
return null;
}
It is probably more efficient to cache these nodes in a registry, though.
UPDATE: I love it when someone comes up with a cleaner solution than me. Thank you, Mr. Karel. Still, the premise (that id alone is not enough) holds.
The Star Trek: Enterprise finale didn't suck, at all. It (and the episode that preceded it) were really well-done.
They gave us Riker & Troi, in a nice touch. I only wish they'd given us those two on the Titan, after Nemesis. Oh, well. I guarantee you Jonathan Frakes didn't have those bags under his eyes in the time frame of the episode they wrapped it around.
The main story was touching, though.
Rick Berman: if you're reading this, maybe after your Star Trek hiatus, you'll resurrect one of the Great Bird's other interesting ideas and set it in whatever century you please. Where did Seven come from? (I don't mean Jeri Ryan.)
Four hours ago I sat down and started laying out a list of items Verbosio (my prototype XML editor) needs implemented to make it useful to people.
Right now, I have 26 things I've added to that list (for today).
Those are just the ones I brainstormed. Getting a working prototype could take a while. (One of the common operations is importing JSLib for file operations. For better or for worse, JSLib's file module works, and would be a nice standalone product from them. If there's a better way, I'll take it...) Also, bear in mind I'm doing this entirely in chrome, IDL and JS components. So there's no special back-end coding going on here.
But when I'm done, if I do everything on the checklist, it'll be one of the best-documented projects based on Mozilla you've ever seen...
I've done some thinking (and code design) on how I perceive a XML editor could work. Basically, I'm following the lines of a blog post I made last year. I'm hoping that if I provide an architecture, others will provide language-specific features.
I found glazou's latest article on this interesting, and I think he's working on a different aspect of the problem. For all I know, he may already have a working solution to what I'm doing. That's how much source code we've seen... (If you're reading this, glazou, don't take this as an attack on you... just a polite, light-hearted poke.)
I have a prototype architecture for such an editor, which I'm calling "Verbosio". (Because XML is verbose.) The primary goal of this project is to make it easy for other developers to insert their own language editors into this application. That is, to offer simple conversions of their own standalone editors into Verbosio extensions that do the real work.
To that end, I have six XPIDL files I've defined which describe the crux of this architecture. The simplest one I'm calling xeITransaction. All that does is extend nsITransaction with one property. That property identifies a XUL box overlaid in the Verbosio editor, which is basically a small form. Users fill in the blanks, bonk on the OK button, and the code executes a command based on the input. I don't define the form, you (the developer) do.
The other IDL files are really not much more complex than that... three out of the six IDL's have no methods defined at all.
So, with that said, who among you would spend their time making a XML language editor written in XUL/JS/XBL/CSS/etc. "fit" into Verbosio? The less work you have to do, I figure, the better. In most parts, I would hope all you'd have to do would be to copy & paste code from the original project into new files. I'd provide well-documented templates with instructions. (Verbosio will come with very minimal editing capabilities stand-alone... but the implementations of those capabilites are the templates I hope others will build from.)
If you'd be interested, please comment with the intended XML language, the project that's already out there, and your interest in directly contributing a port of the project. Verbosio as a project cannot succeed without external help and community interest. Please no "This would be a great idea!" comments unless you intend to actively contribute more than feedback.
UPDATE: I miscalculated on the xeITransaction interface above. I realized this evening that, as is, you as a developer would have to create either a new component class or new interface for every type of transaction. This is unacceptable, even to me writing the template extensions. So I'll be adding a setTransactionType method to xeITransaction.idl, and implementations of xeITransaction would then become more like a command library.
Anyone who does advanced JavaScript work is familiar with the concept of scope. It causes interesting problems, particularly if you want your script to work with someone else's. (Function names may be same, generating a strict warning... or variable names may be the same, resulting in complete silence...) This becomes especially annoying when you design your application to accept overlays from others...
Enter a little-known component called the JavaScript subscript loader. (I don't know the official name for it.) Many thanks to timeless for suggesting this component.
The beauty of this component isn't that it can load scripts for you... it's that you can give it a "scope" to play with. That scope can be a simple JavaScript object. (Omitting the second argument means it will use whatever scope it's being loaded from.)
Even better, these scope objects inherit functions & variables from the script that spawned them, but not from other scope objects.
Check this out:
var b = 4;
var url1 = "var a = 3; dump('url1:\\na: ' + typeof a + '\\nb: ' + typeof b + '\\n')"
url1 = "data:application/x-javascript," + encodeURIComponent(url1);
const jsLoader = Components.classes["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Components.interfaces.mozIJSSubScriptLoader);
var scopeObj1 = {};
jsLoader.loadSubScript(url1, scopeObj1);
var url2 = "dump('url2:\\na: ' + typeof a + '\\nb: ' + typeof b + '\\n')"
url2 = "data:application/x-javascript," + encodeURIComponent(url2);
var scopeObj2 = {};
jsLoader.loadSubScript(url2, scopeObj2);
function foo(evt) {
dump("main scope:\n");
dump("a: " + typeof a + "\n");
dump("scopeObj1.a: " + typeof scopeObj1.a + "\n");
}
window.addEventListener("load", foo, true);
This generates, in my console:
url1: a: number b: number url2: a: undefined b: number main scope: a: undefined scopeObj1.a: number
So, if you want your application to accept overlays, you just need a scope registry to prevent conflicts (mostly). Lo and behold:
const scopeRegistry = {
subscriptLoader: Components.classes["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Components.interfaces.mozIJSSubScriptLoader),
registeredScopes: {},
getScope: function getScope(aScopeId) {
if (typeof this.registeredScopes[aScopeId] == "undefined")
this.registeredScopes[aScopeId] = {};
return this.registeredScopes[aScopeId];
},
loadScriptByScope: function loadScriptByScope(aURL, aScopeId) {
if (aScopeId) {
var scopeObj = this.getScope(aScopeId);
this.subscriptLoader.loadSubScript(aURL, scopeObj);
} else {
this.subscriptLoader.loadSubScript(aURL);
}
}
}
I suppose I should have some try...catch blocks around the loadSubScript call. But if there's an error loading a script through this, we want to know about it!
Mozilla supports several XML languages now:
All things considered, that's quite a list. I'm just wondering: how could we build an editor in Mozilla that was flexible enough to switch from one language to another on the fly? (The problem I see is that there are language-specific editors, but not a central application you could add XML language packs to for editing.)
I myself have only a few ideas, but I'd like to hear yours as well. If we get a big enough list (complete with people who could code it), I may just start organizing a group of us together to work towards it. I'm talking anything from requirements to UI demos.
I just want to see what community feedback there is, and what we can do to lay some groundwork.
(I hope someone will remind me to ask the MozillaZine admins for a "whiteboard" wiki where I can display ideas you can edit. It would make this easier.)
UPDATE: Through the XUL:IDE page I was referenced to (sarcasm is appreciated :) ), I found a sample for IBM's compound editor. I didn't like the fact that you had to do some serious digging to select a XUL element to add... it would be better if they just displayed a menubar specific to XUL when in XUL editing mode.