Re: Schema provider/CA lookup status

Raphael Ritz wrote:
> 
> Is what you are discussing here covering the following
> usecase?
> 
> "support arbitrary many (independent?) schema extenders"
> 
> What I mean by that is the following: people can install
> unforeseen combinations of 3rd-party add-on products which
> each in turn might want to change or extend a type's schema.
> If they are independent that should cause no problem, but:
> What if there is a conflict (e.g., two different products -
> not knowing of each other - are trying to change or add a
> field with the same name/id but intend to use this field for
> completely different purposes)? (real world example: quite a
> number of products (could want to) mess with the 'Subject'
> field.)
> 

It's a good point. I think it depends on what level of abstraction we keep
this at.

In 'company', the explicit design is that we have one schema extender that
we look up. 'company' is not designed to work with more than one concurrent
"customisation" applied. This goes for things like custom views and
workflows as well. Note that different Plone sites could have different
extensions installed (this may depend on Zope 2.10 and local adapters,
though).

In AT itself, the idea so far is to keep it simple - the most specific
adapter from self to ISchema will win, so again there can be only one (But
you could have multiple ones, and the most specific one would always win,
meaning you could register a generic site-wide one for IBaseObject and a
more specific one for IFoo). In the general use case, it's unlikely that we
could support arbitary "blind" extension from very generic components, since
code tends to depend on certain fields being available.

For the metadata use case specifically, we may want to provide a default
extension mechanism that lets you define some side-wide metadata. This could
even do a "find-all" operation (e.g. looking for named utilities) and call
them in sequence - we haven't quite designed that yet (though I'd quite like
to solve it in the general rather than have people invent their own).

Note that there's no reason why one adapter implementation couldn't choose
to delegate to or subclass another, so generic/common behaviour can still be
managed.

Martin
-- 
View this message in context: http://www.nabble.com/Schema-provider-CA-lookup-status-tf1921614.html#a5597079
Sent from the Archetypes - devel forum at Nabble.com.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV