[fdo-internals] RFC15 posted
orest.halustchak at autodesk.com
Wed Feb 13 12:50:08 EST 2008
That's a good point about DictionaryElement, but before we dive into that one, I'm wondering about whether it would be used at all to define the constraint. If the constraint is defined based on data persisted in another class, don't we need just references to that other class and not an actual dictionary held in a structure in memory? Or ... are you thinking that the constraint can defined either way, an explicit dictionary attached to the property definition or a referenced dictionary in another class? Do we need both?
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
Sent: Wednesday, February 13, 2008 5:14 AM
To: fdo-internals at lists.osgeo.org
Subject: RE: [fdo-internals] RFC15 posted
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.
fdo-internals mailing list
fdo-internals at lists.osgeo.org
More information about the fdo-internals