Page 1 of 1
mini refresh on set/remove pseudoclass?
Posted: Thu Apr 01, 2021 1:41 am
by fjeneau
Hi,
I have a class that shows/hides tags based on whether or not a pseudoclass is applied to the root.
...
private static final String PSEUDOCLASS = "show-all-data";
...
doOperation...
AuthorElement root = adc.getAuthorDocumentNode().getRootElement();
boolean dataShown = root.hasPseudoClass(PSEUDOCLASS);
Show/hide is done via element.setPseudoClass(PSEUDOCLASS) and element.removePseudoClass(PSEUDOCLASS).
The issue is that these tags do not show/hide unless I do a full page refresh via authorAccess.getEditorAccess().refresh().
Is there a way to refresh at the element level or refresh only on the inserted fragment or am I missing a method that redraws just psuedoclasses?
Re: mini refresh on set/remove pseudoclass?
Posted: Thu Apr 01, 2021 8:48 am
by Radu
Hi,
You should toggle the pseudo class using the AuthorDocumentController API:
Code: Select all
adc.setPseudoClass(String, AuthorElement)
because it also takes care of triggering the appropriate listeners which update the UI.
Regards,
Radu
Re: mini refresh on set/remove pseudoclass?
Posted: Thu Apr 01, 2021 5:43 pm
by fjeneau
Thanks -- this worked.
The note on WSAuthorEditorPageBase -> refresh(AuthorNode authorNode), "Note: This should be called on the AWT thread because it will generate a layout event," can I assume that adc.setPseudoClass(String, AuthorElement) does that?
Re: mini refresh on set/remove pseudoclass?
Posted: Fri Apr 02, 2021 9:55 am
by Radu
Hi,
Most of our API is not thread safe. So if you have started a separate thread and want to use our API you can do something like:
Code: Select all
Runnable runnable = new Runnable() {
@Override
public void run() {
//Work with API here.
}
};
if(! SwingUtilities.isEventDispatchThread()) {
SwingUtilities.invokeAndWait(runnable);
} else {
runnable.run();
}
Regards,
Radu
Re: mini refresh on set/remove pseudoclass?
Posted: Thu Dec 16, 2021 11:03 pm
by fjeneau
The client has asked us to enable this macro in a read-only context. However, it takes up to 10 times as long for this operation to complete when the document is read-only.
Can you think of a reason why it would take so much longer in this context?
Would placing this on a separate thread prevent oXygen from essentially freezing while the operation is running?
Re: mini refresh on set/remove pseudoclass?
Posted: Fri Dec 17, 2021 9:57 am
by Radu
Hi,
I do not know exactly what your customization does. Do you call refresh on the entire document or on a certain node? Is it a large document or a node which contains lost of content? Do you call it a number of times?
Or do you call the API to set a pseudo attribute? Do you call it on many elements which have lots of content?
It is quite possible these refresh operations would take lots of time if called on large sections of a document or if called lots of time.
Regards,
Radu
Re: mini refresh on set/remove pseudoclass?
Posted: Thu Jan 27, 2022 8:33 pm
by fjeneau
I do not know exactly what your customization does. Do you call refresh on the entire document or on a certain node? Is it a large document or a node which contains lost of content? Do you call it a number of times?
Or do you call the API to set a pseudo attribute? Do you call it on many elements which have lots of content?
It is quite possible these refresh operations would take lots of time if called on large sections of a document or if called lots of time.
The macro was updated awhile back to only refresh on a node-by-node basis instead of the whole document.
The client did some more rigorous testing and found that the times were actually pretty similar between read-only vs. non-read-only. The 10x figure was simply because the last document they tested had over 1700 elements being hidden/shown at once. I think my question is actually a non-issue.
Re: mini refresh on set/remove pseudoclass?
Posted: Fri Jan 28, 2022 7:39 am
by Radu
Hi,
Ok, I'm not sure how to help further, sometimes when you have lots of nodes in the document it might become faster to refresh an entire document than to refresh each node individually.
Regards,
Radu