[fdo-internals] RFC15 posted

[Barbara Zoladek]

Hi Orest,

Doesn't his proposal overlap with our pick list concept?

Thanks,
Barbara.

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Wednesday, February 13, 2008 12:50 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC15 posted

Hi Maksim,

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?

Thanks,
Orest.

-----Original Message-----
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


Hi Orest,

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
*value)

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?

Regards,
Maksim Sestic



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
> FdoPropertyValueConstraint.
>
> Re: Dictionary: Did you have a look at FdoDictionary, which inherits from
> FdoNamedCollection?
>
> 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
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals