v15.2 - HTML Generation (on Enterprise scale)

[Paolo F Cantoni]

I know this kind of question has been tackeld before, but I thought it might be useful to "checkpoint" what is possible in v15.2.

So, as we know, HTML generation is the generation of a branch of the repository.  In order for any linkages (such as attached (composite structure) diagrams, hyperlinks etc.) to operate, the targets have to be within the same branch.

Has anybody managed to find a solution using only HTML generation (plus some HTML "munging)" to allow multiple branches to be generated independently.

In any serious enterprise-wide repository, multiple branches would seem to be a requirement.

I realise all the things I want to do can be done by other means (typically requiring further licenced products), but, for the present,  I'm just trying to evaluate what can be done with HTML output.

TIA,
Paolo

[philchudley]

Hi Paolo

What I did for a client with the same request was to create a script using the AIP function

RunHTMLReport (string PackageGUID, string ExportPath,string ImageFormat,string Style,string Extension)

In order to process the section of packages (assuming they can be selected at the same level), I processed the Repository.CurrentSelection, for which I wrote a tutorial on the Sparx Community.

Hope this helps in some way

All the best

Phil

[Geert Bellekens]

IIRC you can also use virtual documents to select exactly which package branches need to be exported to HTML.

I'm not aware of any solution that allows to connect independently generated HTML exports.

Geert

[Paolo F Cantoni]

IIRC you can also use virtual documents to select exactly which package branches need to be exported to HTML.

I'm not aware of any solution that allows to connect independently generated HTML exports.

Geert

(my emphasis)
That functionalityis what I'm really after.  We have separated the items on the diagrams from the diagrams themselves (a form of separation of concerns).

We need to export the diagrams but would like to also export the item branches so users can double-click a diagram object and open the item as they can in the product itself.  The trouble is the branches are often far apart.

Paolo

[Paolo F Cantoni]

Hi Paolo

What I did for a client with the same request was to create a script using the AIP function

RunHTMLReport (string PackageGUID, string ExportPath,string ImageFormat,string Style,string Extension)

In order to process the section of packages (assuming they can be selected at the same level), I processed the Repository.CurrentSelection, for which I wrote a tutorial on the Sparx Community.

Hope this helps in some way

All the best

Phil

Thanks, Phil,
Unfortunately, the branches are not at the same level.  I suspect Geert's virtual documents may be the way to go.

Paolo

[adepreter]

Why not simply putting everything that needs to be published under one root?
It is convenient to put all items that needs to be published under one root and the rest under other roots.

[Paolo F Cantoni]

Why not simply putting everything that needs to be published under one root?
It is convenient to put all items that need to be published under one root and the rest under other roots.

Hi Alain,

Because the published elements are needed in other roots also.  It's like children, you shouldn't have a favourite.

Besides, since we have "neighborhood" diagrams which allow you to "fly through the model n-space" the number of required items grows exponentially if we wanted to give users a meaningful experience.

Paolo

[Uffe]

Hello,


Looking at the implementation of Model Documents, if you drag-n-drop a package onto a «model document» class, the resulting attribute has its Type property set to "Package" and, behind the scenes, its Classifier set to the Object_ID of the package element.
This is clearly a kludge, since you can't select a package if you bring up the attribute's Select Type dialog (you must select a non-package classifier).

Since it is a kludge, it might not be beyond the pale to suggest it is changed to set the attribute's Classifier to the package's Package_ID instead.
Clearly the intent is to reference a package, not an element. So probably the first thing EA does when generating a document (HTML or RTF) out of a «model document» is to look up the package that corresponds to the referenced element Object_ID, whether by matching the GUID or PDATA1, and then proceeding with that package.

If that is the case, changing that snippet of code to directly look up the package instead of going through the element should be easy.

Now EA doesn't allow you to drag-n-drop a root node onto a diagram, and presumably allowing that would bring a host of other problems that Sparx would prefer not to deal with.

But if they can change the handling of the «model document»s' "Package" attributes, you could then write a script which adds such an attribute, referencing a root node, to a «model document».

If there are backward-compatibility issues with this solution, they could just add a new type of attribute for proper package references; call it "PackageRef" or some such (since "Package" is already taken).


/Uffe

[Paolo F Cantoni]

Thanks, Uffe,

Most interesting!  Sounds like a good idea to me.

However, to be clear my need is not to access many root nodes, but to access package branches IN many nodes.  Also, we have the need to be able to publish each of the branches separately, but have the items accessible between branches.

For example, because we have separated the Views from the Items, we have two branches.  The diagrams in the View branch may not have changed, but the items' neighborhood diagrams may have changed (the neighborhood diagrams are nested under the item in the browser).  Consequently, we want to republish the Item branch, but leave the View breach as before.

Our, compressed, .eapx snapshot files (from our SQL Server repository) are over 1GB so that indicates the number of items and diagrams that might have to be HTML generated.

Paolo