OPF.Why MetaData

" class="oa" bg nowrap="nowrap" width="1%">Marcos

Dec 11 2004, 8:51 am

Newsgroups: borland.public.delphi.oodesign

From: Marcos -

Date: Sat, 11 Dec 2004 14:51:28 -0200

Local: Sat,Dec 11 2004 8:51 am

Subject: Re: ValueType Framework help please

Bob Dawson wrote:
> Classic metadata for a TStringType, for example, might include
> Isrequired, min and max length, case sensitivity, case restriction, input mask
> should a zero-length string be submitted to datastore as is, or as null

It is this that I still didn't understand. If I have in a class:

TPerson
Name: string;
Address: string;

Both registered like TStringType in a TypeRegister (like Joanna do it).
I should have a field metadata (FMetadata: IMetadata) for each attribute
(Name and Address) or should I have in both attributes a reference to a
single object TStringMetadata?

If the affirmative answer is the first one, then I believe that max,
length, IsRequired,... they could be put directly in the interface
TStringType or your base class (TValueType) and not in an attribute
Metadata inside of TStringType. Can anybody comment on?

If the affirmative answer is the second one, then max, length,
IsRequired could not be part of the metadata because Name.IsRequired
attribute can be direferent of Address.IsRequired. Can anybody comment on?

Thank you, sry my bad english

" class="oa" bg nowrap="nowrap" width="1%">Bob Dawson

Dec 11 2004, 1:31 pm

Newsgroups: borland.public.delphi.oodesign

From: "Bob Dawson"

Date: Sat, 11 Dec 2004 15:31:42 -0600

Local: Sat,Dec 11 2004 1:31 pm

Subject: Re: ValueType Framework help please

"Marcos" wrote

> I should have a field metadata (FMetadata: IMetadata) for each attribute

Yes.

> length, IsRequired,... they could be put directly in the interface

You could, but that would be a bit wasteful.

Might think of it in terms of data granularity: Metadata is a singleton for
a specific deployment of the TStringType class--so one instance of the
string metadata can support all instances of the TPerson.FirstName object.
Data layer efficiency then argues that we should not be forced to request
the underlying field metadata information everytime we need a new instance
of the field data object. If there are two underlying objects, then we
should probably have two interfaces.

From a design point of view as well, the data and metadata of a stringtype
are different; that is, 'what is the firstname' and 'how long can the first
name be' are really different orders of questions. If we separate out the
IMetadata interface (so that it is merely cited by, not incorporated into,
the data interface, then we can better contain changes to one or the other.

As your framework gets more complex, this containment can become quite
useful. I route metadata requests through a different connection than data
requests (the OPF asks questions about how to act in its own context, not in
the context of the user), so that a question like "How do I store this
object?" is never asked in the context of a business data transaction.

bobD