On Tuesday 24 January 2006 12:36, Alec Munro wrote:
> As part of an e-commerce system I am building, I need a way to specify
> a set of schemas that the purchaser must fill in data for. For
> example, in order to purchase product A, you need to select a paint
> colour, but in order to purchase product B, you must select 3 paint
> colours. I need a way for the site manager to specify this when adding
> products to the site.
I think this has little to do with the site manager. At least not directly.
> Currently, my plan for dealing with this is that I give all products a
> "product_attribute" property, which consists of a list of schemas.
I think what you want are product types. You can then assign a product type
(by directlyProvides) for each type you support. Then use the ideas in
zope.app.schemacontent to store the data.
The alternative is to develop local, persistent schemas. Unfortunately
interfaces have a bug that prevent persistent schemas, but Jim promised to
fix that soon.
> There are two relatively minor problems I have with this system:
> In order to get the schemas, I currently have them all subclassing
> IProductAttributes, and I look up the Interfaces vocabulary and parse
> it for descendants of IProductAttributes. I would like a simpler way
> to get them. One idea I had was creating my own Type, and declaring
> them all to be of that type. Unfortunately, I don't know how to get a
> list of all interfaces of a given type.
> The second problem I have is that the built-in widget for a List of
> Choices only allows you to select a single instance of each option
> available to the Choice. Is this inherent to the Choice field itself,
> or is it merely a limitation of the widget?
Right, it is a limitation of the choice field, which is always a single item
of a collection. Use the list or tuple field instead with a value_type that
is a choice field.
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-users mailing list