Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 29 Jun 2005 12:36:07 -0500

Kay-Uwe Kasemir wrote:

The current wiki calc example has a default "result" view,
other record types have "value" view.

It doesn't really matter what the name of the default view is, since the

whole point of the default view is purely to determine which one you get

when you just specify "fred". If you know you're pointing at a calc

record you can still say "fred" or "fred.result" and you'll get the same

data, but in general it's advisable to use just "fred" since it permits

me to convert the record to some other type without it affecting your

client (as long as it supports the same properties you're looking at).

Would it make sense to have all records support a "value" view?

No; in V3 every record type must have a VAL field, but it really doesn't

make sense for some record types - the V3 transform record initializes

its VAL field to 0.0 and then ignores it forever after. I want to avoid

this kind of "got to do it even if I don't need it" requirement in V4,

and I'm also encouraging the use of more descriptive names. The "value"

of a calc record could arguably be either the expression itself or its

result, so I thought it appropriate to not have a "value" view at all

(although that particular example was more to demonstrate that the

default view could be called something other than "value").

Should there be default views "value", "control", "display",...
similar to the existing DBR_.. types?

No. A record's default view should contain the union of all of the

display, control and other properties that are appropriate for the

record, so there should never be views called "control" and "display"

that just mirror the existing DBR_ types. If an MEDM widget only wants

the display properties of a channel it should subscribe with a property

catalog that only contains those properties, which avoids their being

sent over the wire unnecessarily.

There will probably be some common conventions we adopt for naming views

-- maybe AI, BI and MBBI records should have "raw" and "engineering"

views and no "value" view (the default views would be "engineering") --

but they should only be used where appropriate.

There is still a question in my head about the distinction between the

terms View and Controller in the MVC model on which I'd appreciate some

input from others - should we allow just any view to be used for a put,

or do we want to have some way of defining which views and/or properties

in a view are permitted? I believe that it's not possible to put a

DBR_CTL_DOUBLE in V3, how should we convert that rule into V4 terms?

- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System