 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Petter H.
Guest
|
 Posted: Thu Dec 04, 2003 7:13 am Post subject: Questions: Metadata and attributes, lists and other stuff |
 |
|
Hello,
I haven't had the time to work on my OPF for about two months (I'm
currently working on a project using Python and Zope), but now I'm going
to try to find some time for it again.
I'm currently on my fourth design, moving towards the fifth as my skills
develop and I've been googeling this group for design suggestions and I
have a few questions. There are a lot of foreign expressions and words
related to this subject that I've never heard about before and it
doesn't actually make the situation better... Strangely enough we never
learned words like "metadata", "attribute", "broker", "iterator",
"persistence" etc. in school.  Well, I'm slowly beginning to figure
them out...
Now on to the questions:
First of all: what exactly is metadata? Is it something that describes
the structure of something? What kind of information would a Metadata
class (or interface) contain?
I've read the "Where do concrete Attributes Belong"-thread about
registering attributes. Now, what is this all about? What are the
advantages? Why does the BO have to be an attribute, too? And why does
the TAttribute-class need a GetMetaType-method?
Object lists: I've read a lot about object lists and object iterators -
which one should populate which? If my OPF was to support loading data
in chunks, which part would be responsible for populating the object
collection, and would this collection be a list or an iterator, or both?
I'll be back with more questions as soon as they pop up.
Thanks in advance,
-Petter-
|
|
| Back to top |
|
 |
Marc Rohloff
Guest
|
| Posted: Thu Dec 04, 2003 1:28 pm Post subject: Re: Questions: Metadata and attributes, lists and other stuf |
|
|
Petter H. wrote on Thu, 04 Dec 2003 09:13:02 +0200 ...
| Quote: | Strangely enough we never
learned words like "metadata", "attribute", "broker", "iterator",
"persistence" etc. in school.
I always thought they taught the wrong things. I don't think I ever used |
anything I learnt at university.
| Quote: | First of all: what exactly is metadata? Is it something that describes
the structure of something? What kind of information would a Metadata
class (or interface) contain?
Metadata basically means information about the data. It can cover a |
whole range of information depending on what you require and the
development environment supplies. For example Delphi's RTTI and .NETs
reflection provide some metadata.
For an OPF you would need to, at a minimum, a list of
properties/attributes and their types, but often you will want to know
more. String lengths, numeric precision, formats, and possibly
information about the field names (Although generally people here will
recommend you seperate that out). It really depends on your model and
requirements.
The metadata can also be generated in different ways. You can generate
it automatically based on the RTTI or add it all yourself. In .NET you
can also use attributes (not the same as the attributes you discuss
below). If you use complex objects to represent your attributes then
these can provide quite a lot of information automatically too. Lastly
you can provide it in some sort of lookup table or database. You might
well land up using more than one method, possibly an automatic
generation followed by a way to override it manually where necessary.
| Quote: | I've read the "Where do concrete Attributes Belong"-thread about
registering attributes. Now, what is this all about? What are the
advantages? Why does the BO have to be an attribute, too? And why does
the TAttribute-class need a GetMetaType-method?
I haven't read the thread but I can try and give you an answer. The |
reason a BO is an attribute is that most object models have objects
which can contain and link to other objects. Making a BO an attribute
makes it easier to fit into this model. You could in theory not make
your BusinessObject derive from TAttribute and have a
'BusinessObjectAttribute'. TAttribute has a get MetaType method so that
it can automatically supply it's own metadata, this s especially true if
the attribute represents a BusinessObject. The OPF could go through
attributes recursively to fill in the whole metadata tree for a root
object.
You will see that making a BO an attribute ties in quite neatly with the
whole issue of automatically generating MetaData.
| Quote: | Object lists: I've read a lot about object lists and object iterators -
which one should populate which? If my OPF was to support loading data
in chunks, which part would be responsible for populating the object
collection, and would this collection be a list or an iterator, or both?
Neither really. An iterator generally allows you to move sequentially |
through a list. The object list will generally be populated by the data
tier. The data tier may use an iterator on a data query object to
achieve this, it could not use an iterator on an object list since the
list is empty to start with.
HTH
Marc Rohloff
marc rohloff at bigfoot dot com
|
|
| Back to top |
|
|
Petter H.
Guest
|
| Posted: Fri Dec 05, 2003 7:06 am Post subject: Re: Questions: Metadata and attributes, lists and other stuf |
|
|
Marc Rohloff wrote:
| Quote: | I always thought they taught the wrong things. I don't think I ever used
anything I learnt at university.
|
Well, I haven't even reached university yet (well, I work at one right
now but I won't start studying until next year).
| Quote: | snip> possibly
information about the field names (Although generally people here will
recommend you seperate that out).
|
Could you please clearify?? Why should I separate that out, and where
should I put it instead?
| Quote: | I haven't read the thread but I can try and give you an answer. The
reason a BO is an attribute is that most object models have objects
which can contain and link to other objects. Making a BO an attribute
makes it easier to fit into this model.
You could in theory not make
your BusinessObject derive from TAttribute and have a
'BusinessObjectAttribute'. TAttribute has a get MetaType method so that
it can automatically supply it's own metadata, this s especially true if
the attribute represents a BusinessObject.
|
This I don't quite understand, do you think you could provide a small
code example?
| Quote: | An iterator generally allows you to move sequentially
through a list. The object list will generally be populated by the data
tier. The data tier may use an iterator on a data query object to
achieve this, it could not use an iterator on an object list since the
list is empty to start with.
|
That I understand, perhaps I should clearify my question.
If my collection supports data loading in chunks I'll of course need the
data tier to provide the data, but I also need a way to ask it to get
the next 10 (or whatever numer) objects from the data store when I run
out of objects. Which approach, if either, is better of these two:
Use an iterator:
procedure Iterator.Next;
begin
if Assigned(FDataTierNext) then
FDataTierNext(Self);
...
Inc(FCurrentIndex);
end;
---
procedure DataTier.OnNext(Sender: TIterator);
begin
if Sender.CurrentIndex = FFetchedItems -1 then
begin
// Fill in the rest
....
end;
end;
---
This code wouldn't actually need chunk-loading as it populates the
ListBox at once, but I hope you get my point.
procedure Form1.FillTextList;
begin
PersistenceBroker.LoadCollection(Iterator);
Iterator.First;
while not Iterator.IsDone do
begin
ListBox1.Items.Add( Iterator.CurrentItem.SomeTextValue );
Iterator.Next;
end;
end;
Or a list:
function List.GetItem(Index: Integer);
begin
if Assigned(FDataTierGetItem) then
FDataTierGetItem(Self, Index);
Result := Items[Index];
end;
---
procedure DataTier.OnGetItem(Sender: TMyList; Index: Integer);
begin
if Index = FFetchedItems -1 then
begin
// Fill in the rest
....
end;
end;
---
procedure Form1.FillTextList;
var
i: integer;
begin
PersistenceBroker.LoadCollection(List);
for i := 0 to List.Count -1 do
ListBox1.Items.Add( List.Items[i].SomeTextValue );
end;
Thanks for your help,
-Petter-
|
|
| Back to top |
|
|
Marc Rohloff
Guest
|
| Posted: Fri Dec 05, 2003 1:30 pm Post subject: More things you won't learn at University |
|
|
Petter H. wrote on Fri, 05 Dec 2003 09:06:31 +0200 ...
| Quote: | snip> possibly
information about the field names (Although generally people here will
recommend you seperate that out).
Could you please clearify?? Why should I separate that out, and where
should I put it instead?
I couldn't figure out a short answer to your question so here it goes |
....
Generally you would try and split your application design into three
parts. Some people call them layers, I don't because I don't see them as
layered on top of each other.
1) The presentation layer. ie. The UI and controls
2) The business model (often called business objects [BO] or Problem
Domain [PD] )
3) The data or persistance layer. Manages storage of your business
objects.
Around here this is generally called an OPF (Object Persistence
Framework)
The advantage with this architecture is that the BOs and their rules
tend to be fairly consistent over time and reusable so you want to keep
them seperate.
Seperating the UI means you can can completely change it without
affecting most of your code. For example changing from a GUI to a web
app.
Lastly keeping the data layer seperate means that you can restructure
and optimize your database relatively painlessly. You can also change
from one database vendor to another or even to a non-database solution
without changing the other two layers.
Generally most of your meta-data would go with your business objects.
The exception is things like table and field name mapping information
(which is also a type of meta-data) which you would want to keep
seperate and associated with the data layer. ie: If you rename a field
that has nothing to do with your business rules.
| Quote: | You could in theory not make
your BusinessObject derive from TAttribute
This I don't quite understand, do you think you could provide a small
code example?
A short one? Not easily! |
Generally you would define your base attribute class as
TAttribute = class
property IsNull:boolean;
class function GetMetaData:TMetaData; virtual;
end;
And you might have say:
TIntegerAttribute = class
property Value:Integer;
class function GetMetaData:TMetaData; override;
end;
So a business object could have a property:
TPerson = class(TBusinessObject)
property Age:TIntegerAttribute;
end;
And you can 'automatically' get meta daat for TPerson and the age
attribute.
But a person also has a spouse: so
TPerson = class(TBusinessObject)
property Age :TIntegerAttribute;
property Spouse:TPerson;
end;
Now if TBusinessObject derives from TAttribute you would automatically
have access to the same meta data using the same basic code.
Of course you could define:
TBOAttribute = class(TAttribute)
property Value:TBusinessObject;
class function GetMetaData:TMetaData; override;
end;
and
TPerson = class(TBusinessObject)
property Age :TIntegerAttribute;
property Spouse:TBOAttribute;
end;
But this can get quite verbose to use.
Does this help? I am not really sure how much detail you want me to go
into or what level you are at.
| Quote: | That I understand, perhaps I should clearify my question.
If my collection supports data loading in chunks I'll of course need the
data tier to provide the data, but I also need a way to ask it to get
the next 10 (or whatever numer) objects from the data store when I run
out of objects. Which approach, if either, is better of these two:
Use an iterator:
Or a list:
|
I guess it's generally a matteer of preference. I tend to use a list
since it is easier for the client to access. On the datatier side I
would/might use an iterator for simplicity. THe list can then read
items from it's cache or if it has not read them yet it can call the
datatier's iterator.
Marc Rohloff
marc rohloff at bigfoot dot com
|
|
| Back to top |
|
|
Petter H.
Guest
|
| Posted: Mon Dec 08, 2003 7:37 am Post subject: Re: More things you won't learn at University |
|
|
Marc Rohloff wrote:
| Quote: | snip
Generally you would define your base attribute class as
TAttribute = class
property IsNull:boolean;
class function GetMetaData:TMetaData; virtual;
end;
And you might have say:
TIntegerAttribute = class
property Value:Integer;
class function GetMetaData:TMetaData; override;
end;
|
Why does this attribute need a TMetaData get-method? If attributes
describe the metadata of an object, is there also a need for something
to describe the metadata of the attribute? What would this metadata
object contain? Would it say something like: this is an attribute and
it's an integer one?
| Quote: | So a business object could have a property:
TPerson = class(TBusinessObject)
property Age:TIntegerAttribute;
end;
And you can 'automatically' get meta daat for TPerson and the age
attribute.
|
But this requires that I register the attributes somewhere, right?
| Quote: | Does this help? I am not really sure how much detail you want me to go
into or what level you are at.
|
It helps a little, thanks. What I'm after is to understand the basics
behind this concept, after that I want to develop my own framework. I
know the basics of OPF design, but this attribute registering thing is
totally new to me.
| Quote: | I guess it's generally a matteer of preference. I tend to use a list
since it is easier for the client to access. On the datatier side I
would/might use an iterator for simplicity. THe list can then read
items from it's cache or if it has not read them yet it can call the
datatier's iterator.
|
Should the list itself make sure it has enough data or should an
"external" component take care of that? Like this:
{ the list itself keeps track of whether it's got enough data or not.
It keeps a private reference to the data cursor }
procedure MyList.Next;
var
n: Integer;
begin
if (CurrentItem = RetrievedItems-1) then
begin
n := 0;
while (not FDataCursor.Eof) or (n < 10) do
begin
FItems.Add( FDataCursor.GetItem )
FDataCursor.Next;
end;
end;
if CurrentItem < TotalItems-1 then
CurrentItem := CurrentItem + 1;
end;
or:
{ the list triggers events on every Next, First, IsDone and let an
external component, 'listening to the events', take care of the
population. }
procedure MyList.Next;
begin
if Assigned(FOnGetNext) then FOnGetNext(Self);
if CurrentItem < TotalItems -1 then
CurrentItem := CurrnetItem +1;
end;
Thanks for your advice,
-Petter-
|
|
| Back to top |
|
|
Joanna Carter (TeamB)
Guest
|
| Posted: Mon Dec 08, 2003 11:32 am Post subject: Re: More things you won't learn at University |
|
|
Petter H. wrote:
| Quote: | Why does this attribute need a TMetaData get-method? If attributes
describe the metadata of an object, is there also a need for something
to describe the metadata of the attribute? What would this metadata
object contain? Would it say something like: this is an attribute and
it's an integer one?
|
Essentially, an Attribute is a value object whose primary purpose is to
represent an attribute of an object.
Due to Delphi's incomplete RTTI implementation, most of us who have worked
with OPFs have moved to the use of the Attribute framework to provide us
with the level of metadata more suited to our needs.
The amount of metadata desired can differ, so we have found it useful to
separate out the metadata structure from the Attribute itself, mainly for
reasons of flexibility and extensibility.
| Quote: | But this requires that I register the attributes somewhere, right?
|
I register Attributes in a Type Register because I use interfaces and need a
mapping to get to the implementing class type for object instantiation
purposes. But if you do not use interfaces, then a registry is not
necessarily necessary :-)
| Quote: | It helps a little, thanks. What I'm after is to understand the basics
behind this concept, after that I want to develop my own framework. I
know the basics of OPF design, but this attribute registering thing is
totally new to me.
|
Having said that Attribute registering is not necessary for metadata
purposes, you will definitely need to have a register that maps the classes
and attributes to tables and columns, or XML elements for persistence
purposes.
| Quote: | { the list triggers events on every Next, First, IsDone and let an
external component, 'listening to the events', take care of the
population. }
procedure MyList.Next;
begin
if Assigned(FOnGetNext) then FOnGetNext(Self);
if CurrentItem < TotalItems -1 then
CurrentItem := CurrnetItem +1;
end;
|
I personally use events in my collection classes to support paging objects;
but when the request for a collection is first made to the OPF, the first
thing that happens is that I get the 'StoredCount' of how many items to
expect into the collection, then I can use this to check for 'EOF'
conditions in the list. This then allows me to say:
if (Count < StoredCount) and Assigned(fOnGetNext)...
Once the Count is equal to the StoredCount, I can disconnect the paging
broker and release the database connection.
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
|
|
| Back to top |
|
|
Franz-Leo Chomse
Guest
|
| Posted: Mon Dec 08, 2003 12:13 pm Post subject: Re: More things you won't learn at University |
|
|
On Mon, 08 Dec 2003 09:37:46 +0200, "Petter H."
| Quote: | And you might have say:
TIntegerAttribute = class
property Value:Integer;
class function GetMetaData:TMetaData; override;
end;
Why does this attribute need a TMetaData get-method? If attributes
describe the metadata of an object, is there also a need for something
to describe the metadata of the attribute? What would this metadata
object contain? Would it say something like: this is an attribute and
it's an integer one?
|
The Metadata of an attribute contains their constraints, like minimal
allowed value, maximal allowed value, pointer to a validation method
etc. And these constraints depend on the original type of the
attribute value.
| Quote: | But this requires that I register the attributes somewhere, right?
|
Either you register them and you have a central repository, which can
be interrogated for the meta data or you have to provide meta data
access routines in each business object.
| Quote: | It helps a little, thanks. What I'm after is to understand the basics
behind this concept, after that I want to develop my own framework. I
know the basics of OPF design, but this attribute registering thing is
totally new to me.
|
Its a normal decoupling pattern. With a register approach you can
access an attribute by an identifier an not only by the real
implementing class. And this is a requirement for BO scripting, i.e.
changing the behavior at runtime.
Regards from Germany
Franz-Leo
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
