Board index » delphi » Displaying extrinsically-defined collections

Displaying extrinsically-defined collections


2005-08-21 05:36:00 AM
delphi272
Bit quiet here, so let me ask the other OPF writers a two part design
question.
We've all got methods for creating collections, so for example
CustCollection := TCustomer.CreateCollection;
CustCollection.Load('LoadForLastName',[Smith]);
Having this collection, now, what approach do you take for rendering it into
a dataset? For example
TCollectionDataAdapter.LoadDataset(CustCollection, memDat);
(The Collection doesn't know about the dataset and doesn't own it), or
CustCollection.Dataset; //the collection can produce an owned dataset on
demand.
Now part two: suppose the collection's inclusion criteria is external to the
collected class, but that additional information should logically be
displayed? For example, I want all Customers whose accounts are overdue,
with their last payment date and overdue amount. These fields obviously
aren't part of the TCustomer object, but displaying them in the grid with
the customers seems a reasonable requirement.
How do folks generally approach this?
My current thought is that the collection has to recognize that the data
layer has returned 'excess' columns, and build a dynamic array of those
columns, remembering the objects they're associated with. Then, if a dataset
is requested, it can use that internal array to extend the dataset it would
normally have produced.
Any one with a more elegant approach?
bobD
 
 

Re:Displaying extrinsically-defined collections

Bob Dawson writes:
Quote

Having this collection, now, what approach do you take for rendering it into
a dataset? For example

<snip>
Hi Bob. I wrote a custom dataset that is 'framework aware'.
I could provide it as-is, but wouldn't be useful to anyone unless their framework interfaces matched
mine exactly. I started with Gexpert's dataset as a starting point.
Joanna has written some articles about creating a custom dataset...
www.joannac.btinternet.co.uk/
see "Keeping hold of your things"
 

Re:Displaying extrinsically-defined collections

Bob Dawson writes:
Quote
Having this collection, now, what approach do you take for rendering it into
a dataset? For example

TCollectionDataAdapter.LoadDataset(CustCollection, memDat);

(The Collection doesn't know about the dataset and doesn't own it), or

CustCollection.Dataset; //the collection can produce an owned dataset on
demand.
Your first example might be the better of the two, since like you said, the collection wouldn't know
what type of dataset it is loading.
Ultimately, it would be best if CustCollection (or its ancestors) didn't have to know anything about
datasets at all.
For example, I'd write my code like this...
AFrameworkDataSet.Collection := CustCollection;
 

Re:Displaying extrinsically-defined collections

Bob Dawson writes:
Quote
Now part two: suppose the collection's inclusion criteria is external to the
collected class, but that additional information should logically be
displayed? For example, I want all Customers whose accounts are overdue,
with their last payment date and overdue amount. These fields obviously
aren't part of the TCustomer object, but displaying them in the grid with
the customers seems a reasonable requirement.

How do folks generally approach this?

I'm not saying its the most elegant solution but,...
What I'd do for your example is use a calculated field. Then assign the field value in the
OnCalcFields event of the dataset. I'd go this route if I thought that I'd only need it in
one place, e.g. on a report.
My dataset does have the capability of retrieving property values of objects that are associated to
the main object of the collection. For instance, i can add a field def to the dataset, and assign
the FieldName to 'Vendor.Name'. In this example suppose the collection is a list of Order objects.
An Order object has a property, Vendor, which is an object that has a Name property. When the
dataset is loaded, it gets its field data from the immediate properties of the Order object, but
also, if needed, properties of any other associated object, e.g. Vendor.
In your example above, I could add a read-only property to my Customer object, called LastPayment,
which would be a Payment object. Then I could add a fielddef to the dataset, FieldName =
'LastPayment.Date'
This isn't something I had to have just to get my framework up and running. But over time, I found
I was writing OnCalcFields events quite often, or adding read-only properties of my objects. For
example, I'd write a read-only property called VendorName, just so I could easily add a field to
a dataset and not have to write the OnCalcFields event.
Hope this helps!
 

Re:Displaying extrinsically-defined collections

"Charles McAllister" wrote
Quote

Hi Bob. I wrote a custom dataset that is 'framework aware'.
I'm trying to avoid that. I currently use the TdxMemData, but it's
subclassed in the framework and I only access generic TDataset perperties
and methods. We've built alternative subclassing units to run over
TClientDataset and TkbmMemTable.
bobD
 

Re:Displaying extrinsically-defined collections

"Charles McAllister" wrote
Quote
>
>TCollectionDataAdapter.LoadDataset(CustCollection, memDat);
>or
>CustCollection.Dataset;

Your first example might be the better of the two, since like you said,
the collection wouldn't know
what type of dataset it is loading.
I like the first from the design modularization point of view, but I'm
wondering about in-grid editing. With an owned dataset I should be able to
link the dataset fields with propertise of the underlying objects, but I'm
thinking that I'd need a framework-aware dataset if I don't bind
them--the dataset would have to know about validating changes against the
object.
bobD
 

Re:Displaying extrinsically-defined collections

"Charles McAllister" wrote
Quote

In your example above, I could add a read-only property to my
Customer object, called LastPayment, which would be a Payment object.
But extrinsic values like last payment date are really not properties of a
Customer, but of an account history. And in any case the potential number of
extrinsic properties is vast: any field that an sql join might return with a
customer table row, including sums or other calculations, could conceivably
be of interest to somebody, and we have to support it. I don't see that
altering the object model to accomodate this co-variant data as a viable
option.
bobD
 

Re:Displaying extrinsically-defined collections

Bob Dawson writes:
Quote
But extrinsic values like last payment date are really not properties of a
Customer, but of an account history. And in any case the potential number of
extrinsic properties is vast: any field that an sql join might return with a
customer table row, including sums or other calculations, could conceivably
be of interest to somebody, and we have to support it. I don't see that
altering the object model to accomodate this co-variant data as a viable
option.

Just an idea, but you could still add LastPayment as a 'dynamic property'. For ideas on how to
achieve this, you could read the threads in this group on Joanna's ValueType framework.
 

Re:Displaying extrinsically-defined collections

"Bob Dawson" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...
Quote
But extrinsic values like last payment date are really not properties of a
Customer, but of an account history. And in any case the potential number
of
extrinsic properties is vast: any field that an sql join might return with
a
customer table row, including sums or other calculations, could
conceivably
be of interest to somebody, and we have to support it. I don't see that
altering the object model to accomodate this co-variant data as a viable
option.
Hi Bob
I tend to write "report" classes for situations like this. The general idea
is that you are able to specify things like : the "driving" type, what
properties you want to handle and which types any external properties belong
to, as well as the property that links the "lookup" if it is not available
in the class maps.
This kind of "listing" really doesn't belong in any single BO class, so the
report concept seems a best fit.
Unless you know differently.... ? :-))
Joanna
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker