Description of problem:
The DHTML editor under IE doesn't work for editing templates. This blocks
automation of template tests with E-Tester, as well as being a general problem.
Short term fix is to disable the DHTML editor for templates. Long term, better
DHTML editors are on the road map.
I finally got a chance to look at this, and it is not clear to me what to do.
TextAssetBody assumes that the text is human-oriented and so uses DHTMLEditor. I
1. Change DHTMLEditor to take some predicate and display its non-DHTML fallback
form if it's true.
This is just super gross and is contrary to DHTMLEditor's purpose.
2. Do Bebop visibility magic and have two widgets for one form parameter.
I'm not sure Bebop will allow it, but even if it does, this is a hack.
3. Use a different authoring kit for templates.
This seems to be the right thing to do to me. But I don't think it's in scope
So, if there's anyway we can avoid having to do 1 or 2, let's consider it.
Otherwise, we'll have to do 2 I think.
What's so gross about option 1? Currently, DHTMLEditor.xsl conditionalizes
<!-- do the DHTML wodoo -->
<!-- display the vanilla textarea widget -->
How's adding one more condition anymore gross than what
we already have?
The XSL for DHTMLEditor makes sense to me. It's intended to be fancy when the
client permits it.
What seems gross to me is to turn that into "Be fancy when the client permits it
and the content is the right sort." DHTMLEditor should be able to assume the
latter, because it is part of DHTMLEditor's contract with the developer.
We could make the test "@isIE55 and not @dumbedDownForSomeUnspecifiedReason",
but I don't think that's very nice.
But, then, maybe that will turn out to be the most expedient fix.
We could make the test
where the value of @isOn is computed in Java based on the following
1. browser version
2. text asset type
3. phase of the moon
4. user preferences
Fixed in perforce 32869.
Though I don't have IE, my log statements indicate that the altered form is in
As it turns out, there was already a subclass of TextAssetBody (which contained
the DHTMLEditor). I changed it to generate the form with a TextArea instead.
On a side note, it would have been nasty to add the predicate. It's not the XSL
that is the issue; it's the code. You would need to change DHTMLEditor to take
a thunk containing the special case.
And why make DHTMLEditor do this in the first place? Much better to keep
DHTMLEditor's use consistent with its mission until we decide to change its mission.
It is turned off.