Page 1 of 1

Define which attributes may be edited

Posted: Tue Aug 21, 2012 3:34 pm
by SSC
Hello,

our customers want some attributes in some XML tag to be not editable for an author, because they are set by a xml transformation and should not be modified by the author afterwards.

I found these methods for a CIAttribute, but I am not sure, if that is what I actually want:
http://www.oxygenxml.com/InstData/Edito ... ixed%28%29

and

http://www.oxygenxml.com/InstData/Edito ... boolean%29

Is it maybe possible to define, which attributes may be modified?

Thanks in advance.

Best regards,

Simon

Re: Define which attributes may be edited

Posted: Tue Aug 21, 2012 4:13 pm
by Radu
Hi Simon,

We do not have API to prohibit editing in the Author page certain attributes.
But we have API which would allow you to filter completely from the Attributes view certain attributes:

Code: Select all

ro.sync.exml.workspace.api.editor.page.author.WSAuthorEditorPageBase.addAuthorAttributesDisplayFilter(AuthorAttributesDisplayFilter)
Would hiding those attributes completely from the user in the Author page be enough?

Regards,
Radu

Re: Define which attributes may be edited

Posted: Mon Oct 15, 2012 11:58 am
by SSC
Hello Radu,

the discussion about editable attributes just came up again and it seems that hiding the attributes is not enough, because the authors/users should see which attributes are set, but they should not be allowed to edit them.

The same issue came up with PIs, which also should be seen by the authors/users, but not be edited by them.

Could you please open a feature request in your internal system concerning the definition of non editable elements or attributes?

Best regards,

Simon

Re: Define which attributes may be edited

Posted: Mon Oct 15, 2012 12:22 pm
by Radu
Hi Simon,

We have some existing API which would allow you to avoid setting the attribute to a different value.
The code is something like:

Code: Select all

      WSAuthorEditorPage authorEditorPage = ...;
authorEditorPage.getDocumentController().setDocumentFilter(new AuthorDocumentFilter() {
/**
* @see ro.sync.ecss.extensions.api.AuthorDocumentFilter#setAttribute(ro.sync.ecss.extensions.api.AuthorDocumentFilterBypass, java.lang.String, ro.sync.ecss.extensions.api.node.AttrValue, ro.sync.ecss.extensions.api.node.AuthorElement)
*/
@Override
public void setAttribute(AuthorDocumentFilterBypass filterBypass, String attributeName,
AttrValue value, AuthorElement element) {
//You could decide not to call SUPER if the attribute should be not editable, maybe also show a small error dialog.
super.setAttribute(filterBypass, attributeName, value, element);
}
});
The user would start editing the value, then he would press ENTER to commit it then this filter would get called and you would have a way of ignoring the new value.
If would be a little misleading because the Attributes table would still allow the user to edit the values but when he would try to commit a value you could ignore the inserted value.

[quote]The same issue came up with PIs, which also should be seen by the authors/users, but not be edited by them.[quote]

Actually the same AuthorDocumentFilter has callbacks like insertText or delete. Maybe on such callbacks you could look to see if the text is inside a certain PI.

Or you could add a selector in the CSS for the PIs which would make it not editable:

Code: Select all

-oxy-editable:false;
.

In Oxygen 14.1 you will also be able to match certain PIs in the CSS by specifying the PI target or some custom attributes or their values.

Regards,
Radu

Re: Define which attributes may be edited

Posted: Tue Dec 04, 2012 8:27 pm
by SSC
Hello,

concerning the solution with the AuthorDocumentFilter.

Is there a possibility to attach such an AuthorDocumentFilter via an Extension for a certain DOCUMENT TYPE?
Now we´d like to prohibit change of a certain attribute, but only for a certain DOCUMENT TYPE.

I imagine an Extension where the AuhthorAccess is passed in, like it is done in an com.oxygenxml.editor.editors.author.AuthorDnDListener, which is invoked once a document of the DOCUMENT TYPE is opened.

Now if I would like to attach a AuthorDocumentFilter, I would have to check somehow which DOCUMENT TYPE is currently used.

Is there an easy way to find out the DOCUMENT TYPE in case you do not have such an extension point I´d mentioned before?

Best regards,

Simon

Re: Define which attributes may be edited

Posted: Wed Dec 05, 2012 11:43 am
by Radu
Hi Simon,

No to both I'm afraid.
For the second approach would the name of the document type be enough for you? Maybe I could add an API request for this.

Probably as a workaround you can create a reader over the editor content WSEditorBase.createContentReader() and look a little at the header to see what type of document it is.

Regards,
Radu

Re: Define which attributes may be edited

Posted: Wed Dec 05, 2012 3:48 pm
by SSC
Hello Radu,
Radu wrote:For the second approach would the name of the document type be enough for you? Maybe I could add an API request for this.
Yes, for now this would be enought.

Nevertheless I would really appreciate to have a Extension in the DOCUMENT TYPE ASSOCIATION which will be invoked, when an editor is opened, in order to initialise the editor instance.

I imagine something like :

Code: Select all


public interface IInitialiseOpenedEditor(ro.sync.ecss.extensions.api.AuthorAccess authorAccess){
// do init stuff
}
For now I am forced to use an org.eclipse.ui.IPartListener and override the partOpened() method and use the WSEditorBase.createContentReader() in order to find out, which DOCUMENT TYPE is used.

Best regards,

Simon

Re: Define which attributes may be edited

Posted: Thu Dec 06, 2012 3:18 pm
by Radu
Hi Simon,

[quote]Nevertheless I would really appreciate to have a Extension in the DOCUMENT TYPE ASSOCIATION which will be invoked, when an editor is opened, in order to initialize the editor instance.[quote]

If you edit the DITA document type in the "Document Type Association" preferences page, in the Extensions tab there is an extension called Author Extension State Listener.
This kind of listener must implement the API ro.sync.ecss.extensions.api.AuthorExtensionStateListener which is notified each time the Author page gets selected.

Such an extension can also be implemented from the ExtensionsBundle side, for example in the ro.sync.ecss.extensions.dita.DITAExtensionsBundle.getUniqueAttributesIdentifier()

The extension that you set individually in the Extensions list will overwrite the one created in the ExtensionsBundle. For DITA the currently created Extension State Listener is used to automatically generate IDs when certain elements (like tables, lists, etc) are inserted.

Regards,
Radu