Marc Portier wrote:
>
> > The reason is that: for now, you can write commands that act on the
> > document loaded in XXE (tox.readAttribute) but you cannot write commands
> > that act on the XXE application itself (tox.openFile).
>
> I understand, conceptually it could even make sense to wrap this
> up under a different API then the command API (more like
> <process> or something really new)
>
> in fact I first tried with the <read> in side <process> if XXE is
> not ready to open up that part of the API they could easily
> provide some <open> or <edit> that behaves like the read?
>
> >
> > We'll try to enhance XXE in release 2.3 (released at the end of this
> > month) to allow you to do that. We have always intended to do it but
> > neglected to add it to the development schedule.
>
> this is somewhat comforting, however the 'try' word leaves some
> room for blind hope :-)
OK. Here's what you'll have in XXE V2.3 (I hope):
* A command (for use in a macro) which returns an XPath node set
converted to a string (? la XSLT), where the context node is the
explicitly or implicitly selected node. This is your tox.readAttribute
but generalized.
(An option of this command will allow to resolve the returned URL
against the entity URL of the found node.)
* XXE (the application) will register some of its javax.swing.Actions as
Commands. You'll have at least a xxe.open. More actions wrapped into
commands (xxe.close, xxe.new, xxe.print, etc) could be added in the
future.
I say "I hope" and "try" because unless we have already implemented it,
one can never be sure.
> Since looking forward to something infinitely distant as 'the end
> of the month' I like to volunteer for beta testing if such is
> applicable?
>
> Maybe to give you some more extensibility-inspiration:
> Some other things I envision for my customization effort...
>
> [1] I now have this <inline-group src="" /> pointing to a
> different file that actually follows the same DTD as the original
> one.
>
> I would like to have an option where people can select a number
> of elements in the current file and then choose in the menu
> something like "Move to new external module" which first asks
> them the name of that new module and then goes of creating that
> file, opening it for edit (that might be optional), pasting the
> selected nodes over there and finally replacing the selection of
> nodes with the reference <inline-group src="new-module-name" />
> in the file you started from.
Except for "opening it for edit", you can do that right now by writing
your own custom command (i.e. not a macro-command).
> [2] Also it would be nice to be able to use some xpointer
> expressions in the css... I foresee the external module files to
> have some root element with a @display attribute. It would be
> nice to have that displayed in the referring document (not only
> in the module itself)
>
> maybe some
> inline-group {
> content: external-content( [xpointer-expr] )
> }
>
> where xpointer-expr becomes something like
> concatenate(attr(src),'#/@display')
>
> but could be any http://file/whatever#xpath
>
> (maybe this is already achievable through creation of my own gadget?)
Yes. It is called a custom view: a view, which unlike a normal view, is
not a paragraph or a piece of text.
How to write a custom view will be documented in XXE V2.3 (Javadoc +
chapter in the developer's guide).
Custom views already work. It is used to style XHTML input, select and
textarea and in this case, custom views are implemented using Swing
JComponents. It is also used to implement the collapse/expand toggle and
in this case, the custom view is a Gadget. We have also written
JComponent based custom views as a service provided to customers.
Writing AWT Component/Swing JComponent based custom views is what will
be documented. Use of Gadgets is ``reserved to XMLmind'', not because we
want to keep secrets, but because we do not intend to provide support
for writing Gadgets.
PS: We have already added an extra optional argument to the image()
pseudo function. This argument specifies which fallback image to use
when the image to be displayed cannot be loaded. While this does not
replace a custom view, you'll be able to do this:
-------------
inline-group {
background-color: #eeeeee;
content: " to select @src right-click: " image(attr(src), auto, auto,
default, url(link.png));
}
-------------
This is not a hack. Being able to specify the image placeholder in the
CSS may be give useful information to the user having inserted a
figure-like element.
