[fdo-internals] RFC15 posted

Orest Halustchak orest.halustchak at autodesk.com
Tue Feb 12 08:47:12 EST 2008

Hi Maksim,

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.


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
Sent: Tuesday, February 12, 2008 4:05 AM
To: fdo-internals at lists.osgeo.org
Subject: RE: [fdo-internals] RFC15 posted

Hi Orest, Frank,

I will definately add more details to it, still I'm not sure about C++
implementation notation due to my VB.NET background. Is it possible to use
UML diagrams only?

Orest, that's exactly another thing I was planning to propose. In my custom
DOM it's called ConstraintLookupDictionary, so in FDO I guess the name of
such class would ressemble to PropertyValueConstraintLookupDictionary.
Basically, it takes another Class/FeatureClass as a data source for the
underlying dictionary (including possible data grouping and/or sorting). In
FDO, such class would inherit PropertyValueConstraintDictionary which
implements Dictionary functionality in first place.

There's one thing I still don't know - whether OSGeo.FDO.Expression
namespace already contains a Dictionary of some sort? (not Collection).

Maksim Sestic

Orest Halustchak wrote:
> Hi Maksim,
> I principle, the idea looks good, but I agree with Frank in terms of the
> amount of detail that is needed.
> One thing to consider is that the dictionary may be persisted in another
> class (e.g. another table in an rdbms). What about having this type of
> constraint reference a dictionary via another class rather than a list
> maintained just with the property that uses it? That way the dictionary
> could be referenced by more than one property and will allow more
> flexibility in defining and maintaining the dictionary?
> Thanks,
> Orest.
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank
> Warmerdam (External)
> Sent: Monday, February 11, 2008 10:49 AM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] RFC15 posted
> Maksim Sestic wrote:
>> Hi everyone,
>> A  http://trac.osgeo.org/fdo/wiki/FDORfc15 FDO RFC15  has been posted.
>> It's
>> about introducing new PropertyValueConstraintDictionary class, so please
>> give some feedback on this. Year ago I've been working on a concept
>> similar
>> to FDO's and this particular constraint type turned out valuable for most
>> of
>> users.
> Maksim,
> While I'm supportive of the general concept, I am not able to judge how
> appropriate the approach is for FDO.
> But, I do think that before we could go to a vote, the RFC would require
> more exactness in terms of what is proposed - including a precise C++
> definition of the proposed interfaces.
> I think you also need to address backward compatability issues (if any)
> and who will implement the proposed new feature.
> Best regards,
View this message in context: http://www.nabble.com/RFC15-posted-tp15408616s18162p15429278.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 mailing list