Enhancement request: default target file name

[skiwi]

When exporting a package,
or generating a document,
the default filename seems to be the last one used (ie entered in any similar dialogue box).

This is less than useful (because it seems to be the last one used for any package for any type of output) because of the risk of overwriting a non related output.

It would be more useful (and safer) if the filename was the package or diagram name, or better the last file name used for this specific local package.

[Geert Bellekens]

I've been annoyed by this one too, but I still feel this is a cosmetic one with a low priority.

Geert

[«Midnight»]

This pattern shows up in several places throughout EA. Like this case some are annoyances to a greater or lesser extent.

This seems to be associated with settings that EA stores in the repository. These become global in nature even if the intent is (or should be) otherwise. An example is the default DBMS language. If this is set to a 'new' DBMS (i.e. one that is identified in a recent update to reference data) then older projects (that do not have the new reference data) 'forget' their DBMS setting, causing chaos when updating models.

In other cases this information is embedded in seed models that are stored in hard-coded locations in the EA install path. Users might not be able to change these files; even if changes can be made they may have to be revisited after new EA builds are installed. A case in point is the Default Language for Code Generation. This setting can wreck havoc in projects where Java is not the target language.

In others the result can be meaningless settings with significant danger of catastrophe. In some cases this pattern causes EA features not to work, or to produce incorrect results. A case in point for both these observations is the most recent schema name (i.e. the target for USE statements) for DDL. This is preserved across all data model packages and diagrams in a model, rendering subsequent DDL generated for other schema to be incorrect. Worse still, the resultant code generally does not fail outright, but corrupts the target database (if the earlier USE statement had a valid target).

The above DDL setting is also preserved across models. Thus previously correct models suddenly generate code with a different USE statement; the target might be meaningless to the database involved, but if the two models target the same server instance this can result in disaster. And if two models have different DBMS language settings the USE clauses can become a major annoyance.

Yes, I've reported this to Sparx, since EA 7.0. I have received no response whatsoever.

Sigh...

[skiwi]

I don't consider these issues to be trival (otherwise I wouldn't take the time and trouble to report then).

They go to making the tool natural and easy to use,
through consistency, use of common and conventional UI metaphors, the "principle of least surprise" - ie it does what you expect it to do,
there is ease of use (ie keep clicks, data entry, to a minimum, menus and options can be found easily, help is in context and explanatory,  defaults are sensible, and actions do not have side effects).

Of course in a complex tool like EA we are not looking for lowest common demonimator, it is a complex and powerful tool,
but we can and should expect a well thought out user interaction (and especially so in a tool that is all about objects {does it eat its own dog food?}) that leads us to the result we want,
rather than frustrates untils we learn the 'tricks'.
In other work each UI inteaction should be given the same scrutiny and discussion as implementation of a facet of UML.

[«Midnight»]

Methinks the man makes sense!