Re: Options for making AT schemas more adaptive

Martin Aspeli wrote:
> On Tue, 02 May 2006 19:07:47 +0100, Rob Miller 
> <ra-UE+B0n23d/[email protected]> wrote:
> 
>> the first step in this process, i'd say, would be to define 
>> ISchemaConsumer and ISchemaProvider interfaces.  BaseObject, and 
>> therefore all derived types, would implement ISchemaConsumer.  the 
>> BaseObject Schema() method would call ISchemaProvider(self) to 
>> retrieve an adapter that would actually return the schema object.
> 
> Out of interest, is the ISchemaConsumer any more than a marker?

wouldn't have to be at first, but it may eventually grow some actual 
content depending on the contract required by ISchemaProvider.

> Also, I think this is pretty much what whit just did ... and see my 
> latest reply to his post.
> 
>> the default implementation of this adapter would do exactly what it 
>> does now, simply accessing self.schema.  we'll want to deprecate 
>> direct schema attribute access... not quite sure how to achieve that; 
>> where do we put the deprecation message?
> 
> Make a property with an accessor method that spits a warning, perhaps?
> 
>> anyway, now we've got more flexibility.  adapters from more specific 
>> interfaces to ISchemaProvider can be implemented that will override 
>> the schema retrieval behaviour.  ATSENG support can then be gained via 
>> a marker interface, for instance, instead of the mix-in currently 
>> required.  also, the default adapter could be easily overridden if you 
>> want to change global schema behaviour.  we can also require that 
>> adapters to ISchemaProvider fire events to allow for subscribers to 
>> impact the process.
> 
> As I mentioned to whit, I think there's some more thought to be had 
> around having multiple schemas aggregated by this mechanism. E.g. a site 
> policy could install some fields, a tagging product could install its 
> own fields, and the type could have a few of its own. We could get all 
> adapters to ISchemaProvider from self, of course, but we'd then also 
> have to have some component responsible for sorting and merging the 
> schemata.

i'd say to take things one step at a time.  but yes, that's what you'd 
be able to do.  it seems pretty straightforward to have ISchemaProvider 
fire some events and include a bit of an API for manipulating the schema 
before it was actually provided back to the consumer.

-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