Re: [Zope3-Users] Re: Referencing objects in auto-generated forms
Hi,. On Sun, Apr 16, 2006 at 01:48:37PM -0500, Jeff Rush wrote: [snip] Frank, I thought vocabularies were being de-emphasized though, in favor of the newer 'sources' component? Vocabularies were good for short lists of choices, but because it read them all into memory at once not so good at lazy evaluation. Sources supposedly uses an iterator and is good for both short and long lists, as I roughly understand it. Hmm - I've heard about Sources before but I didn't know the difference to vocabularies. Thank you for the hint. BTW: Does de-emphasized mean deprecated and no longer supported in Zope3.nnn ? Regards, Frank ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] formlib problem
Hi, I can't use formlib, when I run the example in the form.txt I get this error: Traceback (most recent call last): File pyshell#29, line 1, in -toplevel- print MyForm(None, request)() File pyshell#26, line 6, in __call__ widgets = form.setUpWidgets(self.form_fields, 'form', self.context, self.request, ignore_request= ignore_request) File C:\Python24\Lib\site-packages\zope\formlib\form.py, line 255, in setUpWidgets IInputWidget) File C:\Python24\Lib\site-packages\zope\component\__init__.py, line 154, in getMultiAdapter raise ComponentLookupError(objects, interface, name) ComponentLookupError: ((, http://127.0.0.1), , u'') It happens when setUpWidgets is called in the first example, do I need to import something or to configure a component for formlib to work ? Any hint ? Thanks, Stéphane ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] ZEO Zope3 and Twisted
Is there any plan to provide security for ZEO client / server communication using Twisted now that it is in Zope3? Many thanks Regards, David ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Sending data to widgets
Hi, I need to send some data from a view class to all widgets that are used in the form. Unfortunately some of the widget that need to receive those data are contained e.g. in lists or dictionaries. I tried to do somthing like this: request._data=somedata My view class would add 'somedata' to the request and all the widget would be able to use it. But the the BrowserRequest doesn't like to be modified. It there a chance to transport data throught the request object without modifying the depth of the zope core? Maybe there's a way for widgets to access the view class directly? Regards, Frank ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Sending data to widgets
Hi Frank,
I need to send some data from a view class to all widgets that are
used in the form. Unfortunately some of the widget that need to receive those
data are contained e.g. in lists or dictionaries.
I tried to do somthing like this:
request._data=somedata
My view class would add 'somedata' to the request and all the widget would be
able
to use it.
But the the BrowserRequest doesn't like to be modified.
Right. Requests are read-only to the application.
It there a chance to transport data throught the request object
without modifying the depth of the zope core?
Maybe there's a way for widgets to access the view class directly?
A typical solution is to push data to the widgets. IWidget (from
zope.app.form.interfaces) defines a 'setRenderedValue' method for
widgets that can be used to do that.
If you are using zope.formlib, you can also implement a custom
setUpWidgets method (documented in IFormBaseCustomization from
zope.formlib.interfaces). The default one for edit forms looks like this:
def setUpWidgets(self, ignore_request=False):
self.adapters = {}
self.widgets = setUpEditWidgets(
self.form_fields, self.prefix, self.context, self.request,
adapters=self.adapters, ignore_request=ignore_request
)
setUpEditWidgets (defined in zope.formlib.form) will take the widget's
default values from self.context. For example, you could pass in
something other than that (perhaps an object holding the data you want
the widgets to present). You just have to make sure that it also
provides the interface that you're generating the form from.
Philipp
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Creating PluggableAuthentication problem.
Tobias Weber wrote: Hello! I try to add a PluggableAuthentication and a PrincipalFolder automatically. When I add a principal to the PrincipalFolder it works fine, but the authentification of the User fails. When I add one more PluggableAuthentication manually and choose the automatically generated PrincipalFolder as authenticator plugin, it works. Here is my code: [...] I am sorry for this code, I try to figure out how it works. Did you have a look at this thread: http://www.opensubscriber.com/message/zope3-users@zope.org/3786410.html There I pasted an example how I did it. HTH, mac ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Referencing objects in auto-generated forms
On Apr 18, 2006, at 3:31 AM, Frank Burkhardt wrote: Hi,. On Sun, Apr 16, 2006 at 01:48:37PM -0500, Jeff Rush wrote: [snip] Frank, I thought vocabularies were being de-emphasized though, in favor of the newer 'sources' component? Vocabularies were good for short lists of choices, but because it read them all into memory at once not so good at lazy evaluation. Sources supposedly uses an iterator and is good for both short and long lists, as I roughly understand it. No, actually, both can be used for infinite choices or finite choices. The primary difference to me is purity: sources break apart the token functionality--an aspect of display that widgets need--from the data definition. Up until fairly recently (i.e., post-3.2, I believe) you couldn't even express a finite source. There are still more vocabulary widgets than source widgets in zope.app.form. Sources are slated to replace vocabularies, but the uptake has been slow: I don't know of a hard date. Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Use Case for a Tree of Adapter Registries?
Jeff Rush wrote: I've read the code for adapter registries, how there is a global one and any number of local ones, arranged in a tree and that each can be disabled. But I can't figure out when you'd want to make use of such an arrangement. The docstrings and .txt files use abstract examples, for unit testing, and don't provide a motivation for this feature. Related to that, the global registry is loaded at server startup time from the various .zcml directives, and I presume that the only way to loaded up a local registry is thru-the-web, right? Which means all local registries are persistent in the ZODB, I think. Can anyone nudge me onto the right path? This is going to change with Zope 3.3 so unless you really need to understand how Zope 3.1 and 3.2 work in this respect, I recommend you take a look at the zope.component package in the jim-adapter branch of Zope 3 in SVN. The ideas behind the simplifications in this branch are: - There's one global component registry. - There can be other registries (no relation implied now). - If registries want to imply a relation, they can refer to other registries in their __bases__ attribute so that component lookup will cascade to those. - Registries *can* be persistent, but don't have to be. A persistent registry will typically adjust its __bases__ so that it refers to the next site's registry or, in case that doesn't exist, to the global registry. The result is that you will be able to register things to a non-persistent, but also non-global registry. This registry *could* be identified with a site. This essentially means that some local configuration can be expressed through ZCML and doesn't need persistent, TTW management. There's also a more low-level advantage. All those component registries are essentially one implementation with some very tiny variations. The code is very compact. The high-level advantage is that the APIs for global, local and/or persistent registrations are identical. HTH. Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] formlib problem
Stéphane Brault wrote: Hi, I can't use formlib, when I run the example in the form.txt I get this error: Traceback (most recent call last): File pyshell#29, line 1, in -toplevel- print MyForm(None, request)() File pyshell#26, line 6, in __call__ widgets = form.setUpWidgets(self.form_fields, 'form', self.context, self.request, ignore_request= ignore_request) File C:\Python24\Lib\site-packages\zope\formlib\form.py, line 255, in setUpWidgets IInputWidget) File C:\Python24\Lib\site-packages\zope\component\__init__.py, line 154, in getMultiAdapter raise ComponentLookupError(objects, interface, name) ComponentLookupError: ((, http://127.0.0.1), , u'') There seems to be something missing before , http... ... did you copy it form the browser output? It happens when setUpWidgets is called in the first example, do I need to import something or to configure a component for formlib to work ? Any hint ? Guess out of the dust: does the interface of the object you want to display have a zope.app.container.constraints.containers directive? This thread seems similar to your problem. http://mail.zope.org/pipermail/zope3-users/2006-March/002802.html HTH, mac ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Sending data to widgets
Hi,
On Tue, Apr 18, 2006 at 03:20:49PM +0200, Philipp von Weitershausen wrote:
[snip]
Right. Requests are read-only to the application.
It there a chance to transport data throught the request object
without modifying the depth of the zope core?
Maybe there's a way for widgets to access the view class directly?
A typical solution is to push data to the widgets. IWidget (from
zope.app.form.interfaces) defines a 'setRenderedValue' method for
widgets that can be used to do that.
If you are using zope.formlib, you can also implement a custom
setUpWidgets method (documented in IFormBaseCustomization from
zope.formlib.interfaces). The default one for edit forms looks like this:
def setUpWidgets(self, ignore_request=False):
self.adapters = {}
self.widgets = setUpEditWidgets(
self.form_fields, self.prefix, self.context, self.request,
adapters=self.adapters, ignore_request=ignore_request
)
setUpEditWidgets (defined in zope.formlib.form) will take the widget's
default values from self.context. For example, you could pass in
something other than that (perhaps an object holding the data you want
the widgets to present). You just have to make sure that it also
provides the interface that you're generating the form from.
My problem is not about data the widget should display but about data
that controls the widget's behaviour.
In this case my form consists of some widgets representing a schema interface
plus a special I18NController widget which is e.g. used to define, in which
order different language versions of the form's fields should be displayed.
(-This is about I18Nd content, stored in dictionary-fields)
Problem is: Some of the Widgets that should receive data from the
I18NController
are not known to the formlib because they are multiadapter-queried inside e.g.
a ListInputWidget. The request + the context seem to be the only objects
accessible
to all the widgets - but I don't want to store language order information in
zodb which
leaves the request object only.
Is there really no chance to store information as attributes of the request?
Regards,
Frank
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Blobs in Z3 anyone?
David Pratt wrote: Hi I had asked this question about a week ago with no response. Filesystem blobs are a valuable means of storing large object data in the filesystem instead of the ZODB. I have previously written a repository product in zope2 for blobs but would like to migrate to Z3. Does Z3 have an equivalent stream iterator of that of zpublisher? How are large objects currently handled in Z3 to get them into the DB efficiently if this is not the case? Many thanks. Christian Theune and Chris McDonough have been working on ZODB blob support for a while. The ZODB as our persistence layer is the right level to add blob support, not Zope 3. Once in the ZODB, blobs can be used across both Zope versions. Perhaps you might want to contact them and ask them whether you can help with something so that blobs will make it into ZODB 3.7 (scheduled to be released with Zope 2.10/3.3) Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Object modified or not
Hi, how does Zope decide, if a persistent object is modified? What I'm interested in: Does myobject._foo='bar' delattr(myobject,'_foo') make Zope create a new version of the 'myobject' in zodb? Regards, Frank ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Sending data to widgets
Hi Frank, My problem is not about data the widget should display but about data that controls the widget's behaviour. In this case my form consists of some widgets representing a schema interface plus a special I18NController widget which is e.g. used to define, in which order different language versions of the form's fields should be displayed. (-This is about I18Nd content, stored in dictionary-fields) Problem is: Some of the Widgets that should receive data from the I18NController are not known to the formlib because they are multiadapter-queried inside e.g. a ListInputWidget. The request + the context seem to be the only objects accessible to all the widgets - but I don't want to store language order information in zodb which leaves the request object only. Is there really no chance to store information as attributes of the request? Perhaps there is, but I would still advise against it. In this case I would recommend to make use of the adaption feature of zope.formlib. The context of the form and widgets doesn't necessarily have to be the persistent object itself. It can be an adapter. That way you can generate schema-based forms using schemas that aren't even provided by the object you're editing. zope.formlib will automatically adapt the object to the schema. The adapter will be responsible for mediating between formlib and the object. An example is the Metadata tab in the ZMI. The schema is something like IZopeDublinCore (at least some Dublin Core metadata), though no object really provides this data. However, there's an adapter that the data can be written to and that knows how to modify the object accordingly. In your case your adapter would probably behave like the original context except that it also stores this i18n ordering that you don't want to be stored persistently but still need for the form. Hope that helps Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re : FW: [Zope3-Users] formlib problem
Thanks Pete, I registered the adapters in the shell and it works. The trouble is that I have the same problem from zope. It seems that the adapters for the shema fields are not registered, therefore I can't have formlib working, even when I register the adapters by code. I don't know what to do. The fact is I use AJAX, so I don't have to register my pages, since they are never called, but used to generate the html I use to update my pages (which works fine otherwise). Maybe this explains the behaviour I get, but I doubt it. Stéphane - Message d'origine De : Pete Taylor [EMAIL PROTECTED] À : [EMAIL PROTECTED] Envoyé le : Mardi, 18 Avril 2006, 2h13mn 10s Objet : Re: FW: [Zope3-Users] formlib problem formlib works just fine, but from the shell i haven't had much luck either. probably need to look at the test suite that runs with form.txt and do the necessary setup for it to work correctly. i found it easier just to build a few sample forms and zcml, and learn by doing since getting the shell to work right was kinda a pain ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stéphane Brault Sent: Tuesday, April 18, 2006 7:42 AM To: user-list zope Subject: [Zope3-Users] formlib problem Hi, I can't use formlib, when I run the example in the form.txt I get this error: Traceback (most recent call last): File pyshell#29, line 1, in -toplevel- print MyForm(None, request)() File pyshell#26, line 6, in __call__ widgets = form.setUpWidgets(self.form_fields, 'form', self.context, self.request, ignore_request= ignore_request) File C:\Python24\Lib\site-packages\zope\formlib\form.py, line 255, in setUpWidgets IInputWidget) File C:\Python24\Lib\site-packages\zope\component\__init__.py, line 154, in getMultiAdapter raise ComponentLookupError(objects, interface, name) ComponentLookupError: ((, http://127.0.0.1), , u'') It happens when setUpWidgets is called in the first example, do I need to import something or to configure a component for formlib to work ? Any hint ? Thanks, Stéphane ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users -- All guilt is relative, loyalty counts, and never let your conscience be your guide. - Lucas Buck, American Gothic ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Object modified or not
Frank Burkhardt wrote: how does Zope decide, if a persistent object is modified? What I'm interested in: Does myobject._foo='bar' delattr(myobject,'_foo') del myobject._foo :) make Zope create a new version of the 'myobject' in zodb? Yes. Persistent objects are regarded modified when a) they have either received a new attribute, b) or an old attribute has been set to a new value, c) or an attribute has been deleted. Attributes starting with _v_ are considered volatile and won't count in this. Note that a) through c) above specifically don't mention the changes inside an attribute. Consider this: some_persistent_obj.alist = [] transaction.commit() # some_persistent_obj will be saved some_persistent_obj.alist.append(1) transaction.commit() # nothing happens because # some_persistent_obj itself # hasn't changed The workaround is to either make the 'alist' attribute a persisten object of its own (e.g. a PersistentList). That would mean it gets its own pickle and is stored independently of 'some_persistent_object'. This is usually preferrable for large lists or dicts. Another workaround is to explicitly mark 'some_persistent_obj' as changed: some_persistent_obj.alist.append(2) some_persistent_obj._p_changed = True transaction.commit() All of this is sort of explained in my book, but Gary Poster has convinced me that it wasn't explained well enough. This will be fixed. :) Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re : [Zope3-Users] formlib problem
Thanks Michael, There is indeed something missing : ComponentLookupError: (( zope.schema._bootstrapfields.Int object at 0x01A83610 , zope.publisher.browser.TestRequest instance URL=http://127.0.0.1 ), InterfaceClass zope.app.form.interfaces.IDisplayWidget , u'') My problem has nothing to do with containers, since my interface is not a container. It seems that zope can't find the adapters for the shema fields, even when I register them by code. I really don't know what to do from now. The fact is I use AJAX, so I don't need to register my views, I just call them from code to use the generated html as a response to a javascript call that then update my page. Thanks, Stéphane - Message d'origine De : Michael Howitz [EMAIL PROTECTED] À : Stéphane Brault [EMAIL PROTECTED] Cc : user-list zope zope3-users@zope.org Envoyé le : Mardi, 18 Avril 2006, 3h40mn 16s Objet : Re: [Zope3-Users] formlib problem Stéphane Brault wrote: Hi, I can't use formlib, when I run the example in the form.txt I get this error: Traceback (most recent call last): File pyshell#29, line 1, in -toplevel- print MyForm(None, request)() File pyshell#26, line 6, in __call__ widgets = form.setUpWidgets(self.form_fields, 'form', self.context, self.request, ignore_request= ignore_request) File C:\Python24\Lib\site-packages\zope\formlib\form.py, line 255, in setUpWidgets IInputWidget) File C:\Python24\Lib\site-packages\zope\component\__init__.py, line 154, in getMultiAdapter raise ComponentLookupError(objects, interface, name) ComponentLookupError: ((, http://127.0.0.1), , u'') There seems to be something missing before , http... ... did you copy it form the browser output? It happens when setUpWidgets is called in the first example, do I need to import something or to configure a component for formlib to work ? Any hint ? Guess out of the dust: does the interface of the object you want to display have a zope.app.container.constraints.containers directive? This thread seems similar to your problem. http://mail.zope.org/pipermail/zope3-users/2006-March/002802.html HTH, mac ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Sending data to widgets
On Apr 18, 2006, at 10:19 AM, Frank Burkhardt wrote: Hi, On Tue, Apr 18, 2006 at 04:04:43PM +0200, Philipp von Weitershausen wrote: Hi Frank, My problem is not about data the widget should display but about data that controls the widget's behaviour. In this case my form consists of some widgets representing a schema interface plus a special I18NController widget which is e.g. used to define, in which order different language versions of the form's fields should be displayed. (-This is about I18Nd content, stored in dictionary-fields) Problem is: Some of the Widgets that should receive data from the I18NController are not known to the formlib because they are multiadapter- queried inside e.g. a ListInputWidget. The request + the context seem to be the only objects accessible to all the widgets - but I don't want to store language order information in zodb which leaves the request object only. Is there really no chance to store information as attributes of the request? Perhaps there is, but I would still advise against it. In this case I would recommend to make use of the adaption feature of zope.formlib. The context of the form and widgets doesn't necessarily have to be the persistent object itself. It can be an adapter. That way you can generate schema-based forms using schemas that aren't even provided by the object you're editing. zope.formlib will automatically adapt the object to the schema. The adapter will be responsible for mediating between formlib and the object. An example is the Metadata tab in the ZMI. The schema is something like IZopeDublinCore (at least some Dublin Core metadata), though no object really provides this data. However, there's an adapter that the data can be written to and that knows how to modify the object accordingly. In your case your adapter would probably behave like the original context except that it also stores this i18n ordering that you don't want to be stored persistently but still need for the form. Perhaps it's overkill to write adapter for all my content objects. I think I found a solution. The Request object might be RO but I can smuggle an object reference inside the reponse headers and removed it after all the widgets are processed. augh! :-) Philipp is leading you correctly. I might even be tempted to write a custom form that directly set the data for the widgets myself; maybe that would be a quicker and easier approach to the same road. If you still don't want to listen to him, please don't do the response hack you are talking about. the request has an `annotations` attribute which experts can use to stash things away. Beware: this is a road that has bitten many in Zope 2, and is easily abused. Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Can't build Zope on OS X
Eric Williams wrote: Hi all. I’m having trouble building Zope on OS X. I’ve searched all over for a solution but could not find anything. Any help is much appreciated! [lots of stuff snipped] Seems to mee like you were using MacPython 2.4.3. According to http://bob.pythonmac.org/archives/2006/04/10/python-and-universal-binaries-on-mac-os-x/, it's not only a fork of the official Python 2.4.3, it also requires special precautions when building extensions (some SDK installed, etc.). Try again with the regular Python distro, either compiled from source or from darwinports or so. Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] url traversal and jsonserver
hi all, i've been looking at jsonserver recently, and am very impressed. however, my question doesn't really involve jsonserver functionality, so much as it does a bit of url traversal indirection. i have a simple dashboard like approach to a particular user interface design, where most of the content displayed to the user is determined by content associated with her/his principal id. like principal annotations sorta, only I needed/wanted a little more direct control. also, all of the content for a user is held in a registration utility, in ++etc++site. i've been using viewlets and formlib to give the users access to their data without actually having it in the standard traversal path. that way no smart user can think hmm, my url is some/path/my_user_id, let me ry some/path/johnsid etc. to them my.site/Consumer is all they need to see, which I like. what i would like to do is set up jsonrpc:view's for a number of the different content objects that the user has access to in her/his content directory. the trouble, for me, comes in when i need to give the javascript a ServiceProxy address. while i can probably figure out how to pass a particular url path to the javascript through some tales construction, it occurs to me that the object that jsonrpc view is actually providing a json-rpc view ON is under ++etc++site. i can't really pass that to the javascript, since I don't think ++etc++site is going to let the javascript (with the current principl's authority) connect. so what I'm wondering about is how to expose content held in a traversal path like http://my.site/++etc++site/MyRegistrationUtility/ConsumerStuff/some_user_id/stuff; to a json-rpc ServiceProxy. is it possible? is there a way i could get at this more indirectly? would principal annotations provide a better means of url exposure for picking up a serviceproxy? Thanks in advance for any thoughts or comments! Pete -- All guilt is relative, loyalty counts, and never let your conscience be your guide. - Lucas Buck, American Gothic ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
