[fdo-internals] RFC15 posted
max at geoinova.com
Wed Feb 13 05:13:39 EST 2008
I already included some textual description, UML diagram (with
properties/methods) still to come.
Dictionary is another story. It seems that present implementation of
DictionaryElement (building block of DictionaryElementCollection, which, I
guess, ressembles to generic FDO Dictionary) has following definition:
OSGeo::FDO:Common:DictionaryElement (System::String *name, System::String
This is a bit tricky in the light of FdoPropertyValueConstraintDictionary
since dictionary key is a String, while FdoPropertyValue 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 FdoPropertyValueConstraintDictionary to
work. Orest, I don't know whether FDO developers prefer property overloading
(easier, but introduces possible type narrowing) over class inheritance (bit
more coding) to achieve this?
Orest Halustchak wrote:
> One idea is to post your UML design and ask for help to define the fdo
> interfaces for that design. You could also have a look at the current
> interfaces FdoPropertyValueConstraint, FdoPropertyValueConstraintList, and
> FdoPropertyValueConstraingRange to get an idea of what your interfaces
> might look like. Your interface should inherit from
> Re: Dictionary: Did you have a look at FdoDictionary, which inherits from
> In terms of referencing another class, take into account that you would
> need also to reference the properties of that class.
View this message in context: http://www.nabble.com/RFC15-posted-tp15408616s18162p15453255.html
Sent from the fdo-internals mailing list archive at Nabble.com.
More information about the fdo-internals