We leave the Schema blank because we will be talking about DTD and Schema in later
chapters. The PO XML data comes from the W3C XML Schema Part 0: Primer. You can
put a copy of the data into the textarea by using the get sample selection list.
Actually the generator will guess a simple schema from the data, this
helps the generator to classify elements into simple type, attribute, complex content.
Since the check schema and conform to schema checkbox are not selected, the generated
schema does not affect the editing in any other way.
When we generate the form, we get the following. The forms in the rest of this page are generated using Mozilla and are mainly for display and not really "live". If you actually want to play around with it you should actually generate the form.
However, for some unknown reason in this document (and all following chapters) the fieldsets in the sample form are not displayed correctly in Mozilla (but it is OK on IE). It is mostly cosmetic and should not affect the documentation. The actual generated form would not have this problem.
The first thing in the form that is noticeably different from the basic data entry
mode is that there are lists in the top that acts as pull down menu.
If we ignore the menu the form is almost identical except for a +/- sign in legend of
the field set. Just like the browser display of XML data, "-" indicates that
you can collapse the display of the element, while "+" indicates that
you can expand the display of the element.
Notice that the reset button has been removed. It is not completely clear what reset means after extensive editing. Until we can come up with a clear guideline, we would leave it out.
The "Generate XML" submit button is also on the menu. The two are equivalent and you can use either one depending on your own preference.
This menu stays on the screen all the time even when the document is scrolled so it can
be accessible anytime. However because of CSS menu this is implemented differently
on IE and non-IE broswers. Visually they look slightly different, but functionally
they should behave the same.
This XML editor web application works on the same paradigm as most other desktop
application. You first select the element you want to operate on. You
then select an operation from the menu. To select an element, just click
on the element. The selected element will be indicated by a background color
of dark blue. The next form shows a selected element.
When the focus is on an input text field or textarea, the corresponding element is considered to be implicitly selected, even though the dark blue explicit selection is not shown. Select list or radio button could not be implicitly selected.
Sometimes selecting can be tricky when you are trying to select an attribute, or select an element without selecting the attributes. In such cases you may try to click on the label. Or easier yet, do an implicit selection by clicking on the input text field.
After the selection, you may operate on the selection. For example, expand and collapse are under the "operate on selection" menu. Of course, for such common operation you may not want to use the menu. A shortcut is available. Double click on a regular item would collapse it, while double click on a collapsed item would expand it.
Here is how a selection would look like. We also collapse some elements so you can see what they look like.
You may use Select List or Radio Buttons for the input. Currently when you
convert a text field to make select list or radio buttons, the program would go
through all the text fields and collect the values and use them as the choices.
Choices in select list or radio button also go to the collection. If you make
the select list at different times, it is possible to have different lists on different
fields because the choices reflect the data at the time the list is made. So if
you want consistency, you should make all the lists at the same time before you
change the data again.
Sometimes you want don't want to select any of the choices. You can do this by using the "Clear Selected Fields" menu command. Radio buttons will all be unchecked, and select list would have an new "**Undefined**" state. This choice will disappear as soon as one of the options is chosen.
Browser form would only submit radio buttons that are checked. This means that if a set of radio button is not checked, the element would not show up in XML. However, if you use text field or select list, the element would show up in XML as an empty element. This is something you have to be careful about.
You may repeat an operation on all elements of the same kind. In the example,
suppose you want to collapse all "member" elements. You can do that by first
clicking on the repeat operation, then select collapse from the menu (the
double click short cut cannot be used.) After the operation is completed (and
you did not cancel it), a confirmation dialog will ask you whether you want
to repeat the operation on similar elements. If you agree, then the rest of
the "member" elements will be collapsed.
This powerful feature may save you a lot of work.
Under the Create New Element menu, there are menu items for creating new complex element, new simple element and new attribute.
You can sort repeating elements. Suppose book and magazine are name of elements,
and you have some XML data that looks like this:
magazine book book book book magazine book book book magazine
You can either sort the four book elements or the three book elements. If you want to sort the four books, pick one of the four books and select a simple element or attribute inside that book element, then choose from the menu "Use as Key and Sort". Then you would be ask to confirm you are sorting "book". If you confirm the sorting would proceed. The repeat operation checkbox will be ignored.
Note that the key need not be attribute or child element of book. Suppose author is a child element of book, and author has attribute birth year and child elements first and last name. Then one of birth year, first name and last name can be use as the key. If in the other book elements, the key is missing or is not simple text string, then you will be warned, and elements with missing key will be put in the front. If the key occurs multiple times in the element, the first encountered one would be used. In the example, book may have multiple authors. If you pick a book with a single author and use his last name as the key, the books will be sorted by the last name of the first author. However if you pick a book with multiple authors and last name as the key, the editor would think that you are sorting the authors.
Currently key value is considered to be text strings and sort is in ascending order.
Some of these rules can be changed in the future.
Let us take the PO XML as an example, we would select the product name in the item.
You can write the content of this page as HTML into a new window with this command.
This sounds useless since it seems that you are getting more of the same. Indeed this
is unnecessary if the the browsers are doing the job properly. When you save a page
from the browser, most browsers with the exception of Mozilla just save the original
HTML source. With this XML editor, you may be making extensive addition and deletion of
HTML elements and the content may be very different from the HTML source. While Mozilla
is saving all the current elements, like other browsers it does not update the content
of the input fields. With this command you get HTML source that try to reflect the
actual current content of the web page. If you save this snap shot web page, when you
load it you should get back the same content.
The second reason you may want to use the command is that once you save the page, you can load back the page and use it again without using the form generator. If you have change some of you fields into selection list, and you have defined some new elements, they would all be there when you load back the page. So you can use this to save unfinished work. You can also use this to generate a template for a brand new XML document.
Currently this does not work with Safari. With Opera you would lose the stylesheet information unless they are in an external file.
For those who want to move around the XML document using the keyboard rather than the
mouse, they can use the cursor keys. There are many different ways to match different
functions with different keys, different combination are still be considered and fine tuned.
Therefor all these are subjected to change, and you are welcomed to give your opionion.
Currently, when a XML element is selected, the cursor keys has the following meaning:
The down arrow: move the selection to the current selection's next sibling.
The up arrow: move the selection to the current selection's previous sibling.
The left arrow: move the selection to the current selection's parent.
The right arrow: move the selection to the current selection's first child.
It is not difficult to visualize why the cursor keys are chosen this way. Siblings on above and below each other in this XML editor, so we use the up/down arrow key to get them. Children element are offset to the left, so use left arrow to get to the parent and right arrow to get the children.
However the other reverse choice also make sense. If we think of it as a tree with the root node on top, Then up arrow should get the parent and down arrow get the children, while the left/right arrows get the siblings. For now we stay with the physical layout of the editor.
For the purpose of cursor movement, attributes and elements are considered siblings. However an element with attributes but no child element is considered a single unit. So to access those attributes, you need to use the right arrow key to descend one level. To make it even more confusing, even when you are on a attribute, next sibling can bring you an element. If all these are not completely consistent, try it out and it is not difficult to understand the somewhat twisted logic. The slight loss in consistency is compensated by increased usability.
If you have reached the last child element of the parent, then next sibling will result in no action. If you want to move further down in the document, you need to go up to the parent first, then from the parent's sibling you can go back down. Earlier we mentioned that attributes and elements are considered siblings, nonetheless when we use the right arrow to get the first child, we would pick the first child element and not the first attribute. The reasoning is that the user will be more interested in the child element because the child elements may have child elements of their own, so going there first may speed things up.
Sometimes you are want to go to the next sibling of the same kind. For example, you are at the drink element, and you want to go the next drink element, even though that drink element belongs to another member. To do this you still use the up or down arrows, but you should also hold down the alt key. However, with Opera I cannot see the keystrokes with the alt key down. Therefore use the ctrl key instead of the alt key in Opera.
The browsers let you go from field to field using the tab or shift tab. So it is natural to do the same thing for the XML elements. Here the XML document structure is ignored and you just go from one element to the next. The tabbing should be very similiar to the tabbing of the fields. There is one difference, an complex element can have multiple fields, and our tabbing let you go to the complex element as well as the simple element. It may even look confusing when the selection go from small to large and then back to samll. However there is a simple rule to know where tab will bring you. Just look at the labels from top of the document to the bottom. This is the tabbing order.
However using the tab key this way only works fully for IE, for other browsers the problem is that the field tabbing is going on at the same time, and the effect can range to minor to severe interference with the tabbing. To get around the problem, alt (clrl in Opera) right/left arrow do the same thing as tab/shift-tab (except in IE, where tab and shift-tab are already working correctly and no work around is needed.)
Sometimes when you get to an element, you want to start editing the field. Since here we are talking about people who try to doing everything with the keyboard, so we need a way to switch over to the field with the keyboard. If an element is selected, hitting the escape key it brings you to the corresponding field (or deselect everything if you are not at a simple element or attribute.) Conversely, if you are at a field, escape would (try to) deselect the field and select the corresponding element. There can be minor problems with various browser. For example switching to a select list in Mozilla may select another item in the options list.
As an experiment, right arrow from a leaf node such as simple element or attribute is equivalent to escape, this may be faster when you are in the middle of navigation.
Finally, to be mouse independent, you need to evoke the commands from the keyboard. However, this is not implemented yet. I want to wait to have a complete command set before assigning letter codes.
All these key mappings are subjected to change. It is not easy to come up with a mapping that would work in every browser, and the alt-arrow keys are already being used by the browser. So a better mapping will be needed.