Re: Options for making AT schemas more adaptive

Rob Miller wrote:
> Dieter Maurer wrote:
>> Rob Miller wrote at 2006-5-2 11:07 -0700:
>>> ...
>>> the first step in this process, i'd say, would be to define 
>>> ISchemaConsumer and ISchemaProvider interfaces.
>>
>> Why do you need both "ISchemaConsumer" and "ISchemaProvider"?
> 
> i think it makes sense to have an interface that explicitly specifies 
> that a given object supports AT schemas.

what kind of usecase are you thinking of here?

>> What should an "ISchemaConsumer" be at all. Note that schemas are
>> not "consumed". At least, it is a very badly chosen term...
> 
> 
> i chose 'consumer' just because it seemed the right balance to 
> 'provider'.  i'm not attached to the name.  maybe ISchemaSupporter would 
> be better.  other suggestions welcome.
> 

this may be simplistic, but I also want to make sure I have the concepts 
clear.

I think the concept of provision, aggregation, etc needs to stay behind 
the contract of the schema itself. My reasoning is as follows:

 From the perspective of most interactions with a schema, all that 
anybody should be concerned with is getting an object that fufills 
ISchema.  we shouldn't concern ourselves with whether or not a context 
provides or supports beyond whether or not we get an object back when we 
attempt to adapt.

How that schema object gets constructed is completely separate can of 
worms.

Here, I can see the use of an ISchemaProvider interface in particular 
components used for schema aggregregation, particularily in situation 
where you were not directly aggregating object's schemata (like in 
ATSENG, where an object can have it's own schema, as well as holding the 
schema for objects it manages). iirc, the schemaprovider branch allowed 
for this sort of aggregration by reference or acquisition; interfaces 
provide a way to constrain what object contribute to an aggregation.

there is another side to this too...many times we need subsets of a 
schema in a way that creating an aggregate schema and then filtering it 
would be inefficient. I'm guessing using separate interfaces to return 
what is needed on a case by case basis is the sensible thing here ie. 
IMetadataSchema(obj) or ICustomSubschemaForView(obj).

-w



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642