More about InfoPath

The other day I posted about my initial experiences with InfoPath. As I mentioned, one of the frustrating things I found was that for the body text, whose type was string, I couldn't use the RichTextBox.

Don shared some insight as to why this is the case.

The rich text control can only be bound to an element whose type looks like this:

<complexType mixed="true">
<sequence minOccurs="0" maxOccurs="unbounded" >
<any namespace="http://www.w3.org/1999/xhtml"
processContents="lax" />
</sequence>
</complexType>

As it turns out, the problem is that this particular service uses a string for that field. At first I accepted that answer, but the more I think about it, the more it bothers me. I'm assuming the RichTextBox produces an XHTML. An HTML string, whether well-formed or not, is still just a string at the end of the day. If the underlying data type is perfectly valid, why shouldn't I be able to use RichTextBox?

At the very least, I'm hoping I can do some sort of mapping. If I can create a new "virtual" data field on my end, bind the RichTextBox to it, and then provide some mapping logic to the underlying object (ie escaping XML characters or wrapping it in CDATA), that would be neat. I'm going to keep my fingers crossed and play with it a little this weekend.

The thing is, I really do think it's important for a tool such as InfoPath to be flexible. I realize this may be a contrived example to some extent... but when I design a form, I should be able to choose how to build the string. I shouldn't be limited to a simple textbox. More importantly, we shouldn't have to design services based on their potential consumers.

Can anyone (Don especially) add more insight into this problem? Am I missing something here? Are there valid technical reasons why this shouldn't be the case?

Published Friday, April 04, 2003 1:51 PM by Tim Marman
Filed under:

Comments

# re: More about InfoPath

Friday, April 04, 2003 3:25 PM by Don Box
I agree with the decision to not allow RichTextBox to bind against elements of type xs:string.

I do wish that the tool was a bit more liberal in what schema constructs it allows however.

Requiring a complexType with mixed="true" is good.

Requiring unbounded repeating element wildcards in the XHTML namespace is OK too.

However, a little more flexibility would be great. For example, I'd like to be able to distinguish between block (<div>/<p>/<table>) and inline (<em>/<img>/<a>).

The InfoPath folks are aware of this.

When they can deliver is (as always) based on resources and schedule. Remember, we're just a small software firm trying to make our way in the world :-)

Leave a Comment

(required) 
(required) 
(optional)
(required)