[fdo-internals] RFC15 posted

[Orest Halustchak]

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.

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: 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).

Regards,
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
http://lists.osgeo.org/mailman/listinfo/fdo-internals