[Grok-dev] Iterativly emptying a grok.container shows weird behavior

[Dr. Volker Jaenisch]

HI GROK ME VOLKER!

Hello Martijn. Saw your wonderful presentation in Potsdam last week.
It encouraged me to do grokking. We are on to build
a large community portal and we will definitivly use zope3/GROK.

ME LIKE CODING STYLE. ME LIKE COMPONENTS!

But after the first hour with GROK I run into some weird things.

Starting with your last tutorial example I modified the code to
generate a lot of Entry-Instances (performance testing in mind).

    def update(self, name=None, text=None):
        if name is None or text is None:
          return
        for n in range(10):
            self.context[name + str(n)] = Entry(text + str(n) )

GROK RUN FAST! ME LIKE GROK!

Now to the weirdness:
If I implement a routine to SMASH Entry-Instances from the container:

    def update(self, name=None, text=None, value=None):
       """If empty text or name field delete all Entry instances"""
        if name is None or text is None or text == '' or name == '':
            for key in self.context.keys() :
                del self.context[ key ]
            return
        for n in range(10):
            self.context[name + str(n)] = Entry(text + str(n) )

only every second entry is deleted. [Sorry for this ugly coding.]


    Existing entries

    * e0 <http://10.3.0.45:8080/test1/e0>
    * e1 <http://10.3.0.45:8080/test1/e1>
    * e2 <http://10.3.0.45:8080/test1/e2>
    * e3 <http://10.3.0.45:8080/test1/e3>
    * e4 <http://10.3.0.45:8080/test1/e4>
    * e5 <http://10.3.0.45:8080/test1/e5>
    * e6 <http://10.3.0.45:8080/test1/e6>
    * e7 <http://10.3.0.45:8080/test1/e7>
    * e8 <http://10.3.0.45:8080/test1/e8>
    * e9 <http://10.3.0.45:8080/test1/e9>


    Add a new entry

Name: <empty>
Text: <empty>

    * e1 <http://10.3.0.45:8080/test1/e1>
    * e3 <http://10.3.0.45:8080/test1/e3>
    * e5 <http://10.3.0.45:8080/test1/e5>
    * e7 <http://10.3.0.45:8080/test1/e7>
    * e9 <http://10.3.0.45:8080/test1/e9>


ME VOLKER SAY SHIT! :-)

The reason for this behavior may be due to the fact that self 
context.keys() is
mapped to a OOBTreeItems instance instead of simply returning a list of 
keys - as a dict would do.
An OOBTreeItems seems to be an iterator/walker-like-class which operates 
on low level keys.

ME VOLKER ASK BUG OR FEATURE? VOLKER NO LIKE BUG! VOLKER NO LIKE FEATURE!

The problem is analogous to this one a (python) programming newby may 
run into
writing the following fragment of code:

alist = [1,2,3,4]

for i in range(3):
  del alist[i]

 >>>range eror<<<

print alist
[2, 4]

ME VOLKER WORK AROUND

class Sample(grok.Application, grok.Container):
    def emptyContainer( self ):
        keys = []
        for key in self._SampleContainer__data.keys():
            keys.append( key )

        for key in keys :
            print key.__class__
            del self._SampleContainer__data[ key ]

WORK AROUND STINKS!

Resume:
If you explain a CAVEMAN in the tutorial he may access a
grok.container the way he would use a python dict and
* learns he can ADD items as to a dict with [] notation.
* learns he can ADDRESS items as from a dict with [] notation.
* learns he can GET .keys() as from a dict.
* learns he may ITERATE over the .keys() to ACCESS the items in the 
container.
* FAILS iterativly DELETING all elements from a Container via the .keys().
then the CAVEMAN will get very FRUSTRATED! ME ANGRY!! ME SMASH GROK! 
SMASH!!!

I am sure that someone will now point me to a ZODB-API-Function
that will empty such a container flawlessly.

I do not write this posting in search of such a function.
As a CAVEMAN (addressed by GROK) myself also likes to have a container 
that behaves
not 80% like a python dict, but 100%.

I talked to lots of other CAVEMAN/CAVEWOMEN in Potsdam that are more
afraid of Zope3 than of the monolitic monster Zope2. The most heard
question at the conference (implicitly raised by the first keynote)
was "Should I use Zope3(GROK) or stay by Zope2 or change to Turbo-Gears 
or whatever?"

We should build a Zope3 or GROK that is truly intuitivly usable by the 
newby.

It may be a good idea to lower the barrier for the
GROK-Newbies by starting a grok-users mailing list.

Best Regards

Volker

-- 
====================================================
   inqbus it-consulting      +49 ( 341 )  5643800
   Dr.  Volker Jaenisch      http://www.inqbus.de
   Herloßsohnstr.    12      0 4 1 5 5    Leipzig
   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
====================================================