Changes between Version 9 and Version 10 of FDORfc15


Ignore:
Timestamp:
Mar 20, 2008, 3:28:39 PM (16 years ago)
Author:
gregboone
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FDORfc15

    v9 v10  
    1 = FDO RFC 15 – FDO PropertyValueConstraintDictionary Class =
     1= FDO RFC 15 – FDO !PropertyValueConstraintDictionary Class =
    22
    33This page contains a request for comments document (RFC) for the FDO Open Source project. 
    … …  
    2525Presently, `PropertyValueConstraintList` may contain only plain list of predefined values forced upon particular `PropertyValue` (minus null value). In my opinion, it somehow beats sole purpose of Constraints in a view of overall datastore consolidation.
    2626
    27 This RFC suggest enforcing sound ''rules'' for data types and saving lots of storage - it's not clever to keep underlying i.e. RoadTypePropertyValue as String since it takes too much space, it's not possible to change associated meaning of data once the data is in the store, while schema user from different country may not understand ''by default'' what Main road means, etc.
     27This RFC suggest enforcing sound ''rules'' for data types and saving lots of storage - it's not clever to keep underlying i.e. !RoadTypePropertyValue as String since it takes too much space, it's not possible to change associated meaning of data once the data is in the store, while schema user from different country may not understand ''by default'' what Main road means, etc.
    2828
    29 On the client side, developers may build more robust UIs to deal with FDO-based data. I.e. a ComboBox instead of plain text field, where combo has it's values set to predefined `PropertyValueConstraintDictionary` object range and displayed members consist of associated string values. In that way users will be able to pick between Highway, Main road or Street, while underlying datastore keeps it's `short` or `boolean` (or any other) universal representation.
     29On the client side, developers may build more robust UIs to deal with FDO-based data. I.e. a !ComboBox instead of plain text field, where combo has it's values set to predefined `PropertyValueConstraintDictionary` object range and displayed members consist of associated string values. In that way users will be able to pick between Highway, Main road or Street, while underlying datastore keeps it's `short` or `boolean` (or any other) universal representation.
    3030
    3131
    … …  
    3434There are two possible approaches to this:
    3535
    36   1. `PropertyValueConstraintDictionary` - a Constraint that will keep pairs of [object,string] values, where object is a key dictionary member (an item in present `PropertyValueConstraintList`), while associated string represents localized description of the value itself.
     36  1. `PropertyValueConstraintDictionary` - a Constraint that will keep pairs of [object,string] values, where object is a key dictionary member (an item in present `!PropertyValueConstraintList`), while associated string represents localized description of the value itself.
    3737
    3838Example:
    … …  
    5454}}}
    5555
    56 This is a bit tricky in the light of `PropertyValueConstraintDictionary` since dictionary key is a String, while `PropertyValue` may be of any (reasonable) FDO type for that matter. I guess it would take few additional generic dictionary elements with different Key types (Short... Int16, Int32... Double... etc). Term "name" used for `DictionaryElement` parameter is not appropriate - term "key" is somehow more suitable. It seems that DictionaryElement and DictionaryElementCollection classes may undergo major reconstruction for `PropertyValueConstraintDictionary` to work.
     56This is a bit tricky in the light of `PropertyValueConstraintDictionary` since dictionary key is a String, while `PropertyValue` may be of any (reasonable) FDO type for that matter. I guess it would take few additional generic dictionary elements with different Key types (Short... Int16, Int32... Double... etc). Term "name" used for `DictionaryElement` parameter is not appropriate - term "key" is somehow more suitable. It seems that !DictionaryElement and !DictionaryElementCollection classes may undergo major reconstruction for `PropertyValueConstraintDictionary` to work.
    5757
    5858  2. `PropertyValueConstraintLookup` - a Constraint with it's definition based on data persisted in another class. Please see related proposed solution and implementation details below.
    … …  
    6666
    6767Functionality overview:
    68   1. new class PropertyValueConstraintLookup (or PropertyValueConstraintPickList)
     68  1. new class !PropertyValueConstraintLookup (or !PropertyValueConstraintPickList)
    6969  2. takes feature schema name as parameter
    7070  3. takes a source class/feature class name from 2) as parameter
    7171  4. takes Key property name from 3) for key data source
    7272  5. takes Value property name from 3) for value data source (can be same as 4) for that matter)
    73   6. has a getter method returning... well... instantiated FdoReader instead of a dictionary (?)
    74   7. has GroupBy and SortBy optional properties being cast upon 3)
     73  6. has a getter method returning... well... instantiated !FdoReader instead of a dictionary (?)
     74  7. has !GroupBy and !SortBy optional properties being cast upon 3)
    7575  8. Throws an error if there're duplicate keys in 4) - acting as some sort of proxy dictionary
    7676