
Hi David, In this context we have recorded an improvement to provide access to what elements are available at the current position so that you can disable the action in contexts when that element cannot be inserted. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 4/28/13 7:34 AM, David Cramer wrote:
On 04/26/2013 02:15 PM, Mark Baker wrote: ...
My question is, is there a way, and do folks think it is desirable, to present a different cue for incomplete structures than for erroneous ones. At minimum, use a different color, such as yellow, for incomplete. Ideally, find some way to indicate that the author is on the right track and needs to continue.
Thoughts?
Hi Mark,
That's an interesting idea and what follows doesn't address it at all. Instead, this is my approach to the problem:
In cases where there's more than one possible next element often one of the elements is the most commonly used. For example, if you enter an itemizedlist, it could take a title or info as a child, followed by a listitem, but usually you just want a listitem. The listitem in turn could take many block elements as a child, but 99% of the time you want a para.
If you're writing in author view, then you can add Actions that enter a typical collection of markup instead of just the element and then REMOVE the element from the content completion list.
For example, you could have an itemizedlist action that inserts <itemizedlist xmlns="http://docbook.org/ns/docbook"><listitem><para/></listitem></itemizedlist> at the caret position and then bind that to the Content Completion menu as well as any contextual menus or toolbars. If you remove the itemizedlist element from the content completion stuff, then when you press enter and type itemizedlist, you'll always get your action and not the bare element.
Now it's up to the user to know that she can modify that template and add a title to the itemizedlist or use something other than a para inside the listitem, but for usability, I think this approach wins.
It would be really cool if that stuff were configured out of the box for supported schemas at least for the most important elements. It's not the kind of thing that each user in your org should configure for themselves. Instead all the config should be done and distributed to them in a framework.
Regards, David
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user