Load programmatically alternative CSS

Post here questions and problems related to oXygen frameworks/document types.
Johann
Posts: 89
Joined: Wed Jun 17, 2015 12:46 pm

Load programmatically alternative CSS

Post by Johann » Wed Sep 07, 2016 3:39 pm

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
Posts: 6582
Joined: Fri Jul 09, 2004 5:18 pm

Re: Load programmatically alternative CSS

Post by Radu » Thu Sep 08, 2016 8:13 am

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
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

Johann
Posts: 89
Joined: Wed Jun 17, 2015 12:46 pm

Re: Load programmatically alternative CSS

Post by Johann » Fri Sep 09, 2016 6:27 pm

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
Posts: 6582
Joined: Fri Jul 09, 2004 5:18 pm

Re: Load programmatically alternative CSS

Post by Radu » Mon Sep 12, 2016 9:04 am

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
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

Johann
Posts: 89
Joined: Wed Jun 17, 2015 12:46 pm

Re: Load programmatically alternative CSS

Post by Johann » Mon Sep 12, 2016 11:41 am

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
Posts: 705
Joined: Wed Nov 16, 2005 11:11 am

Re: Load programmatically alternative CSS

Post by alex_jitianu » Tue Sep 13, 2016 12:27 pm

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
Posts: 89
Joined: Wed Jun 17, 2015 12:46 pm

Re: Load programmatically alternative CSS

Post by Johann » Fri Sep 13, 2019 11:53 am

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
Posts: 6582
Joined: Fri Jul 09, 2004 5:18 pm

Re: Load programmatically alternative CSS

Post by Radu » Mon Sep 16, 2019 3:54 pm

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
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

Johann
Posts: 89
Joined: Wed Jun 17, 2015 12:46 pm

Re: Load programmatically alternative CSS

Post by Johann » Wed Sep 25, 2019 3:48 pm

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
Posts: 6582
Joined: Fri Jul 09, 2004 5:18 pm

Re: Load programmatically alternative CSS

Post by Radu » Thu Sep 26, 2019 10:55 am

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
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

Post Reply