Re: Schema provider/CA lookup status

Martin Aspeli <[email protected]> Fri, 14 Jul 2006 02:07:45 +0100
Newsgroups gmane.comp.web.zope.plone.archetypes.devel
Message-ID <[email protected]>
Okay, so there's a lot of really important discussion going on about the 
bigger picture, relating to Z3 schema interfaces, but I still think (and 
I think we agree) that giving AT some more flexibility in this regard 
will give us some real productivity gains in the near future, and 
wouldn't be too risky, so I'm quite keen on pushing it through to 1.5.

To that end, I'd just like to describe my use case a bit more, and 
perhaps we can use that as a guiding example to see how this may work. 
In fact, I expect the same patterns may apply to a Z3 world where 
schemas may still need to come from different places, and relate to 
Whit's "proposal for schema refactoring". I expect that if we can work 
out a pattern here, I'll put it into my product in the first instance as 
a standalone implementation, with a view to generalise and backport into 
Whit's branch whatever extensions may be necessary, and then switch my 
product to use the new infrastructure if/when it's merged.

Simplified, my product, 'company', uses membrane to support a case where 
Department is a folderish type, containing Employee objects. Departments 
become groups, and employees become users. An employee needs fields for 
username and password at a minimum, and a department has a reference 
field for delegating a manager (which gets a Manager role by way of a 
PAS plugin, I hope). So - membrane wiring, some base fields, some logic 
(e.g. password validation) - but nothing else.

Then, I'll write another product called 'charity', which depends on 
'company'. 'charity' will plug in some charity-specific fields for 
departments and employees, and register a view template to display them.

Thus, I need to:

  - Use some base fields always
  - Add (append?) some fields coming from an external component
  - Have this component (adapter? utility?) be local, so that it only 
affects sites where it's been installed (this is important, since it's 
possibly difficult to have more than one such product installed, e.g. 
'charity' and 'consultancy').

Now, I was going to analyse this a bit more in terms of whit's actual 
code, but it's way past bed-time after I started discussing naming with 
Rocky and Alec, so I'll keep it a bit more abstract :)

Basically, as I understand it, Whit's branch basically lets you register 
an adapter that can provide you a full ISchema. That lets you override 
the schema for an existing type wholesale, without having to subclass 
and re-register that entire object. For the site-local case (which I 
think will apply to most well-behaved products), that would mean a local 
adapter.

What I need is a bit more complex, since I need to have the fields from 
the base type *and* some extra fields. I think it may be possible to 
have some kind of general version of Whit's adapter that could be 
applied as an alternative in the case where you have the 'extension' use 
case. That is - the author of the original product probably knows best 
whether it's "extension" or "replacement" that matters.

For this, though, I'm unsure if I should

  - use a (local) adapter from IEmployee to some interface 
IAggregateSchemaProvider and have the schema logic do that

or if I should

  - look up a (local) utility.

The local utility approach feels a bit more natural (it's not really 
context-specific, it's more of a global registration), but in that case 
I either have to make a new utility and new aggregation logic for each 
type e.g. to look for an IEmployeeSchemaProvider, or look for named 
utilities for IAggregateSchemaProvider, where the name == the 
portal_type ('Employee'), though that doesn't feel very Zope3-ish. :)

Note that, I think, in most cases, the original type would be making 
some kind of assumptions about which fields it expected to be there 
always, so you'd have a more complex case of *some* fields needing to be 
there and *some* fields being replaceable. This is clearly harder to 
deal with, and I'm unsure if we'd need some way of marking fields as 
"necessary" vs. "optional" or if it's purely a documentation issue that 
is solved in the same way as the wholesale-replacement problem.

Martin



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