mini refresh on set/remove pseudoclass?

[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?

[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

[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?

[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

[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?

[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

[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.

[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