General XMetaL Discussion
hico February 20, 2018 at 12:28 pm
XMetaL Customization – DeploymentFebruary 20, 2018 at 12:28 pmParticipants 2Replies 3Last Activity 4 years, 11 months ago
We have installed XMetaL Developer recently. The output of a customization project is, e.g., a .mcr and a so called .xac. So, how do I deploy the .xac? If I copy the .mcr in the “Startup” folder, the .mcr seems to run, I also can debug it with “debugger” keyword, as I read here. But what about the .xac? I did not find anything about .xac deployment in the developer and customization guides and would be very thankful for your assistance. Kind regardsDerek Read February 20, 2018 at 7:11 pm
Reply to: XMetaL Customization – DeploymentFebruary 20, 2018 at 7:11 pm
It sounds like this is an application-level customization. In that case you can ignore the XAC file. Both are built just because that is how XMetaL Developer was designed but the XAC file isn't really useful. You can consider your application-level customization to consist of the MCR file itself (unless it calls other code like an XFT form or a DLL that you need to deploy as well).
XAC files are ZIP files containing a copy of whatever was “built” when you select build in Visual Studio, together with a manifest that lets XMetaL Author know what to do with the file(s). A XAC is (arguably) slightly more useful for a document-level customization where your customization consists of DTD/XSD/RLX/RLD, CSS, CTM, MCR, XFT and possibly other files. All of those files are zipped into a single XAC file. When that file is read by XMetaL Author (or XMAX) it is first unzipped to a temp folder then all the files are read in as they would be if opened directly. The single benefit (if you can call it that) is that you can then deploy a single file. However, this can add to the complexity of debugging issues, and it makes it much more difficult to tweak a customization after deployment.
I did a webinar a few years ago on customization deployment. The accompanying document that describes the subject in detail now lives here: https://www.slideshare.net/XMetaL/deploying-schemas-and-xmetal-customization-fileshico February 21, 2018 at 9:47 am
Reply to: XMetaL Customization – DeploymentFebruary 21, 2018 at 9:47 am
Thanks for your advice! That sounds like we've done everything fine till now, we use XMetaL API in a dll, which seems to work. If we have more than one Macro, all macros are packed into the .mcr build by XMetaL Developer, right?
The thing is…we have a lot of different schema DTDs. How can we deploy these? In the past, we handled this with the help of a catalog file, that referenced sub-catalog files and so on, so that referenced schema DTDs could be resolved. I know that there's a catalog in “Rules” folder, but can I reference my own catalog in any way? Or does I have to build my own document level customization for every schema DTD? How would I deploy the .xac, that means, in which folder do I have to place it, or reference it?
We are on the very beginning of our customization, so, sorry for your time.Derek Read February 21, 2018 at 7:58 pm
Reply to: XMetaL Customization – DeploymentFebruary 21, 2018 at 7:58 pm
You can put multiple macros into one MCR file or you can build multiple MCR files. If installing to a single machine the result is basically going to be the same, though loading order of macros may differ depending on the filename of the MCR files.
To XMetaL, each schema (DTD or XSD) is the basis for a single document-level customization. It loads the XML file, finds the DTD or XSD file (see the document I referenced previously for a very detailed description of how a DTD or XSD is found) then all other files needed to render the display of the XML file and provide UI interaction are loaded (this includes CSS, CTM, MCR and possibly other files). The minimum is CSS and CTM but there are over 1000 APIs you can use to customize how users interact with the XML and the main UI of the application, and what happens for many many events.
You can either add your entries to the catalog file or add your own catalog file(s) and reference them from the XMetaL catalog file. The software needs to start looking somewhere and it uses its own catalog file to do that.
However, there are many other ways to find your schema (see the document I referenced previously for a very detailed description). Some options:
1. Place your DTD/XSD any other files in the same folder as your XML file or nearby, perhaps in a subfolder, sibling folder, etc, then in the XML file's DOCTYPE declaration or SchemaLocation point to the DTD/XSD using a relative path.
2. Place your DTD/XSD file in the Rules folder. This is where XMetaL looks for schemas when it can't find them using any other method. This is by far the simplest solution as it means you can have literally any random value in the XML for DOCTYPE or SchemaLocation and if XMetaL can't find the file there it looks in the Rules folder and loads everything from there.
3. Add catalog entries for each of your DTDs, then set a unique PUBLICID value in each of your XML files XMetaL Author can use to find them based on the catalog entries.
3. Some CMS systems have the capability to manage and deploy customization files for XMetaL Author. The vendor can tell you if this is the case and how to configure that.
4. Create a macro that overrides all of the above, parses the XML file (using some external process) and then tells XMetaL Author where to look for the DTD by overriding the SYSTEMID value. This gives you absolute control but is overkill 99.9% of the time.
- You must be logged in to reply to this topic.