Bug 97735 - Turn off DHTML editor for Templates
Turn off DHTML editor for Templates
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
high Severity medium
: ---
: ---
Assigned To: Justin Ross
Jon Orris
:
Depends On:
Blocks: rc0blockers
  Show dependency treegraph
 
Reported: 2003-06-19 17:31 EDT by Jon Orris
Modified: 2007-03-27 00:07 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-07-02 10:03:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jon Orris 2003-06-19 17:31:53 EDT
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 12:23:50 EDT
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
could

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.

Justin
Comment 2 Vadim Nasardinov 2003-06-25 13:12:06 EDT
What's so gross about option 1?  Currently, DHTMLEditor.xsl conditionalizes 
on 
 
   <xsl:choose> 
 
      <xsl:when test="@isIE55='true'"> 
<!-- do the DHTML wodoo --> 
      </xsl:when> 
      <xsl:otherwise> 
<!-- display the vanilla textarea widget --> 
      </xsl:otherwise> 
  </xsl:choose> 
 
How's adding one more condition anymore gross than what 
we already have? 
 
 
Comment 3 Justin Ross 2003-06-25 13:24:37 EDT
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 13:42:46 EDT
We could make the test 
   <xsl:when test="@isOn='true'">  
 
where the value of @isOn is computed in Java based on the following 
inputs: 
 
  1. browser version 
  2. text asset type 
  3. phase of the moon 
  4. user preferences 
 
Comment 5 Justin Ross 2003-06-25 17:41:01 EDT
Fixed in perforce 32869.

Though I don't have IE, my log statements indicate that the altered form is in
place.

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 10:03:53 EDT
It is turned off. 

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