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.
There are at least two reasons that you may want to use this command. Mozilla (but not IE
or Opera) has a bug that with any added input fields would be out of order when
the form is submitted. This results in the server CGI generating the wrong XML data. With a snap shot
the input fields would be submitted in the correct order. However this is not a problem
if you do it with client side JavaScript.
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.