Dealing with Style nodes

hyndgrinder commented 6 years ago

In the reportPages nodes' descendants, many points have a style node. Usually, the style node is just left at default state for it's node level. Depending on the node, it could be more or less likely to be overriden by the user. Here are a few examples of style nodes at differing levels of the etree:

page:

<style>
    <defaultStyles>
            <defaultStyle refStyle="pg"/>
    </defaultStyles>
</style>

pageBody:

<style>
    <defaultStyles>
        <defaultStyle refStyle="pb"/>
    </defaultStyles>
</style>

list (simple tabular output)

<style>
    <CSS value="border-collapse:collapse;font-size:10pt;margin-top:20px"/>
    <defaultStyles>
        <defaultStyle refStyle="ls"/>
    </defaultStyles>
</style>

In each of these cases it looks like the default style has been used. Each default style has a refStyle and value which it ultimately references from the Cognos css system. In the list object we see a new node called . I believe this represents a user override, where they have specified a specific style for the object of the style's parent (the list in this case).

I think it makes sense to build a method to deal with the parsing of style no matter which level it comes from. Thoughts @SinclairC ?

SinclairC commented 6 years ago

Lol. I just asked about this stuff in another issue. Nice timing.

I agree that it makes sense to make a generic method for getting style info that returns both "defaultStyle" and "CSS" no matter how they're arranged.

hyndgrinder commented 6 years ago

Styles can be inherited from parents, but styles placed on a child overrides a style that is inherited.

Also someone can create a custom style class in a report. This is different from explicitly changing a style on an object. It's more like creating a 2nd custom defaultStyle node. I don't seem to have any examples of this, but it's not a commonly used feature either. I may be the only person I know who actually uses them. I will try and get sample of a custom style class.

SinclairC commented 6 years ago

I feel like maybe I'm missing something. Are we planning on using these style values to style the exported reports, or are they just being included only in text form so users can easily see where styles have been applied to which areas?

hyndgrinder commented 6 years ago

In a word: both. We only have to do work for the latter, however. We will not be using the styles per se. By capturing the etree element in the class, we will have captured all the things necessary to transport the object to the clipboard. So, that piece will only require a method to do the actually 'clipboard copy'. At this point, my suggestion is that it's a simple toString(element) displayed on the screen for the user to highlight/copy. Maybe it gets more sophisticated down the line; somehow we inject it directly onto the clipboard, but to start, we'll just display the elements to allow for copy/paste. This is our methodology for all object copy/pastes, not just styles. It's just that styles appears at some many levels and points throughout the layouts node, so we want to just build one method for dealing with styles.

We will be documenting the styles. The 'work' for the latter, is simply to create the class and capture its XML attributes, text, subclasses, and its etree element. Basically what we're doing for each class.

SinclairC commented 6 years ago

I've pushed a branch called "styleClass" that mostly shows how I think things could work, but I'm not recommending merging it at this point.

Note that it would probably use Util.getStyles() on the ReportPages if we had them implemented. Right now it just grabs everything from the entire XML file.

Anyway, the basic idea is that every style element found in a report/section should have the most recent style in the hierarchy as its parent. The getStyleTree() method just goes through and gets all info from its parent, their parent, etc. in order so that the most important CSS is element 0 in the list.

We might have to do some adjusting to make sure that there aren't multiple CSS items that override earlier versions (ex. seventeen "background-color" values aren't much help). Should just be a matter of checking if the setting exists already and only displaying the latest one when getting the full Style "tree".

FeedTheCube / CogDoc