[Zope] CMFBTreeFolder Behavior
fairwinds at eastlink.ca
Mon Feb 28 11:28:15 EST 2005
Hi Paul. Thank you for your reply. I think you are right on what is
happening with BTree and will try what you have suggested. I was just
going to try looping over the data but thought of this as strange and
should consult the list. I think the workflow approach to the problem
is likely the better one for sure since I already have the logic for
what I want to do with each image. Can this approach work on images on
the uploads folder only without affecting the behavior of images across
the entire portal? For example, if I set a boolean property on the
uploads folder and tested for it, can something like this be used to
determine whether the postprocessing script is run with workflow?
I will look for the DCWorkflow docs in the meantime. Many thanks.
On Monday, February 28, 2005, at 11:31 AM, Paul Winkler wrote:
> On Mon, Feb 28, 2005 at 10:07:48AM -0400, David Pratt wrote:
>> Hi. I am working with the CMFBTreeFolder for the first time. I
>> it would make sense since I am wanting to use this type for an uploads
>> folder. There may be thousands of objects. Once files have been
>> uploaded to the folder, I am running a script to pull out images using
>> a for statement like this:
>> # Iterate over folder contents
>> for name, obj in start_dir.objectItems(['Portal Image']):
>> and then executing some logic on the images afterwards. I am planning
>> to cron the script unless I can figure a way to execute the logic as
>> files are coming into the folder (which would be the best - so any
>> ideas here would be great).
>> In any case, what happens is that about half the objects get processed
>> with each run of the script. For example if I had 1030 objects about
>> half gets processed, and then half of that and so on. I may take 4
>> runs to get everything processed in the folder. On a normal Folder or
>> CMF Portal Folder, all objects get processed in one run.
> I'm just guessing, but it may be that in CMFBtreeFolder,
> objectItems() returns not a list but some kind of iterator
> that lazily gets the next batch of images. I don't know what
> you're *doing* with those images you find, but if the result is
> to change the result of what objectItems() would return, you
> might be getting into undefined behavior territory.
> Easy ways to find out would be
> 1) read the source of CMFBTreeFolder and maybe base classes.
> 2) try looping over list(start_dir.objectItems(['Portal Image'])
> instead and see if that just works.
> But maybe unacceptable performance
> if the list is really really huge.
> FWIW, I'd take a different approach (I think... hard to be
> sure since I don't know what you want to DO with these images):
> Use workflow.
> DCWorkflow provides for "automatic" transitions, where
> an object in one state can automatically transition to
> another state whenever some guard condition is met.
> So, write a script like "postprocessImage" that does what
> you want to *one* Image, add it to your Images workflow as a script
> in an automatic transition that always occurs from the workflow's
> initial state. The result is that this script will get called
> on every image exactly once just after it's created.
> There's a good doc on DCWorkflow somewhere, PDF I think.
> Google should find it.
> Paul Winkler
> Zope maillist - Zope at zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-dev )
More information about the Zope