[Zope3-Users] Q: Custom containers, non-persistent items

[Paul Everitt]

On Nov 11, 2004, at 12:50 AM, Stephan Richter wrote:

> On Wednesday 10 November 2004 02:47, Paul Everitt wrote:
>> First, this is very much a newbie question, so apologies in advance.
>> Yesterday I sent this note to zope3-dev before this list was created,
>> but this question clearly isn't meant for zope3-dev.
>>
>> I'm trying to fill in the example in
>> zope/app/container/sample.py->SampleContainer.  My ultimate goal is to
>> traverse a custom container, grab the next item, and look it up in
>> Berkeley DB XML.  For example, dbxmlfolder/37 would look up an item
>> "37" in the DBXML and return some HTML that I generate.
>>
>> sample.py->SampleContainer has a method _newContainerData where you
>> supply a mapping.  I have wired this up, returning an empty 
>> dictionary,
>> and I can browse to dbxmlfolder.  I can't, though, browse to any items
>> in the dictionary.
>
> The dictionary is empty, so you cannot browse to any items. :-)
>
> I think using the SampleContainer might not be what you want to do. I 
> think it

Long-term, I imagine I'll want more control.  At this point, though, I 
have to manage the number of simultaneous new things to learn.

> would be better to start implementing IContainer from scratch; this 
> way you

I thought SampleContainer was a good starting point for seeing how to 
implement an IContainer?

If not, can you point to an example?  If my starting point is an empty 
Emacs buffer, then I'm in a bit of a pickle. :^)

> can control better what each method returns. In fact, you will be able 
> to
> create better optimized queries for the methods. For example, when 
> trying to
> get the number of items in the container, instead of taking the length 
> of the
> dictionary (which has to be created), you can probably write a more 
> efficient
> XPath expression to access the amount of items in the container.

Yep, that's a very good idea.

>> 1) Are the keys for this dictionary simple strings?
>
> The IContainer interface does not say so, but trust me, almost all of 
> Zope 3
> depends on them being unicode strings...I have been there before 
> trying to
> make ids integers...it is a miserable pain in the b***!

Will the interface tell me the rules for implementing containers?

>> 2) Are the values...errr, special in any way?  For example, can I just
>> put instances of Python classes that aren't wired into the CA (so I 
>> can
>> skip debugging ZCML, interfaces, factories, views, etc. until I get
>> past this traceback)?
>
> No, but in order for them to work well, the have to be ILocations; you 
> can put
> a proxy around the values before returning them using
> zope.app.location.locate(object, parent, name).

Uhh, ILocation?  Proxy?

That's my biggest problem at the moment.  There are ways that things 
are supposed to be done, but I don't know these patterns.  So my only 
realistic choice is to find an existing module/recipe that is close, 
and that led me to your traversal hook recipe and to SampleContainer.

It's looking like this container project is a bit too advanced for the 
newbie stage I'm at.

>> Stated differently, what is the least amount of work to get
>> _newContainerData to return non-empty sample information when
>> traversing to an item?  I'm looking for something like Bobo's
>> publishable mappings.
>
> Yeah, you can do this, but it would be expensive, since you either 
> would need
> a complex mapping object or do the query for all objects every time the
> container is created. I'd say implement IContainer yourself and be 
> happy. :-)

I'm at the stage of "knows a good bit of Python, a little Zope 2, has 
followed Zope 3 but not learned it".  If implementing an IContainer is 
straightforward, involves less than 15 new concepts (like ILocation, 
proxy), and is reasonably documented, I could give it a shot.

I have a feeling, though, that I'll need to learn more than 15 things 
about the CA before I even see "hello world" appear for an IContainer.  
The challenge is that I don't know which 15 things I'll need to learn. 
:^)

I had hoped that this was a Pythonic-kind of project that would be 
implemented more like Bobo way-back-when, where I could supply a Python 
mapping and something basic would work.  Then, I could start signing up 
for more contracts, one by one, and avail myself of more CA benefits 
one step at a time.

Thus, I guess I need to ask, what are the rules for implementing a 
container?  I could look at IContainer, but it has a rather deep 
interface inheritance hierarchy and nothing actually in its own 
interface.

Do I want IReadContainer? ISimpleReadContainer? IItemContainer?  
IItemMapping? IReadMapping?

I think it is IReadMapping that is the most basic definition I need to 
look at.  However, it only has two methods, get and __contains__.  
SampleContainer gave a longer list of things that might need to be 
implemented.

Thus, perhaps it is IEnumerableMapping (which is one of two parent 
interface of IReadContainer, which is a parent interface of IContainer) 
that gives the blueprint for the minimum of what I need to get started?

If I implement IReadMapping, but not IEnumerableMapping, is this still 
a minimally-functional component for traversal?

Looking at the interface docs for IEnumerableMapping, there isn't 
anything mentioned about unicode values for key arguments.  Nor 
anything about ILocation, though I imagine that's a different pattern 
and I shouldn't expect to see it explained in the container interface.

This is some pretty complex mojo. I don't think you should casually 
suggest to unsophisticated Zope 3 developers to implement their own 
IContainer.

--Paul