Fwd: Re: Options for making AT schemas more adaptive

Seems Ben's good ideas were dropped off the list :)

Martin

------- Forwarded message -------
From: "Benjamin Saller" <bcsaller-5YxZ1of64+Pk/[email protected]>
To: [email protected]
Cc: "Rob Miller" <ra-UE+B0n23d/[email protected]>
Subject: Re: Options for making AT schemas more adaptive
Date: Wed, 03 May 2006 18:34:24 +0100

http://svn.plone.org/svn/archetypes/Archetypes/branches/historical/schema_provider-branch/docs/schema_provider.rst

Has design notes. In that same branch the schema package has Provider
which is the main class and then Collection and Compose which are the
two major phases used to assemble schema. Collection can be mostly
handled with adaptation like others have indicated. Composition can also
be somewhat complex if you have to preserve the same interface and
semantics of current AT.

What I would recommend is taking elements of these patches and moving
forward with them in the following way.

+ Each schema has its own unique id. This is currently a UUID but I
think a URI would work as well or better.

+ Move to the consistent get/set(key, [value], **kwargs) api. This will
remove the need to generate methods most of the time and makes
composition simpler. This flat interface doesn't play well with Z3's
notion of an interface for everything but... we can now adapt between
provided schema and the interface another component is looking for.

+ Open get/set to take an optional namespace instance.get("dc:Title")
instance.get("exif:Title") Each schema has a namespace prefix based on
its URI and can be used to load parallel namespaces as needed.
instance.get("Title") would access the schema with the highest priority
given the composition policy in place.




Martin Aspeli wrote:
> On Tue, 02 May 2006 20:31:13 +0100, Rob Miller  
> <ra-UE+B0n23d/[email protected]> wrote:
>
>> yeah, fair enough, but i'd encapsulate all of that into the  
>> functionality of the adapter providing ISchemaProvider.  in which case,  
>> we don't really lose anything by starting w/ a trivial implementation  
>> of this adapter, and then experimenting w/ more sophisticated  
>> implementations that support the aggregation.  that's one of the nicest  
>> things about the CA, it makes this sort of refactoring much simpler.
>
> +1
>
> I'd like to think a bit more about how such aggregation may work.  
> Perhaps Ben could tell us a bit more about how the schema_provider  
> branch worked (which I note is in branches/historical and I guess no  
> longer an active candidate?)
>
> Martin
>
>
>
> --"You can just adapt yourself out of it..." // Archipelago sprint  
> 26/04/2006




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