Thank you Hussein.
> > Would such an operation be appropriate for XXE to support?
>
> Why not? However this can also be done using a document type
> specific macro-command.
>
> For example: this one will work for docbook's listitem.
>
> ---
> <command name="moveListItemUp">
> <macro undoable="true">
> <sequence>
> <command name="selectNode"
> parameter="ancestorOrSelf[implicitElement]
> listitem callout step" />
> <match context="$selected" pattern="*[position() > 1]" />
> <set variable="anchor" context="$selected"
> expression="./preceding-sibling::*[1]" />
> <command name="cut" />
> <set variable="selected" expression="$anchor" />
> <command name="paste" parameter="before" />
> </sequence>
> </macro>
> </command>
> ---
This is where it suddenly balloons. Writing a fragment of code using XML
syntax, editing config files, is very painful. A scripting language (like
jRuby) would say this very simply (and I have not even looked for
improvements):
Command(:moveListItemUp, :undoable=>true) {
selectNode ancestorOrSelf(implicitElement), listitem, callout, step
match $selected, {position > 1}
anchor = $selected.preceding_sibling
cut
$selected = anchor
paste
}
This macros could simply be put into a standard directory. XXE loads it
dynamically from this directory, looks it up dynamically by name, puts it
onto menus dynamically by name. Macros can be structured using the features
of the scripting language. Absolutely no need to _have_ to edit
configuration files. It makes customization _so_ much easier. Wrapping XML
syntax around a fragment of code makes it much less approachable, not
easier.
> > What other tree-operations would be appropriate on any tree
> of elements
> > governed by some schema? Such as "make an element A at the closest
> > subsequent location (relative to current cursor or current
> selection)
> > where A would be legal in the schema, and position cursor
> at the first
> > editable position in that new A" ?
>
> Generic command "add" does exactly that. See
> http://www.xmlmind.com/xmleditor/_distrib/docs/commands/ch06s02.html
>
> However, unlike for the "insert"/"replace"/"convert" commands, you
> cannot pick element A from a list.
Why not? I agree you cannot pick it from a list of elements valid at the
current insertion point, but you should be able to pick it from a list of
all insertable elements.
> That's why generic command "add" can only be used in document type
> specific macros, in document type specific toolbars, in document type
> specific menus, etc.
I don't see why this restriction is necessary. But I may be missing
something.
