| 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: views |
| From: | Andrew Johnson <[email protected]> |
| To: | Kay-Uwe Kasemir <[email protected]> |
| Cc: | EPICS Core Talk <[email protected]> |
| Date: | 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.