Bug 97735

Summary: Turn off DHTML editor for Templates
Product: [Retired] Red Hat Enterprise CMS Reporter: Jon Orris <jorris>
Component: otherAssignee: Justin Ross <jross>
Status: CLOSED RAWHIDE QA Contact: Jon Orris <jorris>
Severity: medium Docs Contact:
Priority: high    
Version: nightlyCC: ccm-bugs-list
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-07-02 14:03:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 92111    

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
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 17:12:06 UTC
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 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 
inputs: 
 
  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
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 14:03:53 UTC
It is turned off.