| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
I have a suggestion concerning the user-friendliness of the FCL for
certain commands. I guess it isn't exactly a "bug", but it's certainly
a Grade A misfeature.
If you type a command that requires an attribute, and you don't mention
it (e.g. the partition), you get prompted for it. But if you make the
same mistake concerning a qualifier, you just get a ratty error
message:
MCC> show recording node4 tenere circuit bna-0 partition *
Node4 tenere Circuit bna-0
AT 1992-01-10-13:40:52.094Iinf
This directive requires the In Domain qualifier
Required Qualifier = In Domain
To which the obvious answer is "if you knew the domain qualifier was
required, why didn't you #%$#@# ask for it!". It's particularly
irritating when you've just been prompted for other stuff... you
finally get the command right (as you think), only to have it chucked
out anyway.
(Given all the pressures on the product team right now, I don't expect
this to get fixed prior to release. But it would give a much better
impression of the product if it could get attended to some time).
John
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2065.1 | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Fri Jan 10 1992 11:30 | 22 | |
Are you yelling at us for separating form and function??? :-)
How else are we going to get to "Enterprise Wide bla bla bla"? :-)
The PM cannot tell that the in_domain qualifier is required for this
directive - it's the FM that discovers this.
MCC does not have a mechanism for the FM to ask the PM to ask the
user something. Should it? Absolutely if we want decent user
interfaces. To do it within the confines of the current architecture
is probably possible - we need to define another type of reply to
mcc_call which says "Need more info from PM". The attributes of the
reply would point to some text string and datatype in the dictionary
which would be used to issue a prompt in whatever style the PM works
with.
I don't want to design it here, just want to convey that these things
can get complex if we want to preserve the modularity and data-driven
nature of things.
| |||||
| 2065.2 | More information in the MS file | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Fri Jan 10 1992 12:37 | 6 |
Currently there is nothing in your MS file which states what types of qualifiers you want or need. The FCL dispatches the call to your MM, then your MM returns the error about needing (or not wanting) a qualifier. /keith | |||||
| 2065.3 | No, I don't think so... | TAEC::HARPER | John Harper, DTN 830 3647 | Fri Jan 10 1992 14:25 | 35 |
Well, I didn't say I thought it was easy, just that it would be a lot
more user friendly.
>> Are you yelling at us for separating form and function??? :-)
I don't think .0 really qualifies as "yelling". Actually my general
demeanour at this point in my attempt to become a self-taught MCC
expert could better be described as "sobbing faintly between
occasional outbursts of hysteria". But I'm getting there, slowly.
Seriously, at some point I will write a well-thought-out piece on the
need to find the right balance between following an architecture and
being a slave to it; but not on Friday evening.
>> MCC does not have a mechanism for the FM to ask the PM to ask the
>> user something. Should it?
But surely, from what you say in the rest of the paragraph, it does.
The FM comes back and says "no %$# way, there's no xxx qualifier, where
xxx=domain. So I didn't do it. So there." Whereupon the PM, if it's
smart, can say "well, if he didn't do it, it won't hurt to make the
same request again, since there isn't something half-done that needs to
be undone first". So it prompts the user for the required
qualifier(s), and, remembering the rest of the request, reissues the
whole thing. N'est-ce pas?
Of course I agree that the "right" way to do it is much as you
describe, with some kind of call-back to the PM. And that what I've
described above is a hack. Hacks can sometimes be a good idea... and
sometimes a dreadful one. (See well-thought-out piece on the need to
find the right balance between following an architecture and
being a slave to it, in preparation).
John
| |||||
| 2065.4 | Thank you | TOOK::MINTZ | Erik Mintz, DECmcc Development | Fri Jan 10 1992 15:12 | 15 |
> >> Are you yelling at us for separating form and function??? :-) > > I don't think .0 really qualifies as "yelling". Actually my general > demeanour at this point in my attempt to become a self-taught MCC > expert could better be described as "sobbing faintly between > occasional outbursts of hysteria". But I'm getting there, slowly. Note the smiley face at the end of the first line... Seriously, we appreciate your well thought out comments. We are definitely interested in any ideas that make DECmcc easier to use and understand. -- Erik | |||||
| 2065.5 | use exception to initate prompt? I like it | TOOK::CALLANDER | MCC = My Constant Companion | Wed Jan 15 1992 20:01 | 14 |
John,
this item has been discussed many times, and keeps getting traded off.
It is still on the "if we have time this release...." list.
The minimum functionality we would like would be to prompt for
qualifiers. The only problem has been how and when? Your idea is great,
I will look into it's feasibility.
As to the, have the FM tell us what to do, we have talked about what we
call a callback mechanism where and FM can do just that. This would
require PM support of the mechanism but would allow for a more open
interface and richer functionality.
| |||||