[Opensource] Future Code for Expresso 5.1 and beyond [LONG THINK TANK ARTICLE]

[Michael Rimov]

At 02:47 AM 11/7/2002 +0000, you wrote:
>I am not sure if I follow choice #1. Are you saying that DBField becomes the
>method to return data? For example
>
>         DBObject emp = new Employee();
>         DBField  field = emp.getField("lastName")
>         String   s = field.asString();
>         Date    d = field.asDate();
>
>If this what you had in mind. Give us an example?

Hi Peter,

Sorry, I was definitely NOT clear about the issue.  Choice #1 actually 
exists in CVS (Or actually in Expresso 5).

I should clarify how it's currently divided out.

DBField is really just field metadata, it has nothing to do with field values.
DataField is an interface that contains the actual value object.

So the current code is:

DBObject emp = new Employee();
DataField field = emp.getDataField("lastName");
String s = field.asString();
Date d = field.asDate();

Or for brevity:

String s = emp.getDataField("lastName").asString();

Or currently the 'alpha' APi allows:

Object o = emp.getDataField("lastName").getValue();

Which will return an Object.

You can create your own DataField derived class that implements, for example:
MyGifClass gif = ((GifDataField)emp.getDataField("picture").getGif();

All you would have to do is have the Gif data field created... that's a 
matter of factory methods, and since I'm working on the component work, how 
to assemble a DataObject class hasn't been cemented yet.  The default 
implementation I'm using is:
com.jcorporate.expresso.core.dataobjects.DefaultDataField()... but of 
course the actual guts of the implementation can change, I'm just looking 
for an API that will allow us to change the most flexibly.

Now... the current implementation currently deals internally as initial 
strings since we haven't implemented native fields.  I COMPLETELY agree 
with you that we need at the data layer, native support for Dates, 
BigDecimals, etc.  However, allowing for the framework to also convert the 
native types to whatever you need at the time can be time saving.

For the record, if anybody has programmed in Delphi/C++ Builder, this is 
similar to how their API works. Although they eventually have derived 
classes such as IntField, DateField, TimeField, etc.  But that's another 
issue. [And certainly not needed right now!]

No matter, what, in the next few versions,
String s = DBObject.getField("fieldname")

will still exist.  I think it will be several minor versions before the 
data api is ready for prime time. [It's certainly not even at alpha stage 
yet, I'm still trying to break apart DBObject into smaller parts.. look for 
a few hundred lines of code to disappear into other classes each minor 
version release:)]

Thanks for taking a look at this.
                                                 -Mike