[oXygen-sdk] Custom editor variables in CSS

[Alex Jitianu]

Hi Nathan,

In order to be sure, I've also tested ${frameworkDir} in the CSS and I 
obtained the expected result: we don't expand it to the framework 
directory. For your CSS rule at least, it is as if you don't have 
${frameworkDir} at all. The system id of the CSS is used as the base URI 
and I'm guessing that the relative path '../../../../../' it's actually 
relevant starting from the location of the CSS.

I'm guessing there is nothing in the XML instances that differentiates 
between different versions? Possible solutions:

1. From an Workspace Access [1][2] plugin you can add an URIResolver, 
intercept the CSS resolving [3] and resolve there the editor variables:

   /**
    * @see 
ro.sync.exml.plugin.workspace.WorkspaceAccessPluginExtension#applicationStarted(ro.sync.exml.workspace.api.standalone.StandalonePluginWorkspace)
    */
   @Override
   public void applicationStarted(final StandalonePluginWorkspace 
pluginWorkspaceAccess) {

pluginWorkspaceAccess.getXMLUtilAccess().addPriorityURIResolver(new 
URIResolver() {
       @Override
       public Source resolve(String href, String base) throws 
TransformerException {
         System.out.println("href " + href);
         if 
("http://www.oxygenxml.com/extensions/author/css/userCustom.css".equals(href)) 
{
           String versionPath = 
pluginWorkspaceAccess.getUtilAccess().expandEditorVariables("${test}", 
null);
           String frameworkURL = 
pluginWorkspaceAccess.getUtilAccess().expandEditorVariables("${framework}", 
null);

           String imageURL = frameworkURL + versionPath + "/";
           return new StreamSource(new StringReader(
               "*[class~=\"topic/image\"][href]{\n" +
               "    content:oxy_url('" + imageURL + "', 'attr(href)');\n" +
               "}"));
         }
         return null;
       }
     });

This goes hand in hand with your idea to tell the user to change a 
custom editor variable in options and then perhaps perform a refresh in 
the editor.

2. This idea is based on a custom form control implementation [4]. You 
add this this form control, for example, on the root of the document. In 
this form control the user writes something that identifies the version 
of the document. The form control saves this value in a fake attribute 
using the API :

authorAccess.getDocumentController().setAttribute("myVersion", new 
AttrValue("patch21", "patch21", false), element);

The CSS must contain a rule that uses that attribute, something like this:

*[myVersion] *[class~="topic/image"][href]{
     content:oxy_url('${frameworkDir}', '../../../../../', 
oxy_xpath('/topic/@myVersion'), 'app/main/core/sfdc/htdocs/img/', 
attr(href));
}

If you are interested I can send you the source code for the built-in 
text field form control. It would take minimal changes to make it behave 
like above.


[1] 
http://oxygenxml.com/doc/ug-editor/#concepts/workspace-access-plugin.html
[2] http://www.oxygenxml.com/oxygen_sdk.html#Developer_Plugins
[3] http://oxygenxml.com/doc/ug-editor/#references/handling-css-imports.html
[4] 
http://oxygenxml.com/doc/ug-editor/#topics/implementing-custom-form-controls.html

Best regards,
Alex
-- 
Alex Jitianu
<oXygen/>  XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

On 13-May-14 3:32 AM, Nathan wrote:
> Hi Alex,
>    Here is the use case scenario I am targeting:
>
> In the CSS, I have
>
> *[class~="topic/image"][href]{
> content:oxy_url('${frameworkDir}', '../../../../../', 
> 'app/main/core/sfdc/htdocs/img/', attr(href));
> }
>
> Here, the built-in variable "frameworkDir" works fine. The above path 
> is valid when the file is in the "main" branch.
> When the input xml file is in another branch (say "/patch/21"), I 
> would like to change the "app/main/core...." to "app/patch/21/core...".
> My first idea was to have a custom variable defined (say $BRANCH) 
> which would be set to "/main" by default and could be reset to 
> "/patch/21" by the user when they change the branch.
>
> However, while the built-in variable was accepted, the custom variable 
> is not accepted here. Also, with respect to creating pseudo classes, 
> it would be a maintenance issue since I would need to put in every 
> release number (since theoretically XML files from any release could 
> be opened) in the CSS and also the CSS would need to be updated after 
> every release.
>
> Could you provide some alternatives?
>
> Thanks,
> Nathan
>
>
>
> _______________________________________________
> oXygen-sdk mailing list
> oXygen-sdk at oxygenxml.com
> http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.oxygenxml.com/pipermail/oxygen-sdk/attachments/20140515/4c32fb79/attachment.html>