context checked XUI input? mini-Editor window?

[naglists]

Hi all,

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.

--
Paul Nagai

[ClayHelberg]

Hi Paul-



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.



--Clay

[naglists]

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.

Thanks for the thoughts, Clay!

[ClayHelberg]

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?



--Clay

[bibach]

Hey, Paul...

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.

-Brandon 🙂