Re: Kupu shows up even if the TextField doesn't support text/html

Martin Aspeli wrote:

> kupu is a mystery to me, but I'm sure it must be able to *not* load
> itself  conditionally, because it does so when it presents the "edit
> using kupu"  option when the current mimetype isn't HTML.
> 
> If I put this just before the last return statement in
> contentUsesKupu.py,  I get closer:
> 
> allowedTypes = getattr(field, 'allowable_content_types', None)
> if allowedTypes is not None and len(content) == 0:
>      if 'text/html' not in allowedTypes:
>          return False
> 
> This stops kupu stomping on my content, but doesn't hide the "edit
> using  kupu" link, which could still cause confusion. I'd consider
> this a bug in  kupu - but I don't have commit privs and as I said,
> kupu's  uber-general-ness scares me. :)
> 
Yes, I think you are right and I need to tighten up the test for loading 
kupu. The problem I'm trying to solve is that a document which has just 
been created e.g. ATDocument has a default output type of HTML, but since 
the field is empty it claims its current type is 'text/plain'. In that 
situation we need kupu to load even though the field isn't currently html.

As you point out though, just because you are using RichWidget doesn't mean 
that html is really one of the allowed content types, so I made a wrong 
assumption there.

Likewise the link to force kupu on needs to test the allowed content types, 
which is a pity because right now it just tests for the general case of 
kupu being enabled and runnable in that browser.



-------------------------------------------------------
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