List Info

Thread: Options for making AT schemas more adaptive




Options for making AT schemas more adaptive
user name
2006-05-03 04:20:35
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
_______________________________________________
Archetypes-devel mailing list
Archetypes-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/archet
ypes-devel
[1]

about | contact  Other archives ( Real Estate discussion Medical topics )