kupu vs. allowed content types

Sorry if this is a re-post, but it seems my mail from last night isn't
showing up?

Basically, I have discovered that if I have a RichWidget on a TextField that
sets allowable_content_types to a list that does *not* include text/html,
then kupu will still load up. This is quite bad, because the output ends up
being plain text (in my case, intelligenttext, but STX, reST, Markdown etc.
would have the same problem) with HTML tags in them.

I believe this is a bug in kupu, but I don't have commit privileges, and at
any rate kupu's XSLT-driven multi-platform-ness scares me a bit. I *think*
however, that it should be sufficient to make two small changes:

 - contentUsesKupu.py needs to make a check that if 'text/html' is not in
the list of content types for the field, it should return False. It can do
this by calling field.getContentType(context) and examining the list that's
returned.

 - kupu_wysiwyg_support.html needs a similar check around the "edit with
kupu" links so that these don't show up if the content does not in fact
support editing with kupu.

Is this reasonable? 

Martin
--
View this message in context: http://www.nabble.com/kupu-vs.-allowed-content-types-t1535676.html#a4172331
Sent from the Archetypes - devel forum at Nabble.com.



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642