Relative file paths for ro.sync.ecss.css.URIContent.URIContent(String, String)

[SSC]

Hello,

we are using oXygen 14.1 Eclipse Version.

I am trying to use the ro.sync.ecss.css.URIContent.URIContent(String, String) in order to show a certain image.

Code: Select all

styles.setProperty(Styles.KEY_MIXED_CONTENT, new URIContent("file:./icons/","lock.gif"));

The lock.gif path is relative to the XML file, which is edited, but the image is not shown.
When using the absolute path it is shown correctly, but not with the relative one.
I also tried :

Code: Select all

new URIContent("file:","lock.gif"); // placing the lock.gif into the same location, where also the file is placed.

or

new URIContent("file:./","lock.gif");

or

new URIContent("file://","lock.gif");

Actually nothing really works, except of an absolute path.

Can you give me a hint, what I am doing wrong here?

Best regards,

Simon

[alex_jitianu]

Hello Simon,

The first parameter of the URIContent constructor must be an absolute system ID that will be used to resolve the relative reference. You said that the image is relative to the location of the XML file so you can get the absolute system id of the XML like in the code below:

Code: Select all


if (authorNode.getOwnerDocument() != null) {
String systemID = authorNode.getOwnerDocument().getSystemID();
try {
URL resolveRelativeSystemIDs = new URL(new URL(systemID), "icons/"));
URIContent value = new URIContent(resolveRelativeSystemIDs.toExternalForm(),"lock.gif");
styles.setProperty(Styles.KEY_MIXED_CONTENT, value);
} catch (MalformedURLException e) {
e.printStackTrace();
}
}

As a side note, I believe that you could have obtained the same behavior by just using CSS:

Code: Select all

node {
content: oxy_url(oxy_base-uri(), "/images/lock.gif")
}

Best regards,
Alex

[SSC]

Hello Alex,

I already use your second approach for a different framework/document type, but without oxy_url(oxy_base-uri(),..) by just using:

Code: Select all

[locked]:before{
content: url("icons/lock.gif") " [Locked by user " attr(locked) "]";
display: inline;
color: #FF5500;
background-color: #C2C2C2;
}

But in other cases we cannot have an extra attribute "locked" according to DTD restrictions, so we are using a PI inside the actual XML node, which defines the locked state.
Therefore I think I have to use the StylesFilter in order to find that PI and then modify the style, according to the text content of that PI.

Or is there an easy oxy custom CSS function, which is able to handle that?
But for now the solution with the StylesFilter by using your resolveRelativeSystemIDs approach works great.

As an aside we are really looking forward for a fix concerning the problem considered here:
http://www.oxygenxml.com/forum/topic7103.html#p22366

Because not only the border is too long, but also the background we set for locked items.
And also the :before statements are outside the visual tag so that we always have to use the display:line;, which is not desired, because the inline value also eliminates the line break after a :before node.

For us this bug would have the highest priority on our wishlist

Best regards,

Simon

[Radu]

Hi Simon,

The side-issue you mentioned is already fixed.
The :before and :after block children are now considered part of the parent (and the border is drawn around them).
Should I try to prepare an Oxygen 14.2 plugin beta kit for you just to make sure it covers what you wanted?

Regards,
Radu

[SSC]

Hello Radu,

if this is not too time-consuming for you I´d like to have such a beta 14.2 version.

Best regards,

Simon

[SSC]

Hello Radu,

thanks for the beta 14.2 version.
Its nice to see some new features like the highlighting....

I just tested the :before and :after issue and I say it is solved.

Thanks for that.

Best regards,

Simon

[SSC]

Hello,

just one little question:

When will oXygen 14.2 be released?

Best regards,

Simon

[Radu]

Hi Simon,

Oxygen 14.2 will probably be released in the early Spring of 2013.
You can look at our release history:
http://www.oxygenxml.com/history.html
to see when the X.2 versions were released.
I cannot guarantee a certain month or date of course.

Regards,
Radu

[SSC]

Hello Radu,

could you imagine to merge the Bugfix concerning the :Before elements into version 14.1?
Without this bugfix the border, which I add to certain elements is not completely right and therefore may confuse our customers.

Or would the merging process be too time-consuming?

As an aside: Nearly one year ago we moved from Subversion to GIT as our version control system. Thinks like merging with GIT has become really easy.

Best regards,

Simon

[Radu]

Hi Simon,

I discussed this internally but we cannot do this.
Usually minor bug fix releases are intended to fix critical bugs.
In this case the original :before and :after pseudo elements behavior was there for years and nobody complained.
And there are quite many modifications which would need to be ported and tested on the 14.1 branch.

Regards,
Radu