Bug 97735 - Turn off DHTML editor for Templates
Summary: Turn off DHTML editor for Templates
Alias: None
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other
Version: nightly
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Justin Ross
QA Contact: Jon Orris
Depends On:
Blocks: rc0blockers
TreeView+ depends on / blocked
Reported: 2003-06-19 21:31 UTC by Jon Orris
Modified: 2007-03-27 04:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-07-02 14:03:53 UTC

Attachments (Terms of Use)

Description Jon Orris 2003-06-19 21:31:53 UTC
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.

Comment 1 Justin Ross 2003-06-25 16:23:50 UTC
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
right now.

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.


Comment 2 Vadim Nasardinov 2003-06-25 17:12:06 UTC
What's so gross about option 1?  Currently, DHTMLEditor.xsl conditionalizes 
      <xsl:when test="@isIE55='true'"> 
<!-- do the DHTML wodoo --> 
<!-- display the vanilla textarea widget --> 
How's adding one more condition anymore gross than what 
we already have? 

Comment 3 Justin Ross 2003-06-25 17:24:37 UTC
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.

Comment 4 Vadim Nasardinov 2003-06-25 17:42:46 UTC
We could make the test 
   <xsl:when test="@isOn='true'">  
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 

Comment 5 Justin Ross 2003-06-25 21:41:01 UTC
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.

Comment 6 Jon Orris 2003-07-02 14:03:53 UTC
It is turned off. 

Note You need to log in before you can comment on or make changes to this bug.