Oxygen XML Forum

Posted: **Tue Jan 10, 2017 9:24 pm**

Hello-

I modified our cc_config file to exclude certain elements for selection - I'm new to config files and I have few questions before distributing the files to the writers (they were just loaded with oXygen 18, so they are starting from scratch):

[*]I only modified the excludeElements list for now, but if I need to modify this again in the future, will there be any "side effects" of distributing the new file for the writers? For example, if the writers have customized x, y, or z in the UI or elsewhere (not in the cc_config file), they need to do that again.
[*]Is the Global Options xml file only UI preferences, or does that have a role with the config file as well?
[*]What is the easiest way to distribute the new cc_config file? I could only think of emailing the file and requesting that the writers copy the file over to the correct resources folder locations. Is there a better way?

Many thanks,

Abby

Posted: **Wed Jan 11, 2017 1:08 pm**

Hello Abby,

[*]I only modified the excludeElements list for now, but if I need to modify this again in the future, will there be any "side effects" of distributing the new file for the writers? For example, if the writers have customized x, y, or z in the UI or elsewhere (not in the cc_config file), they need to do that again.

The cc_config.xml file is a customization layer. When you'll deploy a new version it will apply without interfering with the writers settings.

[*]Is the Global Options xml file only UI preferences, or does that have a role with the config file as well?

It has no connection with the content completion configuration file (cc_config.xml). All the options a writer will make inside Preferences will be stored inside this "Global Options" file. As a side note, options can be shared by using projects (perhaps you will find it useful to ensure that your writes are using the same set of options).

[*]What is the easiest way to distribute the new cc_config file? I could only think of emailing the file and requesting that the writers copy the file over to the correct resources folder locations. Is there a better way?

This configuration file resides inside the framework so I guess you could go with one of the recommended way of Sharing a Framework. Also, if you are making changes to a built-in framework it is better to extend it and Sharing the Extended Document Type.

Best regards,
Alex

Posted: **Thu Jan 12, 2017 8:16 pm**

Thank you. I was able to remove the elements from the content completion menu and the elements menu by creating a dita extension file, but I was wondering why my rejectElements code in the cc_config file did not work on it's own - what am I doing wrong here?

Code: Select all

<!-- 

    	Element Proposals 

    -->   	

    <elementProposals path="section" insertElements="title p"/>

	<elementProposals rejectElements="abstract" />

	<elementProposals rejectElements="apiname" />

	<elementProposals rejectElements="bodydiv" />

	<elementProposals rejectElements="boolean" />

	<elementProposals rejectElements="cmdname" />

	<elementProposals rejectElements="coderef" />

	<elementProposals rejectElements="conbodydiv" />

	<elementProposals rejectElements="critdates" />

	<elementProposals rejectElements="delim" />

	<elementProposals rejectElements="figgroup" />

	<elementProposals rejectElements="foreign" />

	<elementProposals rejectElements="fragment" />

	<elementProposals rejectElements="fragref" />

	<elementProposals rejectElements="itemgroup" />

	<elementProposals rejectElements="kwd" />

	<elementProposals rejectElements="linkinfo" />

	<elementProposals rejectElements="linklist" />

	<elementProposals rejectElements="linkpool" />

Posted: **Fri Jan 13, 2017 3:47 pm**

Hi,

Apparently, <elementProposals> do not stack together so your elements will override one another. I'll have a look to see if it is something that we can improve on the loading part or, at least, make the documentation clear. Meanwhile, you should group them all like this:

Code: Select all

<elementProposals rejectElements="abstract apiname bodydiv boolean" />

Best regards,
Alex

Posted: **Mon Jan 16, 2017 8:40 pm**

Hi Alex,
This worked with attributes, but I could not get it to work with elements. I could only modify the elements list by creating a Document Type Associations DITA extension file.

Now, my problem is that I have added Additional frameworks directories, and I cannot save the file locally to copy it into the oXygen program files:

I've tried:

${homedir}C:/Users/[username]/custom_frameworks/dita-extensions
file:/C:/Users/[username]/custom_frameworks/dita-extensions

However, when I go back into the extension file, click External, and try to save to one of these locations, it says the location must be on the Additional frameworks directories.

It will not save to the Default directory either because I do not have rights to saving in the oXygen Author Program files.

How do I fix this? TIA.

Abby

Posted: **Tue Jan 17, 2017 1:08 pm**

Hi Abby,

Have you tried putting them both on the same declaration, like this?

Code: Select all

<elementProposals rejectAttributes="audience platform" rejectElements="abstract apiname bodydiv boolean" />

The "Additional frameworks directories" entries have to be file paths (no protocol at the beginning) so you could put something like:

Code: Select all

${homeDir}/custom_frameworks/dita-extensions

which will expand to:

Code: Select all

C:/Users/[username]/custom_frameworks/dita-extensions

Best regards,
Alex

Posted: **Thu Jan 19, 2017 9:24 pm**

Hi Alex,

I managed to get the elements constrained with a frameworks file (we conferenced with Radu the other day), but the attributes that I thought were removed via the config file are still appearing.

This works when I add values:

Code: Select all

<!-- Contributes values for outputclass attribute -->

    <match attributeName="outputclass">

        <items action="addIfEmpty">

            <item value="landscape"/>

            <item value="no_help_folder"/>

            <item value="nohyphenate"/>

            <item value="show_hide"/>

            <item value="show_hide_expanded"/>

        </items>

    </match>

But if I try to delete attributes from the menu (we don't want the writers to see the attributes at all), I cannot find a way to achieve that. Is there a way I can alter my existing frameworks extension to include the attributes as well? Here is what I was using in the config file:

Code: Select all

<elementProposals rejectAttributes="xtrf xtrc props base rev status dir role otherrole search class xml:space navtitle cols"/>

Thank you again,

Abby

Posted: **Fri Jan 20, 2017 3:47 pm**

Hi Abby,

Please make sure you have just ONE <elementProposals> element without a @path attribute. Can you send me the cc_config.xml file on support@oxygenxml.com so I can take a look at it?

Best regards,
Alex

Oxygen XML Forum

Distributing cc_config file, and effects

Distributing cc_config file, and effects

Re: Distributing cc_config file, and effects

Re: Distributing cc_config file, and effects

Re: Distributing cc_config file, and effects

Re: Distributing cc_config file, and effects

Re: Distributing cc_config file, and effects

Re: Distributing cc_config file, and effects

Re: Distributing cc_config file, and effects