I did a little more investigating on using the underlying .js files from different sites, and they appear to work seamlessly. As you can see from the source for orm.aspx, this uses three .js files, which I would recommend you reference directly from my site so that they get updates (and, frankly, because ORM Solutions owns the copyright). So, to get an .orm viewer running on your site, you need to reference the three js files shown in orm.aspx using absolute URLS, as shown below.
If you use the raphael rendering library for other things in your site then you obviously don't need my file. I'm currently using version 2.0.1.
<head>
<style type="text/css">
@media print {
table#info {display:none}
}
</style>
<script src="http://ormsolutions.com/tools/js/raphael.js" type="text/javascript"></script>
<script src="http://ormsolutions.com/tools/js/ormMin.js" type="text/javascript"></script>
<script src="http://ormsolutions.com/tools/js/ormViewMin.js" type="text/javascript"></script>
<script type="text/javascript">
window.onload = function () {
window.ormViewer.attach({
name: "view", // This is the name used to refer to this ORM pane. Use a different name for each viewer to view multiple panes
infoTable: "info", // This matches table with id 'info' in the body
fileName: "YOURFILE",
paper: "diagramPaper" // This matches the div with id 'diagramPaper' in the body corresponds to diagramPaper div in the body
});
};
</script>
</head>
<body>
<table id="info">
</table>
<div id="diagramPaper"></div>
</body>
Available fields for the object passed to the ormViewer.attach method (bolded name indicates a required field):
-
name: The name of the pane for attaching the orm viewer. Should be different for each call to attach, and a simple name (no spaces, etc.)
-
paper: The name of the div used to host the diagram. Corresponds to the id of a div element in the html
-
fileName: This comes in three forms.
-
An empty string means that a local file will be loaded (browser support required, Chrome, FF, IE10)
-
A relative path loads an .orm file relative to the current page (leave off the .orm, this is assumed)
-
A full URL (including the .orm) references an external URL, which must give permission as discussed in
http://ormsolutions.com/remoteViewing.aspx. Note that you must specify 'infoTable' or 'fileInput' fields for this to work.
-
initialDiagram: The name or guid of the diagram to select when the file is loaded
-
userScale: A scaling value for the diagram itself. This is multiplied by the page zoom and the zoom dropdown, but allows you to adjust the diagram scale without zooming the page. 1.2 is the closest to default NORMA zoom and is the default.
-
infoTable: A table to hold information about the displayed diagram. This table contains the model and diagram names, zoom level, and diagram picker dropdown. If you set this, the following elements are all created automatically as part of the information table, but you can use your own controls by providing an id. Providing a null value for these elements hides them.
-
header: Provides status information during load and the model name afterwards.
-
nameDisplay: Shows the current diagram name and triggers the diagram name dropdown.
-
diagramLinks: The control holding the diagram names. Clicking these names activates the selected diagram.
-
zoomSelect: The dropdown used to pick the zoom states.
-
zoom: The zoom picture beside the zoomSelect button.
-
filterButton: The button used to open the diagramLinks list of diagrams.
-
filterText: The text box used to type in a diagram filter name (highlights matching diagram names in the diagramLinks control).
-
filterContainer: The container used to hold the diagramLinks and filterText elements.
-
fileInput: The name of a file input control. Used when fileName is "" to load a local file.
-
infoPrefix: If set, a name to append to the ids of automatic controls generated for infoTable. Use to display multiple infoTables on one page.
-
reduceSingleDiagram: Set to true to hide all diagram fields if the model contains exactly one diagram
Wrapup:
So, the bottom line is that you can easily display .orm diagrams in your own pages using minimal code and do not need to use heavy weight and static graphics. The entire viewing framework (raphael and my two files) totals less than 250k, which is likely smaller than the .png for a large diagram, plus you get live diagrams (right click to find a shape on another diagram, switch diagram pages, vector graphic 'no fuzz' scaling, etc). The diagrams are a little slow and rough on IE<9 because of the lack of SVG support, but I think most of us are using other browsers at this point. For svg-enabled browsers the diagram load and rendering is almost instant (much faster than NORMA).
I use the .aspx part of the page to fill in the ormViewer fields, so there isn't much to it that you don't see in 'view source'. My general approach is to keep the viewer files unsecured and add security to the orm file directories, then use UrlAuthorizationModule.CheckUrlAccessForPrincipal on the requested file name when the viewer is called, with a Response.Redirect to a login page if the caller does not have permissions (watch out for ../ lead text, CheckUrlAccessForPrincipal requires ~/ instead). Obviously, this will be different for every site and web server, but it is only a couple of lines of code in aspx.
The backing code for ormPrint.aspx (all diagrams on one page) is not yet nicely packaged like this, so I wouldn't recommend trying to integrate it locally at this point.
This is actually part of a web-based editing framework designed for web-hosted editing and collaboration on model files, not just viewing. These more advanced features will run under a different business model, but the file viewers (including future extensions, like live browser verbalization) will remain freely available. I can currently do 'cheat' verbalization by dumping all of the verbalizations from a model file (with hyperlinks and styles tweaked to run with this framework) into a database, then ajax loading them as the selection changes. However, this is a large amount of raw data for both the db and wire, so is not a long-term solution and not something I'm sharing publicly at this point.
Let us know if you're able to do this. You should be able to prototype in a few lines of code.
-Matt