Re: [Zope3-Users] Does zope.app.file.Image works ?
Hey, On Sun, 2007-05-20 at 02:04 +0200, Christophe Combelles wrote: Hi, Is zope.app.file.Image functional ? I'm trying to use it, but uploading or reuploading an image doesn't do anything excepted sometimes when I'm lucky. Is it maintained and tested? (I'm on 3.3.1) Yep, z.a.file.image is functional. My guess from your implied statement that the problem is intermittent is that your browser may be loading a cached image. Shift-[click refresh] may help. Hope that does it. Regards, Darryl Christophe ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: zc.queue conflict question
Gary Poster wrote: Why does adding to identical objects to a queue at the same time result in a conflict? Surely they should both just get added in an artbitary order? Basically, the constraint allows for more powerful conflict resolution, or at least simpler code. Um, can you explain that? How is adding two dissimilar objects different from adding two identical objects? I'd certainly welcome a variation that removed the constraint, possibly in exchange for weaker conflict resolution, if you were willing to contribute it to zc.queue. Sure, but I'm still hazy on what the problem with adding two identical objects is. Can you explain? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Does zope.app.file.Image works ?
Hey, On Sun, 2007-05-20 at 11:19 +0200, Christophe Combelles wrote: actually not. :( Pity, it seemed like such an easy answer. I've never struck the problem of only some files uploading. I have a small set of jpg images coming from different sources. Only two of them can be uploaded. The other ones don't upload at all, and validating the form just leads me again to the empty adding form. If I upload one that can be uploaded, no further modification can be done, and reuploading a different image does nothing, even if I shift-reload or use a different browser, or work on a new clean instance (without any added code) You might want to take a look at z3c.widget.image for an alternate widget. Regards, Darryl Christophe Darryl Cousins a écrit : Hey, On Sun, 2007-05-20 at 02:04 +0200, Christophe Combelles wrote: Hi, Is zope.app.file.Image functional ? I'm trying to use it, but uploading or reuploading an image doesn't do anything excepted sometimes when I'm lucky. Is it maintained and tested? (I'm on 3.3.1) Yep, z.a.file.image is functional. My guess from your implied statement that the problem is intermittent is that your browser may be loading a cached image. Shift-[click refresh] may help. Hope that does it. Regards, Darryl Christophe ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Does zope.app.file.Image works ?
the problem I found seems to be close from https://bugs.launchpad.net/zope3/+bug/98024 I cannot upload a file larger than 40kB. In zope.publisher.browser.py:263 cgi.FieldStorage only creates the two first fields, corresponding to ['field.contentType', 'field.data'] but the other fields are not parsed! So 'UPDATE_SUBMIT' and 'add_input_name' are missing ! And UPDATE_SUBMIT is used to start processing in the widget. There are TWO problems here : 1) a problem while parsing the input HTTP stream (or some limit I did not find) 2) The lack of any feedback or exception Christophe Christophe Combelles a écrit : thanks for your answers, I'm trying to investigate on this problem, because the same thing appears on z.a.file.file. I've not yet found why, but self.request.form is empty for certain files, not only images. Christophe Darryl Cousins a écrit : Hey, On Sun, 2007-05-20 at 11:19 +0200, Christophe Combelles wrote: actually not. :( Pity, it seemed like such an easy answer. I've never struck the problem of only some files uploading. I have a small set of jpg images coming from different sources. Only two of them can be uploaded. The other ones don't upload at all, and validating the form just leads me again to the empty adding form. If I upload one that can be uploaded, no further modification can be done, and reuploading a different image does nothing, even if I shift-reload or use a different browser, or work on a new clean instance (without any added code) You might want to take a look at z3c.widget.image for an alternate widget. Regards, Darryl Christophe Darryl Cousins a écrit : Hey, On Sun, 2007-05-20 at 02:04 +0200, Christophe Combelles wrote: Hi, Is zope.app.file.Image functional ? I'm trying to use it, but uploading or reuploading an image doesn't do anything excepted sometimes when I'm lucky. Is it maintained and tested? (I'm on 3.3.1) Yep, z.a.file.image is functional. My guess from your implied statement that the problem is intermittent is that your browser may be loading a cached image. Shift-[click refresh] may help. Hope that does it. Regards, Darryl Christophe ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Catalog
Hello everebody. Trying to use Catalog with the package based on S.Richter messageboard example. Add Catalog via ZMI. Add UniqueId Utility. Add Text index, with the interface ISearchableText, callable field searchable_title. Write adapter:implements(ISearchableText), adapts(IMessage), def searchable_title #8230; return self.context.title. Ok. After adding messages i can reindex my catalog, and numbers of documents and words are increased. I can do it from zmi and from code. I can also call DocCount() and WordCount() from code. It works. But I can`t call aplly() or searchResult() L Got: Forbidden attribute: apply. It looks like that only the methods which have permission: ManageServices (I can see it via Introspector) are working. What about the others? Their permissions are: n/a but cant call em, even with the manager rights. Where I did the mistake? - Вы уже с Yahoo!? Испытайте обновленную и улучшенную Yahoo! Почту!___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: zc.queue conflict question
On May 20, 2007, at 6:26 AM, Chris Withers wrote: Gary Poster wrote: Why does adding to identical objects to a queue at the same time result in a conflict? Surely they should both just get added in an artbitary order? Basically, the constraint allows for more powerful conflict resolution, or at least simpler code. Um, can you explain that? How is adding two dissimilar objects different from adding two identical objects? I'd certainly welcome a variation that removed the constraint, possibly in exchange for weaker conflict resolution, if you were willing to contribute it to zc.queue. Sure, but I'm still hazy on what the problem with adding two identical objects is. Can you explain? Sure. The `pull` is actually the interesting part, and it becomes more so when you allow an arbitrary pull. By asserting that you do not support having equal items in the queue at once, you can simply say that when you remove equal objects in the current state and the contemporary, conflicting state, it's a conflict error. Ideally you don't enter another equal item in that queue again, or else in fact this is still an error-prone heuristic: - start queue == [X]; - begin transactions A and B; - B removes X and commits; - transaction C adds X and Y and commits; - transaction A removes X and tries to commit, and conflict resolution code believes that it is ok to remove the new X from transaction C because it looks like it was just an addition of Y). Commit succeeds, and should not. If you don't assert that you can use equality to examine conflicts, then you have to come up with another heuristic. Given that the conflict resolution code only gets three states to resolve, I don't know of a reliable one. Therefore, zc.queue has a policy of assuming that it can use equality to distinguish items. It's limiting, but the code can have a better confidence of doing the right thing. Also, FWIW, this is policy I want: for my use cases, it would be possible to put in two items in a queue that handle the same issue. With the right equality code, this can be avoided with the policy the queue has now. It's worth noting that putting persistent.Persistent objects (or non- persistent objects that refer to persistent.Persistent objects in code used for conflict resolution) into objects with conflict- resolving behavior such as BTrees or zc.queues will stymie conflict resolution code, because persistent.Persistent objects other than the conflicted one are not around. This leads to a problem Jim and I recently discovered with zope.app.keyreference.persistent being used with intids. I intend to write up some blurbs about this and other issues in the zc.queue docs (although they are pertinent to BTrees too) asap. A collector issue would probably be in order too. Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
