I'm working on easifying the editing of some meta data attached to my content. The first, low-hanging fruit, we've picked by way of XUI dialogs that manage the attribute editing of forty or fifty content-less elements and two elements requiring only rudimentary tagging capabilities (hard spaces, newline element).
The next set of meta data elements require me to "easify" the editing of forty or fifty additional elements more or less with the following cascade of content models: Meta data elements' content models include: <value> <value> includes: #PCDATA | newline | check | bold | italics newline and check are EMPTY elements representing just what they sound like. bold and italics are just what they sound like.
I would like to be able to create XUI "structureboxes" that could be passed value's content model and editing would be Editor-like in terms of keeping context and validity and a quick-list. (I would also like $3M and an airplane.) Anyone know how to do a "structurebox" in XUI?
The alternate idea I'm rolling around is finding some way to launch or embed a "mini-Editor" window with a handle only on the <value> element. Not sure if I explained that well. Something like what you get when you select content and Edit as XML Source except that it would be validated, context-checked XML, not source. The problem I see with this (aside from not having figured out step 1 yet) is that I can't imagine it scaling well to even ten or fifteen simultaneous instances of the "mini-Editor."
Any thoughts? Pointers to help docs? Even sympathy appreciated at this point.
You can do this if you use 5.4, which has a nifty new Editor ActiveX control. This lets you embed an Editor window inside an ActiveX container, including a XUI dialog. In fact, it even ships with an example of that in the samples directory.
So, you could do something along these lines:
1) Create a micro-DTD for your <value> fragment
2) Make a XUI with an embedded Editor ActiveX control to let the user create/edit their <value> content
3) When the user is done, get the content and import it into your real document.
If you're stuck with 5.3 or lower, you might have to do something like use a tree control and let them build the structure that way, somewhat akin to the docmap view. Or maybe you could just give them a textbox with a "<value></value>" wrapper and let them type content in directly, maybe giving them a few buttons for adding <newline/>, <check/>, etc. Then you'd want to validate when they click "OK" to make sure you're getting good markup from them.
Hmmm. Maybe I'll download and play w/5.4. I'm still suspicious that a XUI dialog with ten+ embedded Editor instances might be a resource problem. But maybe I don't understand the architecture and it will work like a charm. In any case, if 5.4 does it "right" maybe we defer this requirement and find a cheap (hours-wise), interim, better-than-what-they-have-now solution.
We're already doing that last thing you suggest for two fields ... it's taking it up to 40+ such fields that feels too cumbersome.
Uh oh, I missed the part about 40-50 instances on the same dialog. Yeah, in that case you probably don't want to try having a separate ActiveX control for each one. Maybe you could fix it so your micro-DTD can handle all 40-50 instances in one document? Add a container element at the top, and maybe an extra attribute you can use to tell them apart?
If it looks like embedding 5.4 would work well, but you're concerned about the performance issues of having many instances, perhaps you could do something like having a regular text box for each value and wiring things up so that when the focus shifts to one of those boxes, a single instance of the Editor control is positioned on top of the text box, loaded with its content and made visible. On loss of focus, the content is shifted back to the text box and the Editor is hidden. The effect would be one of the Editor kind of "coming to life" as they move to each field.
Alternatively, especially since you're not on 5.4 yet, you might consider doing something with a rich text control. Your description of the content model seemed to indicate that it is pretty much the same for all of the fields, consisting of mixed content with two empty tags and two inlines (bold and italic). Assuming that the empty tags can occur inside the inlines, you could probably enable bold and italic in the rich text control, giving the user buttons and/or keyboard shortcuts to activate them, make the control multi-line so the user can insert a "newline" directly, and allow insertion of the "check" through whatever mechanism feels right, representing it in the field with a character whose glyph looks about right.
If the input is limited, which should not be too hard, it should be fairly easy to keep them from making something invalid and it shouldn't be too complicated to parse the result, turning actual newlines into the element form, your chosen special character into the check element and stretches of bold and italic into the inline tags.
This does have a certain amount of reinventing the wheel attached to it, but given the minimal structure involved, it may provide a lighter-weight solution than embedding the full Editor control, and you could do it with the version of Editor you're using right now.