[Mozile] unsubscribe

[Jack C Crawford Jr]

"James A. Overton" <james at overton.ca> wrote:  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   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 element is 
> possible only when inside a element and the button (or 
> whatever) used to create an element will appear only if 
> there already is a 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 
today.

James
_______________________________________________
Mozile mailing list
Mozile at mozdev.org
http://mozdev.org/mailman/listinfo/mozile




IMPORTANT! my old email address, jack at crawfordia.com, IS NO LONGER VALID! Please change your address book to my new permanent address: JACK at JACKCRAWFORD.US
		
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mozdev.org/pipermail/mozile/attachments/20060505/0548f159/attachment-0001.htm