non-breaking space in XUI textbox breaks my acl

[naglists]

I have a XUI dialog that, among other things, allows a GUI interface to
editing the value of an element named date.

If <date> contains "1 January 2009" everything behaves as expected. If
<date> contains "1January 2009" things get messy.

When there are no non-breaking spaces, and I change 2009 to 2010 in the XUI
dialog, my ACL properly inserts "1 January 2010" into the XML.

When there is a non-breaking space between "1" and "January" and I change
2009 to 2010 in the XUI dialog, my ACL incorrectly inserts "1January
2010January 2009" into the XML.

When there is a non-breaking space between "January" and "2009" and I change
2009 to 2010 in the XUI dialog, my ACL incorrectly inserts "1
January20102009" into the XML.

Incidentally, the non-breaking space does not display in the XUI text-box at
all. So, with a non-breaking space between "1" and "January" the XUI
displays "1January 2009".

Prior to this discovery, I had to detect "<newline/>" in the XML and gsub it
with "|" on the way into the XUI and reverse that process before a write. I
am able to do the same thing with (although I haven't decided on a
suitable replacement character for the XUI text box ... temporarily I'm
using "~"). When I make this swap, the correct content ("1 January 2010") is
inserted.

Anyone seen this before? Seems like a bug (or feature) somewhere in the XUI
textbox display / store area.

--
Paul Nagai

[bibach]

Hey, Paul...

I recall dealing with these sorts of issues when working with COM/VB
dialogs as Editor customizations (before XUI was an option). Can you
show some of your code for getting the content from your document into
the XUI and back?

-Brandon 🙂

[naglists]

This is the code reading in the XML and loading the XUI element:

implementation_date = oid_find_children($qvarr[1], implementation_datearr,
"implementation_date_qv");
temporary_implementation_date_value =
oid_content(oid_child(implementation_datearr[1], 1));
junk = gsub("<newline/>", "|", $temporary_implementation_date_value);
# junk = gsub("", "~", $temporary_implementation_date_value);
implementation_date_value = '<textbox id="ImplementationDate"&lt;br"/>width="275"><value>' . $temporary_implementation_date_value .
'</value></textbox>';

This is the code reading the updated (or not) XUI and inserting content back
into XML:

implementation_date = oid_find_child_attrs(oid_root($xuidoc),
implementation_datearr, "id", "ImplementationDate");
implementation_date_out_value = oid_content($implementation_datearr[1]);
junk = gsub("\\|", "<newline/>", $implementation_date_out_value);
# junk = gsub("\\~", "\\", $implementation_date_out_value);
junk = oid_select(oid_child(oid_caret(), 15),1,1);
delete_mark;
goto_oid(oid_child(oid_caret(), 15));
insert_tag value;
insert_string -sgml "$implementation_date_out_value"


I believe bug number one occurs when the XUI "engine" attempts to display
in the XUI dialog's XUI textbox. XUI!

I believe bug number two occurs when oid_content reads
$implementation_datearr[1].

Or that the same bug exhibits in each of those situations.

Uncommenting the nbsp gsub lines bypasses the problem and should be in-use
tomorrow, pending testing resources. I'll probably submit this to support
later.


On Wed, Sep 9, 2009 at 10:01 AM, Brandon Ibach <
brandon.ibach@single-sourcing.com> wrote:

> Hey, Paul...
>
> I recall dealing with these sorts of issues when working with COM/VB
> dialogs as Editor customizations (before XUI was an option). Can you
> show some of your code for getting the content from your document into
> the XUI and back?
>
> -Brandon 🙂
>
>

[bibach]

Just an untested suspicion, but I bet the problem is that the "nbsp"
entity is not defined in the XUI doctype.

Your gsub replacement of the reference is one way to go, though you
might consider just replacing the reference with the raw character or
a numeric reference (), as I suspect this should display just
fine, looking much like a regular space to the user, but still
preserve back into your document. You may need to explicitly convert
it back to a named reference, if Editor doesn't do so automatically.

Take a look at the flag value 4 for the oid_content function, as well
as the entity_expand function, as they may be useful.

-Brandon 🙂

[naglists]

But authors have to be able to insert an nbsp from within the dialog so I
have to support a typeable (ideally visible) character. ~ works well enough.
They're already using | for a newline element so it's not a new thing.

On Wed, Sep 9, 2009 at 11:32 AM, Brandon Ibach <
brandon.ibach@single-sourcing.com> wrote:

> Just an untested suspicion, but I bet the problem is that the "nbsp"
> entity is not defined in the XUI doctype.
>
> Your gsub replacement of the reference is one way to go, though you
> might consider just replacing the reference with the raw character or
> a numeric reference (), as I suspect this should display just
> fine, looking much like a regular space to the user, but still
> preserve back into your document. You may need to explicitly convert
> it back to a named reference, if Editor doesn't do so automatically.
>
> Take a look at the flag value 4 for the oid_content function, as well
> as the entity_expand function, as they may be useful.
>
> -Brandon 🙂
>
>

[bibach]

Good point. 🙂 I wasn't sure if you had a requirement to allow
authors to put in non-breaking spaces explicitly. This is an inherent
problem with using dialogs for content entry, since Editor's built-in
mechanisms for entry of non-keyboard characters are not available
there.

If you expect entry of newlines to be a required feature, you might
make the text box multi-line so that the user can just hit the
carriage return key as they might normally. For others, like nbsp,
unless you want to subject them to the alt-keypad trick (which may or
may not work in a XUI... not sure), you might also consider providing
a button or other type of GUI widget specifically for entering each
special character they might need, if the list of options is
relatively small. If you go the button route, you could even put
accelerators on the button so they could hit, say, Alt-N to get an
nbsp.

While you probably still want a visible character, if it doesn't have
to be typeable, you have a choice of a wide range of glyphs, depending
upon what font the text box is using, such that you can avoid clashing
with a character that might eventually get used for its normal
purpose, even if it is pretty unlikely that you'd end up with a tilde
in a field that's supposed to be a date.

-Brandon 🙂

[naglists]

Interesting. Just for fun, I tried the alt code for a non-breaking space.
XUI textboxes do support alt code entries. Further, the nbsp is properly
returned to the XML. The bug (Arbortext's or mine) is in the XML read or
insert into the XUI dialog, not in its display or being read.

Regardless, I think my authors are going to like the "visible" non-breaking
space better anyhow so they will know while looking at the XUI if they've
authored according to their style guide or not.

On Wed, Sep 9, 2009 at 12:49 PM, Brandon Ibach <
brandon.ibach@single-sourcing.com> wrote:

> Good point. 🙂 I wasn't sure if you had a requirement to allow
> authors to put in non-breaking spaces explicitly. This is an inherent
> problem with using dialogs for content entry, since Editor's built-in
> mechanisms for entry of non-keyboard characters are not available
> there.
>
> If you expect entry of newlines to be a required feature, you might
> make the text box multi-line so that the user can just hit the
> carriage return key as they might normally. For others, like nbsp,
> unless you want to subject them to the alt-keypad trick (which may or
> may not work in a XUI... not sure), you might also consider providing
> a button or other type of GUI widget specifically for entering each
> special character they might need, if the list of options is
> relatively small. If you go the button route, you could even put
> accelerators on the button so they could hit, say, Alt-N to get an
> nbsp.
>
> While you probably still want a visible character, if it doesn't have
> to be typeable, you have a choice of a wide range of glyphs, depending
> upon what font the text box is using, such that you can avoid clashing
> with a character that might eventually get used for its normal
> purpose, even if it is pretty unlikely that you'd end up with a tilde
> in a field that's supposed to be a date.
>
> -Brandon 🙂
>
>

[ClayHelberg]

Hi Paul-



At the risk of starting a flame war, isn't this the sort of thing we're
supposed to be discouraging our users from doing? Is there really a use
case for authors deciding specifically when the space between "1" and
"January" should break and when it shouldn't?



--Clay

[ptc-1787870]

I wonder if a calendar object would work better here. That would allow you to write out the date in the correct format based on the user selection.

You probably already argued for something like that...

[naglists]

The possibility of either a custom or customized calendar object exists ...
this is not your every day date or date format. They do strange stuff I
don't necessarily understand in this field.

We should just make Robin buy a round of drinks next June and we'll spec out
the best possible implementation date widget (where best possible = my full
employment in FY11 😉 Hey, *I'll* buy the round.