Re: Options for making AT schemas more adaptive

whit wrote:
> 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.

*light bulb goes off above head*

okay, i think i see why we're misunderstanding each other... we're 
thinking about slightly different designs.  i'll clarify:

you're talking about having an object, foo, such that adapting that 
object using ISchema(foo) would return the appropriate schema object for 
foo.

i was talking about an ISchemaUser interface (thx to dieter for the 
name), which, upon further thought (sorry martin), would _not_ be a 
marker interface but would actually consist of the Schema() method.  the 
default implementation of this (in BaseObject) would look something like 
this:

def Schema(self):
     provider = ISchemaProvider(self)
     return provider.Schema()

and, in the default adapter which provides ISchemaProvider:

def Schema(self):
     return self.context.schema

the schema provider layer would be the place where any aggregation could 
occur.  ISchemaProvider would define methods where specific schematas or 
namespaced schemas could be returned, etc.

schemas themselves would of course still implement an ISchema interface.

if a non-BaseObject derived object wanted to use AT schemas for any 
reason, it would have to either implement or adapt to ISchemaUser.

i don't feel strongly re: one approach vs. the other.  adapting directly 
to the schema object is nice.  adapting to get a provider that is the 
explicit layer where schema aggregation can occur fits my brain a little 
better, though.

hope this clarifies.

-r



-------------------------------------------------------
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