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