General XMetaL Discussion

XMetaL Community Forum General XMetaL Discussion How to batch apply pretty-printing to files?

  • paul_cpwr

    How to batch apply pretty-printing to files?

    Participants 0
    Replies 1
    Last Activity 10 years, 8 months ago


    On occasion, we use XSL scripts to apply global changes to our XML source. A unfortunate byproduct of this action is that the XSL transformations tend to destroy the pretty-printing that XMetaL applies to the source file. We'd like to invoke XMetaL on these files and re-save them to re-apply the pretty-printing. Since we transform hundreds or thousands of files at a time, we'd like to automate this step.

    I was going to leverage XMetaL's Java API for this task (I have XMetaL Developer 6 and Author 6.0.2). My plan is to create a custom Ant task that takes the set of files to re-save and then add the necessary XMetaL API calls to re-save them. A gross simplification of this process would be something like:
    app = new Application();
    docs = app.getDocuments();
    //for each file to process…
    new Document() doc = docs.Open(filename,2); //Open file in text-only view

    Does this sound about right? I suspect I'm not the only one who has tried this, so if you have a working sample available, I'd love to see it.

    Also, will the Document.Save() method force a save if the only changes are pretty-printing changes? I looked into forcing the issue via the Document.setSaved() method but it explicitly states that setting this to “false” has no effect. I also didn't see the “isDirty” method that I think I've used in the native XMetaL scripting API.

    Any feedback is appreciated.

    Best regards,

    Paul Anderson
    Compuware Corporation


    Derek Read

    Reply to: How to batch apply pretty-printing to files?

    What you have sounds about right to me. One thing you will need to be sure of is to not save from Plain Text view if you opened the file in Plain Text view. Pretty printing is only applied when you save from Tags On or Normal view, or when you switch from one of those views into Plain Text view. When you save from Plain Text view what is saved is what you see on screen.

    You will also likely need to dirty the document on purpose before you can save (as you say). XMetaL won't let you save a document that has just been opened (unless the customization it is using dirties it somehow).

    The alternative would be to do something like the following instead of a simple open and save. This should avoid needing to dirty the document.

    //for each file to process
    pick one of the next two:
    1: docAsString = “
    2: docAsString = Application.FileToString(pathToFile)
    tempDoc = Documents.OpenString(docAsString,1,”temp.xml”,false,true,false)

    I've never heard of anyone needing to do this before, so I don't have an example.

    It isn't clear to me why pretty printing needs to be applied after the transformation though. I guess you must have other 3rd party tools that are relying on the XMetaL prettying printing your CTM file has configured? Perhaps you are using some sort of DIFF tool that is not XML-aware (ie: can't tell you that two XML files are equivalent despite white-space differences)? Something else?

    XMetaL Author Enterprise and Essential 7.0 have a new “cross files” feature. If it was documented and supported for extension by clients I might recommend it, but it isn't yet. There is also a slight possibility the actual implementation might change slightly in the future. I mention it only because you may wish to watch out for it. It would provide two benefits:
    1) The infrastructure for deciding which files to process is provided, including a GUI, allowing you to select the files to work on without any coding required.
    2) The files can be loaded identically to loading them in the editor but without rendering them (relevant customization files can be loaded, including CTM for pretty printing, DTDs to resolve attribute values, etc) but the actual rendering does not take place. This makes operating on them much faster. Basically the idea is to provide similar capabilities to loading files into an XML processor like MSXML or Saxon, etc, while providing capabilities that XMetaL is good at (all standard APIs can be used).

    In 7.0 we have shipped a number of “cross-file operations” that use this infrastructure (Tools > Run Cross-File Operation) if you wish to see it in action. You would be on your own if you wish to try to take advantage of this infrastructure today however.


  • You must be logged in to reply to this topic.

Lost Your Password?