OK I just looked. If you have an ad_form snippet like:
{foo:rich_text ... }
your widget just puts out "foo.textarea" and "foo.format" (or perhaps "foo.1" and "foo.2").
The "values" attribute will contain the list of the two values.
The textarea datatype would work with this if you overload its meaning and submit processing code used the values rather than value attribute.
But ... as I said above, submit processing code should not need to be aware of what widget's used with a variable of a given datatype. In this case it needs to know to use values if your rich_text widget is used.
Creating a rich_text datatype as well as widget avoids that slight messiness, and as I mentioned above allows you to provide get_property, set_property, acquire and transform methods that hide the data structure you're using to hold the textarea/format pair from the application code.
These also plug in to the ad_forms to_html, from_sql and related ... ummm ... hacks (I eventually want to extend the datatype implementation model so ad_form can intuit these without explicit coding by the programmer). to_html, for instance, would apply the right style of formatting to the data and pass back the HTML string - which is then suitable for display in a "-confirm_template" template.
