Raise an error if function name is blank for New Plugin Model (Trac #770)

[pkienzle]

There is no error if the new plugin model name is blank, but the resulting function won't show up in the list of custom models.

Default the name to blank so that the user is required to provide a meaningful name.

Migrated from http://trac.sasview.org/ticket/770

{
    "status": "closed",
    "changetime": "2016-11-08T10:24:22",
    "_ts": "2016-11-08 10:24:22.915372+00:00",
    "description": "There is no error if the new plugin model name is blank, but the resulting function won't show up in the list of custom models.\n\nDefault the name to blank so that the user is required to provide a meaningful name.",
    "reporter": "pkienzle",
    "cc": "",
    "resolution": "fixed",
    "workpackage": "SasView Bug Fixing",
    "time": "2016-10-10T23:56:44",
    "component": "SasView",
    "summary": "Raise an error if function name is blank for New Plugin Model",
    "priority": "minor",
    "keywords": "",
    "milestone": "SasView 4.1.0",
    "owner": "piotr",
    "type": "enhancement"
}

[smk78]

Trac update at 2016/10/11 17:12:43: smk78 commented:

The same issue applies to the Sum|Multi case too.

[smk78]

Trac update at 2016/10/11 17:13:30:

• smk78 changed _comment0 from "Don't understand how starting out with a blank function name helps any though?" to "1476206384171087"
• smk78 commented:

Don't understand how starting out with a blank function name helps any though? Wouldn't it be better to test for an empty string?

[butlerpd]

Trac update at 2016/10/11 17:18:28: butler changed type from "defect" to "enhancement"

[rozyczko]

Trac update at 2016/10/12 01:20:21: piotr commented:

Indeed it would be better to start with a predefined (default) name - the less the user has to add/modify the more "friendly" the control is, I guess.

[rozyczko]

Trac update at 2016/10/12 01:20:44:

• piotr changed owner from "" to "piotr"
• piotr changed status from "new" to "accepted"

[rozyczko]

Trac update at 2016/10/12 01:22:54: piotr commented:

Do we need to worry about the backend? Will sasmodels catch attempts to pass ".py"?

[sasview-bot]

Trac update at 2016/10/12 01:24:00: Piotr Rozyczko <[email protected] commented:

In changeset ad1ac45:

#!CommitTicketReference repository="sasview" revision="ad1ac45c1b0fae0a90dcd973e0dcaa6368726c9a"
filter out empty filenames. Fixes the obvious part of #884

[pkienzle]

Trac update at 2016/10/13 05:37:34: pkienzle commented:

Replying to [comment:4 piotr]:

Indeed it would be better to start with a predefined (default) name - the less the user has to add/modify the more "friendly" the control is, I guess.

Reasons to leave the initial name blank:

• There is no meaningful default name.

• The current default of "!MyFunction" works the first time, but the next time it will trigger an error because "override" is false (but see below^*^).

• Users who have created a model of the name "!MyFunction" and want to share it on the marketplace will have to contend with other users who just left the default name.

Even if we do stay with a default name, the name "!MyFunction" does not match the underscore naming style of the new models.

^*^Override is currently True, which is bad since it can destroy the previously created model. The default was changed to from False in response to the error on "Apply" when the model was incorrect; it should be change back to False to avoid accidental deletion of models.

[smk78]

Trac update at 2016/10/13 11:10:08: smk78 commented:

I tend to side with PaulK that NOT providing a name is best. But I think the issue here is that we don't provide any way from this window (or the Sum|Multi window) for the user to see what names are already in use - think how a normal load/save dialog box works. If we could let them see what was already there then PaulK's concern about my changing the default action of overwrite is also mitigated. But I found it, during testing, profoundly annoying that every little coding slip up required me to give a new model name until I understood what the overwrite box did. In which case, if you're providing an overwrite capability I don't see why you wouldn't enable it...

[sasview-bot]

Trac update at 2016/11/08 10:24:22:

• Piotr Rozyczko <[email protected] commented:

In changeset 94f0873:

#!CommitTicketReference repository="sasview" revision="94f0873f0d6db34d039295cbc4fbe5a7bf2b1467"
Removed default name and changed override status. Fixes #884

• Piotr Rozyczko <[email protected] changed resolution from "" to "fixed"
• Piotr Rozyczko <[email protected] changed status from "accepted" to "closed"