thx for this, sounds promising, looking forward...
-marc=
Hussein Shafie wrote:
> 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
I'll use!
> 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.
>
fair enough
>
>
>
>>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).
>
I see, but then I would need to ask for a filename as well.
>
>
>
>>[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.
>
I'll have a look into this part of the API then
> 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.
> --
> XMLmind XML Editor Support List
> xmleditor-support at xmlmind.com
> http://www.xmlmind.com/mailman/listinfo/xmleditor-support
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo at outerthought.org mpo at apache.org
