Oxygen 16.0: css-link overwrites oxy_button

[Patrik]

Hi,

i have added some buttons by css to the header of references:

Code: Select all

oxy|reference[href]:before {

	content: 

		url(../img/editContent.gif) 

		oxy_label(...) 

		oxy_button(actionID, "refresh.reference", transparent, true, showIcon, true)

		oxy_button(actionID, "reference.expand.this", transparent, true, showIcon, true)

		oxy_button(actionID, "reference.expand.all", transparent, true, showIcon, true)

		oxy_button(actionID, "reference.collapse.this", transparent, true, showIcon, true)

		oxy_button(actionID, "reference.collapse.all", transparent, true, showIcon, true)

		!important;

}

This worked fine in oxygen 15.2. Now with oxygen 16.0 when clicking any of the buttons the corresponsing action is no more being executed but the referenced file is opened.

An idea for a workaround would be to no more use the css-link but have another oxy_button that opens the referenced document. However, I can't find a way to remove the link-property that is set in the built in stylesheet!?

Thanks and regards,

Patrik

[alex_jitianu]

Hi Patrik,

This is indeed a bug. I've added an issue and we will fix it in a next 16.0 maintenance build. Unfortunately the bad news don't stop there. Another change in v16.0 is that buttons added in a read-only context (and a reference is read-only) are also read-only... So even if you would succeed in overriding the link property, the buttons still wont be usable. I admit, that's not the ideal behavior because the action associated with the button could execute itself in a different, valid context. What kind of actions have you added on oxy|reference[href]:before? Would it be possible for you to move them on the xi:include element instead?

Code: Select all

xi|include:before {

   content:

      oxy_button(actionID, "refresh.reference", transparent, true, showIcon, true)

      oxy_button(actionID, "reference.expand.this", transparent, true, showIcon, true)

      oxy_button(actionID, "reference.expand.all", transparent, true, showIcon, true)

      oxy_button(actionID, "reference.collapse.this", transparent, true, showIcon, true)

      oxy_button(actionID, "reference.collapse.all", transparent, true, showIcon, true)

      !important;

}

I'm asking because the buttons enable/disable behavior changing might prove a bit more difficult to correct in a v16.0 build. So if you have an workaround, I think I would prefer to correct it in v16.1.

Best regards,
Alex

[Patrik]

Hi Alex,

these buttons are not only for xinclude but also in other references (e.g. my self-implemented xslt-conref). Moving the buttons one level up would only lower the problem rather than solving it since one referenced content might contain another. For instance an xincluded file can an xslt-conref or another xinclude.

Nevertheless, for now I removed the content from oxy|reference:before and added it to xi|include and my other references and this works. (Yet, without a way to jump to the referenced file but this should be simple to add as a new AuthorOperation.)
BTW: xi|include:before has no effect but with xi|include it looks exactly as it should.


Actually I like the idea that operations in read-only content are not available and there are other cases where it's on my todo list to remove/disable these when beeing inside a reference.
However, all the actions I've added are no operations modifying the document at all:

• refresh.reference: simply calls

  Code: Select all

  authorAccess.getDocumentController().refreshNodeReferences(nodeAtCaret);

• reference.expand/collapse.this/all: marks the current reference / all references (of this kind) as expanded/collapsed (stored within a java-singleton that is asked by the reference resolver) and refreshes it. A collapsed xinclude will be reduced to the first title element and an xslt-conref will be hidden at all.

All these actions seem pretty useful in general - not only for my application.

So possibly the problem is that I'm using an author operation for something it is not intended for. (Another indication for this theory is that these operations always generate an undo-action and mark the document as modified while no modification occurs).
So I could think of following solutions:

• A new kind of NotModifyingAuthorOperation: no undo, not marking the document as modified, not disabled within read-only content.
• Using some other feature I'm not aware of yet.
• If you agree on the general use (I think there exists an issue for collapsing xincludes) these features could be built into oxygen.

BTW: When the buttons are disabled I'd expect them to be grayed and having the hover effect being deactivated!? Right now the buttons just don't have any effect but the user doesn't see it.

Thanks and regards,

Patrik

[alex_jitianu]

Hi Patrick,

Moving the buttons one level up would only lower the problem rather than solving it since one referenced content might contain another. For instance an xincluded file can an xslt-conref or another xinclude.

Actually I think that for nested references, the buttons were always disabled. So as far nested references go, I don't think you lost any functionality.

BTW: xi|include:before has no effect but with xi|include it looks exactly as it should.

I tried it myself and I was able to add buttons of the before of an xi|include. Maybe you should try and use a more powerful selector, maybe xi|include[href]:before. And don't forget the !important flag (the default rules have one).

So possibly the problem is that I'm using an author operation for something it is not intended for. (Another indication for this theory is that these operations always generate an undo-action and mark the document as modified while no modification occurs).

This is not an issue of the AuthorOperation per se, but of choosing which code to invoke in the operation. refreshNodeReferences(nodeAtCaret) generates changes in the document that are recorded for UNDO and I don't think there is much else we can do. This kind of situations may happen when using the API in general(the API is used for actions that the user must not UNDO) but we so far we have no solution.

BTW: When the buttons are disabled I'd expect them to be grayed and having the hover effect being deactivated!? Right now the buttons just don't have any effect but the user doesn't see it.

You are correct! I've added an issue to make the button also look disable too.

Best regards,
Alex