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

[Peter A. J. Pilgrim]

Michael Rimov wrote:
> At 05:52 AM 11/4/2002 -0800, you wrote:
> 
>> Choice 1 and 3 may have similar code bases, but would it not be better
>> encapsulation and possibly better re-use to go with choice 1?
>>
>> Just playing devil's advocate,
>> David Lloyd
>>
>> > >        DBObject.getField().asString()/.asDate()/.asInteger()  etc.
>> > >
>> > >                or
>> > >        (Date)DBObject.getField()/(String)DBObject.getField() etc.
>> > >                or
>> > >
>> > >        DBObject.getFieldString()/.getFieldInt()/.getFieldDecimal()
> 
> 
> Choice #1 DOES give us the ability to have custom Field types.  For 
> example, we can have a specialized DataField type called GIFField that 
> contains all the gif metadata.  Specially formatted fields are also a 
> possibility.  If we use an XML configuration, we could specify the class 
> to use for the field and then give us another layer of abstraction.  
> Thanks for playing opposite advocate here in the sense that it gives me 
> a chance to better think out things :)  I've used #1 in C++ Builder with 
> good results... but, like Larry said, it IS more typing, and it's a 
> matter of whether or not the migration is worth it.
> 
> I suppose if people started contributing custom data fields, then it 
> suddenly would become worthwhile to go with #1, but if nobody is 
> interested then it's not worth it.
> 
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?
-- 
Peter Pilgrim
ServerSide Java Specialist

My on-line resume and for interview videos about myself, J2EE
Open Source, Struts and Expresso.
    ||
    \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''