Bug 97735
Summary: | Turn off DHTML editor for Templates | ||
---|---|---|---|
Product: | [Retired] Red Hat Enterprise CMS | Reporter: | Jon Orris <jorris> |
Component: | other | Assignee: | Justin Ross <jross> |
Status: | CLOSED RAWHIDE | QA Contact: | Jon Orris <jorris> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | nightly | CC: | 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
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 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? 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 <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 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. It is turned off. |