[Mozile] testing mozile 0.8: comments, questions and TODOs

[James A. Overton]

Thanks David,
	I'm assuming that your tests were under Firefox 1.5 and Mac OS 1.4.

On 2006-May-05, at 9:33 AM, david wrote:
...
> - BUG: clicking inside the editor, in the middle of the sentence to
> position the caret and start editing, the caret actually goes to the
> start of the line and editing starts there instead of where I clicked.
> If I doubleclick a word, editing starts at the end of the selection
> (should delete selected word and start editing).
This is Mozilla-only. The first click in the editable are leads to a  
mozile.edit.setStartus() call which turns on document.designMode.  
Only after that do you get a proper cursor. So a second click will  
make it work. Not sure how to fix this one yet.

> - BUG: insert a new row and press any letter on the keyboard: this
> triggers an error in mozile.event.handle "TypeError:
> selection.focusNode.insertData is not a function", but then the letter
> pressed actually gets inserted. The same error occurs when moving the
> caret to the end of a row using the mouse.
The "enter" key isn't supported yet by Mozile. We need support for  
operations like splitting and merging elements before it can be  
supported, which I'll be working on soon.

IMPORTANT: When Mozile doesn't handle an event, the event will pass  
through to the browser. So when something throws an error and then  
seems to work it's probably the browser that completes the operation.  
That's a bad thing, since the operation won't be undoable by Mozile.  
Just be aware that it works this way.

In this case a new BR tag is created and selected, and the  
mozile.edit.insertText command can't use Text.insertData on it.

> - BUG: when backspace-deleting I sometimes get the following in
> mozile.event.handle: "Exception... "Index or size is negative or  
> greater
> than the allowed amount: "1" nsresult "0x80530001
> (NS_ERROR_DOM_INDEX_SIZE_ERR)" location: "file:///Users/david/... ...
> .../mozile.js" Line:982". The error is thrown, but deletion  
> actually works.
This is one of those errors I see occasionally but haven't tracked  
down yet. I can't explain it, but it will have to be squashed.

> - Q: How is the RNG validation of the XML contents to actually  
> occur? Validation will take place at all data inserts (only node  
> creation I guess), right? So all the edit functions need to know  
> about schema and how to call for validation of the current fragment  
> (or do we have to do it on the full document?). In the current code  
> there is no such connection between editing and validation, right?
Good question. No validation is being done yet. Yes, node creation  
and removal will be validated, and only the current fragment will  
have to be validated. But the RNG system is already being used.  
Here's how it works (somewhat simplified for clarity):

All the events Mozile listens for pass through mozile.event.handle().  
That method determines the target element and checks to make sure  
it's editable. If the element is editable it enters a loop which  
starts with that element and climbs up through the element's parents  
until either the event gets handled or it runs out of editable  
ancestor elements.

At each step of this loop the mozile.edit.lookupRNG() method is  
called. It uses the name of the element to find a matching  
mozile.rng.Element object inside the current RNG schema. Then the  
mozile.rng.Element.handleEvent() method is called for that RNG  
Element object. The method takes the event and shows it to each of  
the commands associated with the RNG Element. Each command is given  
the chance to trigger itself based on the event information. If the  
command is triggered then the command will do its thing and the event  
will be canceled. If no command is triggered the loop will continue  
with the element's parent element.

The important thing is that commands are associated with  
mozile.rng.Element objects, and the RNG Elements get a chance to  
handle all the events which pass through the elements that match  
them. The RNG Elements know all about the structure that the matching  
elements are supposed to have: whether text is allowed, what  
attributes are allowed, what children are allowed, etc. (See  
mozile.edit.generateCommands() for the method which attaches commands  
to RNG Elements.) You'll also be able to add custom commands to the  
RNG Elements. So the RNG Element knows what commands should be  
available when editing a matching element. This is how we get really  
strong context sensitivity, and also how we can provide a lot of  
editing information simply by providing an RNG schema for whatever  
XML document we want to edit.

We aren't getting much benefit from that design yet, since only text  
editing is working. But after spending a lot of time thinking about  
this and prototyping, I'm convinced that this is the proper design.

> - Q: the schema selection is "mozile global", i.e. it is not  
> possible to have two editable <div/>s using different RNG schemas  
> (c.f. mozile.js, line 180, mozile.useSchema()). This might be fine  
> (for my purposes I believe it is), but might be a limit for other  
> people. Is there any easy way around this?
I agree that this feature should be supported. I'd rather not add in  
the extra complexity at this point, but I see no serious obstacles to  
adding it in the future.

> - Q: it is not clear to me how commands will be handled. On one  
> hand it would be logical to keep RNG Schemas and command  
> definitions together in some way. What are your thoughts on and  
> plans for the "lib" folder? the "lib/xhtml.rng" file does not seem  
> to be using "lib/xhtml/*", but one way of handling the  
> commands&schema thingy could be having a folder inside lib/ where  
> you'd put all RNG stuff as well as the commands definitions? (What  
> do I mean by "commands"? All the keyboard shortcuts and other  
> editing commands as well as some kind instructions on how to  
> present GUI/toolbar)
Commands are objects capable of making undoable changes to the  
document, and aware of the context in which those changes can be  
made. The commands will get all the information they need from the  
RNG schema. However, there will be ways to add extra information  
about Mozile commands to RNG files which only Mozile will understand  
and which other RNG tools will ignore (using a separate Mozile XML  
namespace). Details about things like keyboard shortcuts and toolbar  
button icons will be added in this way. This isn't supported yet, but  
I want to keep Mozile's extended RNG files separate from the original  
RNG files.

So I'm not sure how to lay out "lib" yet, but those are some things  
to consider.

> - Q: generic XML. I'd like to use mozile to edit generic XML. How  
> am I to instruct mozile about how to render these elements while  
> editing? Let's say I want to edit adressbook entries (as used in  
> the RNG tutorial). In the web page I put a div with mozile attached  
> to it. I create a RNG schema and instruct mozile to use it. What  
> will I see when I open the page? There will be a GUI permitting me  
> to insert a new adressbook entry, and while entering the data,  
> different commands permitting me to insert new elements will become  
> available in the GUI, e.g. creation of a <name/> element is  
> possible only when inside a <card/> element and the button (or  
> whatever) used to create an <email/> element will appear only if  
> there already is a <name/> element in the document... In other  
> words, there will have to be hooks linking the RNG schema to  
> commands and commands to the GUI. It sounds complicated and it  
> probably is... What are your vision for all this?
Note: Mozile will support generic XML, but I haven't started working  
on that yet. I expect problems because Mozilla and IE have very  
different ways of handling XML.

There isn't any interface code written yet, but I want to make that  
part of Mozile as separate from the rest as I can so that people will  
be able to experiment and find the best interface for their tasks. I  
want to have at least two different interfaces included with Mozile:  
a toolbar like 0.7 has, and a "sidebar" which is more like Kupu  
(http://kupu.oscom.org/demo/) or OpenOffice's styles palate.

The interface will be given the current node. It can look up the RNG  
Element associated with that node and get at all the commands  
associated with that RNG Element. It will then be able to ask the  
commands about their names, tooltips, icons, etc. A toolbar might  
only want to show editing commands for the current node, while a  
sidebar might want to provide commands for the current node and a few  
of its ancestors. A toolbar might use more dialogs, and a sidebar  
more inline textbox widgets.

Using the address book example, there will be commands which add a  
new card, which switch between RNG Choices like "name" and "givenName  
+ familyName", which allow you to add the optional "note", which let  
you set the email "preferredFormat" attribute to either "html" or  
"text", and so on. The interface just has to decide how to display  
them to the user.

The XML elements themselves can be styled with CSS. So you'll really  
need an RNG schema and a CSS file before you can edit the XML  
properly. CSS is limited, but there are some other more powerful  
possibilities: Under Mozilla you can do amazing things by using XBL  
to bind widgets to XML, and Microsoft's XAML may expose similar  
capabilities. David Kingma and I were discussing the possibility of  
using XSL to bind widgets in a similar way, which Xopus does  
(apparently; I don't know the details). All of that is for the future.

> Ok, I'll send this now before it gets too long!
I've gone on too long too, but they were good questions!

> btw: the code looks nice and is quite readable...
Thanks. I'll write some proper high-level documentation when things  
stabilize a bit. I'll do some JSDoc cleanup and the API docs at  
<http://mozile.mozdev.org/0.8/doc/jsdoc/index.html> today.

James