Load programmatically alternative CSS

[Johann]

Hello everyone,

In the last version of the oxygen SDK, is there a way to load programmatically an alternative CSS ?

My document has two CSS, a "normal" one and a "light" one. The light one is used to increase performance (indeed, with the "normal" one, the refresh of the page can take more than 30 seconds whereas with the "light" one it only takes 2 seconds).

So, for some actions, I would like to switch between these CSS "programmatically". I know there is the "CSSAlternativesToolbar" but I do not want the user to switch between the CSS.

Thanks for your help,

Johann

[Radu]

Hi Johann,

We do not have such API but we do have some plans for it so I added your feedback to the opened issue. I will update this thread when the issue is fixed.

As workarounds:

1) If your actions make multiple insertions and deletions in the document, we have special APIs which accelerate multiple changes:

AuthorDocumentController.multipleDelete(AuthorElement, int[], int[])

and:

AuthorDocumentController.insertMultipleFragments(AuthorElement, AuthorDocumentFragment[], int[])

So calling such APIs would be much faster than repeatedly inserting/deleting XML in various places. We use this API ourselves to insert table columns for example.

2) You can set a custom pseudo class on the root element:

authorDocumentController.setPseudoClass("fast", authorDocumentController.getAuthorDocumentNode().getRootElement());

and you can have special CSS selectors matching on this pseudo class which will get triggered like:

Code: Select all

::root:fast para {

  content: "";

}

and then remove the pseudo class at the end so that the specific selectors no longer match.

Regards,
Radu

[Johann]

Hi Radu,

In fact, even the refresh takes a long time on the document without performing any action...
In using pseudo class before opening my document (as you suggested), I have a "reasonable" refresh.

Thanks for your workaround,

Johann

[Radu]

Hi Johann,

My colleague Alex reminded me of two API methods which here added in 17.0:

Code: Select all

ro.sync.ecss.extensions.api.AuthorDocumentController.disableLayoutUpdate()

and:

Code: Select all

 ro.sync.ecss.extensions.api.AuthorDocumentController.enableLayoutUpdate(AuthorNode)

Basically if you call the disable layout update, then call our API to make changes, and then enable layout update you might not need any more the pseudo class approach. You need to call "enableLayoutUpdate" in a try{}finally block so that it is always executed no matter of what exceptions your code throws.

Regards,
Radu

[Johann]

Hi Radu,

I've just tested these two methods like this :

Code: Select all

try {

	authorDocumentController.disableLayoutUpdate();

	new InsertOrReplaceFragmentOperation().doOperation(authorAccess, argumentsMap);

} catch (Exception e) {

	LOGGER.error(e.getMessage());

} finally {

	authorDocumentController.enableLayoutUpdate(null);

}

Because I added

Code: Select all

authorDocumentController.disableLayoutUpdate();

I get this error on the InsertOrReplaceFragmentOperation :

Code: Select all

javax.swing.text.BadLocationException: Offset must be between 0 and 86 but was 18195

and the operation is not well performed.

Johann

[alex_jitianu]

Hi Johann,

Thank you for reporting this issue. It looks like when you disable the layout events, as an undesired side effect, the selection model and caret also remain stale. I will add an issue to resolve this problem. Meanwhile, if you still want to use disableLayoutUpdate() you'll have to directly use our API and make sure that you do not rely on the selection model once the update sequence begins.

Best regards,
Alex

[Johann]

Hello,

I would like to know if there is any update about the possibility to load programmatically an alternative CSS in the Author view ?

Thanks,

Johann

[Radu]

Hi Johann,

Sorry but we have not yet implemented such an API.
Just to recap this conversation, before a time consuming action is performed you want to switch the entire UI to using a custom imposed CSS and then after the action is performed to revert back to using the default CSS, right?

Regards,
Radu

[Johann]

Hi Radu,

In fact, the original need was to improve the performance of the authoring page. We found that some CSS properties are consuming, so we wanted to put them in a seperated CSS file and apply that CSS file on demand.
At last, we used pseudo classes to handle these CSS properties. It works but we do not know if the performance could be better if we load separately the "light" CSS file and the "normal" CSS file.

Johann

[Radu]

Hi Johann,

Thanks for confirming your use case. Even with the API you would not obtain faster editing than you do now with pseudo classes.
Sometimes CSS properties which are heavy (and they are usually the ones using oxy_xpath) could be maybe re-thought to use standard CSS selectors and sometimes you could try to use the optional evaluate parameter which can be passed to the oxy_xpath:

https://www.oxygenxml.com/doc/versions/ ... ction.html

Regards,
Radu