Re: [Zope3-Users] Re: looking for something like getUtilitiesFor...

[Chris Withers]

Philipp von Weitershausen wrote:
Utilities are never created when they're looked up. They're created when 
registered. Singletons (instances) are registered with the utility 
registry, never factories.


Ah, yes, of course, I think I'm looking for local utilities...

and all I'm then doing with the list is generating a drop-down for 
people to select from...


getUtilitiesFor is all we have. If you want that drop-down, consider 
using UtilityVocabulary from zope.app.component.vocabulary, e.g.:


 class FooUtilityNames(UtilityVocabulary):
 interface = IFoo
 nameOnly = True
 classProvides(IVocabularyFactory)

Register that as a utility:

  utility component=...FooUtilityNames name=Foo Utilities/

Then you can refer to it from a schema definition (Choice field).


Hmm, okay, how have the UI's for the creation of local utilities been 
built? (I'm thinking there must be some kind of drop-down somewhere with 
an Add list as in Zope 2's ZMI, and that must include the available 
types of local utility?)


Also, more theoretically, would you see indexes for a catalog as being 
local utilities. If not, what would you see them as being?


cheers,

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] __init__ method never called?

[FB]

Hi,

On Mon, Sep 18, 2006 at 03:37:28PM +0100, John Smith wrote:
 Hi everyone!
 
 the class
 zope.app.publisher.browser.fileresource.FileResource
 inherits from BrowserView and Resource in that order.
 
 As far as I can work out, the __init__ method in
 Resource
 (zope.app.publisher.browser.resource.Resource) is
 never called.

(Please correct me if I'm wrong, I'm not a Python guru :-) )

Whenever you inherit from two classes, only the first class'
__init__ method is called implicitely on create of a new instance.

If you want both base classes' init method to be called, do something
like this:

class MyView(BrowserView,Second):
   def __init__(self,context,request):
  BrowserView.__init__(self,context,request)
  Second.__init__(self,context,request)

Regards,

Frank
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Re: looking for something like getUtilitiesFor...

[Chris Withers]

Philipp von Weitershausen wrote:

Chris Withers wrote:

Philipp von Weitershausen wrote:
Utilities are never created when they're looked up. They're created 
when registered. Singletons (instances) are registered with the 
utility registry, never factories.


Ah, yes, of course, I think I'm looking for local utilities...


But even global utilities are *first* instantiated from their factory, 
then registered as singleton instances.


Yes, that's true, but unrelated...

In fact, in this case, the utilities that are global are just python 
functions marked with directlyProvides ;-)


Hmm, okay, how have the UI's for the creation of local utilities been 
built? (I'm thinking there must be some kind of drop-down somewhere 
with an Add list as in Zope 2's ZMI, and that must include the 
available types of local utility?)


Sure. Just use the standard Add menu in Zope 3. Some of the items 
there are potential local utilities, such as the Catalog, Cookie Client 
Id Manager, Error Logging Utiltiy, etc. You can add these objects 
anywhere, though it is recommended to do it within ++etc++site. The 
thing that makes them available as utilities is the registration. All 
objects have a Registration tab.


Ah, I see, so rather than using ZCML, you use the Registrations tab?
(now I'm dying to know if this has been implemented in Zope 2/Five)

That said, when you add a local utility in Zope 3, does it automatically 
register itself by default? It'd be quite annoying to have to:


1. add you thing that uses local utilities
2. oops, actually have to go create the local utility
3. great, now I have to register the damn local utility
4. finally, I can go back and tell my thing to use the new local utility

Ideally there'd be some way to do steps 2-4 automatically, but at the 
very least, having to manually do 3 seems superfluous, although I do 
like the idea of being able to manually un-register a utility...


Also, more theoretically, would you see indexes for a catalog as being 
local utilities. If not, what would you see them as being?


The catalog is the local utility.


That's also true, but also not really what I was getting at ;-)

It functions as a container for 
indices.


Indeed, and how are these indices managed? For me, an Index is a local 
(and potentially or maybe even definitely local to only that catalog) 
utility for ICatalogIndex (or whatever it may be called). For me it'd be 
nice to register the types of indexes using something like (and this is 
all pseudo code):


utility provides=catalog.interfaces.Index
 factory=catalog.fieldindex.FieldIndex
 name=Field Index/

utility provides=catalog.interfaces.Index
 factory=catalog.textindex.TextIndex
 name=Text Index/

...so you then have your list of addable index types.

How _is_ this done in Zope 3?

cheers,

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] Re: looking for something like getUtilitiesFor...

[Philipp von Weitershausen]

Chris Withers wrote:
Hmm, okay, how have the UI's for the creation of local utilities been 
built? (I'm thinking there must be some kind of drop-down somewhere 
with an Add list as in Zope 2's ZMI, and that must include the 
available types of local utility?)


Sure. Just use the standard Add menu in Zope 3. Some of the items 
there are potential local utilities, such as the Catalog, Cookie 
Client Id Manager, Error Logging Utiltiy, etc. You can add these 
objects anywhere, though it is recommended to do it within 
++etc++site. The thing that makes them available as utilities is the 
registration. All objects have a Registration tab.


Ah, I see, so rather than using ZCML, you use the Registrations tab?


Yes, exactly.


(now I'm dying to know if this has been implemented in Zope 2/Five)


No :(

But I'm trying to convince some of the Plone folks to work on that 
during the PloneConf sprints. I'll touch this topic briefly as well, as 
I'll try to get another shot at the Customize button for 
template-based views.


That said, when you add a local utility in Zope 3, does it automatically 
register itself by default?


No.


It'd be quite annoying to have to:

1. add you thing that uses local utilities
2. oops, actually have to go create the local utility
3. great, now I have to register the damn local utility
4. finally, I can go back and tell my thing to use the new local utility


That's how it is. Of course, you could subscribe to IObjectAddedEvent 
for those utilities and register them automatically when they're added. 
Zope doesn't do this by default because it doesn't want to be in your 
way. I sometimes have the several incarnations of the same local utility 
in my site manager, and I don't want Zope to guess which one it should 
take now.


Ideally there'd be some way to do steps 2-4 automatically, but at the 
very least, having to manually do 3 seems superfluous, although I do 
like the idea of being able to manually un-register a utility...


Right. Point is, you *can* automate. But Zope does no magic there. I 
think that's a big lesson learned from Zope 2.



It functions as a container for indices.


Indeed, and how are these indices managed? For me, an Index is a local 
(and potentially or maybe even definitely local to only that catalog) 
utility for ICatalogIndex (or whatever it may be called). For me it'd be 
nice to register the types of indexes using something like (and this is 
all pseudo code):


utility provides=catalog.interfaces.Index
 factory=catalog.fieldindex.FieldIndex
 name=Field Index/

utility provides=catalog.interfaces.Index
 factory=catalog.textindex.TextIndex
 name=Text Index/

...so you then have your list of addable index types.


Zope 3 does this via the standard Add menu. Go to the ZMI, add a 
catalog and you'll see that inside the catlaog you'll get a different 
Add menu. Voila.


Look at zc.catalog for lots more indices than Zope 3 comes with. 
zc.catalog's configuration should give you more examples on how to plug 
in new indices.



How _is_ this done in Zope 3?


I s wish I could RTFM you now, but my book ain't out yet. I already 
gave you the gist: The catalog is the letterbox company for indices. 
That means:


  - the catlaog contains the physical index objects (IOW, indices are
added inside the catalog) and therefore provides access to them via
the standard dictionary API (getUtility(ICatalog).values() gives you
the indices of the current catalog).

  - the catalog listens to object events and dispatches actions like
indexing and unindexing a document to its contained indices.

  - the catalog has a minimal querying API, but you're usually better of
getting a hold of the indices directly, querying them and joining
their results the way you want it. hurry.query helps a lot there.

Of course, you don't *have* use the catalog if you don't like its 
machinery. You could potentially place indices somewhere else and 
register them indidivudlaly as local components. You will then have to 
tell them yourself (via object event subscribers) when to index and 
unindex objects. Note that the standard catlaog indexes have a 
containment constraint in their interface that they can only be added to 
catalogs. That's why they don't show up in the Add menu for regular 
containers, only within catalogs.


Philipp

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Security in Zope 3

[Chris Withers]

Hi All,

Curious about security in Zope 3.

In Zope 2 the following would be bad:

class X(SimpleItem): pass
class Y(SimpleItem): pass
class Z(SimpleItem): pass

x = X()
y = Y()
z = Z()

x.y = y
x.z = z
y.z = z

...because z has two containment paths:

x.z
x.y.z

...which might have different security constraints.

How does Zope 3 handle the same kind of setup?

cheers,

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] __init__ method never called?

[FB]

Hi,

On Tue, Sep 19, 2006 at 04:53:45AM -0400, Stephan Richter wrote:
 On Tuesday 19 September 2006 03:47, FB wrote:
  (Please correct me if I'm wrong, I'm not a Python guru :-) )

[snip]

  class Join(First, Second):
 ... def __init__(self):
 ... print 'init 3-before'
 ... super(Join, self).__init__()
 ... print 'init 3-after'
 ...
  Join()
 init 3-before
 init 1-before
 init 2-before
 init 2-after
 init 1-after
 init 3-after
 __main__.Join object at 0xb7b5fb6c
 
 

Thank you for the clarification, Stephan. I know the meaning of 'super' a
lot better now.

Regards,

Frank
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] __init__ method never called?

[Stephan Richter]

On Tuesday 19 September 2006 03:47, FB wrote:
 (Please correct me if I'm wrong, I'm not a Python guru :-) )

 Whenever you inherit from two classes, only the first class'
 __init__ method is called implicitely on create of a new instance.

 class First(object):
...     def __init__(self):
...         print 'init 1-before'
...         super(First, self).__init__()
...         print 'init 1-after'
...
 class Second(object):
...     def __init__(self):
...         print 'init 2-before'
...         super(Second, self).__init__()
...         print 'init 2-after'
...
 class Join(First, Second):
...     def __init__(self):
...         print 'init 3-before'
...         super(Join, self).__init__()
...         print 'init 3-after'
...
 Join()
init 3-before
init 1-before
init 2-before
init 2-after
init 1-after
init 3-after
__main__.Join object at 0xb7b5fb6c


Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Security in Zope 3

[Martijn Pieters]

On 9/19/06, Chris Withers [EMAIL PROTECTED] wrote:

...because z has two containment paths:

x.z
x.y.z

...which might have different security constraints.

How does Zope 3 handle the same kind of setup?


In Zope2 containment is looked up through acquisition, that is,
implicitly. In Zope3 it is explicit, through the ILocation interface.
That interface specifies the __parent__ attribute, which normaly
specifies only one parent, as the current implementations of that
interface in Zope3 persist this or use a wrapper.

I a currently running application I store references to objects in
multiple places without problems just fine. Just be careful to clean
up when the object gets deleted from it's canonical location (the
__parent__ object).

--
Martijn Pieters
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Security in Zope 3

[Philipp von Weitershausen]

Martijn Pieters wrote:
On 9/19/06, Chris Withers 
[EMAIL PROTECTED] wrote:

...because z has two containment paths:

x.z
x.y.z

...which might have different security constraints.

How does Zope 3 handle the same kind of setup?


In Zope2 containment is looked up through acquisition, that is,
implicitly.


And it depends on the acquisition chain.


In Zope3 it is explicit, through the ILocation interface.
That interface specifies the __parent__ attribute, which normaly
specifies only one parent, as the current implementations of that
interface in Zope3 persist this or use a wrapper.

I a currently running application I store references to objects in
multiple places without problems just fine. Just be careful to clean
up when the object gets deleted from it's canonical location (the
__parent__ object).


Right, objects are suppoed to only have one __parent__ in Zope 3. 
Whether or not that __parent__ is actually used to look up security 
settings is entirely the decision of the securitypolicy you're using. 
YOu can always plug in a different policy that acquires security 
declarations in a different way than wlaking up the __parent__ hierarchy.


___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] __init__ method never called?

[John Smith]

Hi,
both Resource and BrowserView have a common parent
class, viz Location, whose parent class is object.

   object
 |
 |
 Location
   /   \
  / \
 /   \
   BrowserView   Resource
 \/
  \  /
   \/
FileResource


As there are no calls to super() in any of the
definitions of BrowserView, Reource, FileResource or
Location, only the __init__ method of BrowserView
would appear to be called because attribute lookup
proceeds through the parent classes in the order they
are provided in the definition.

This can be practically tested by inserting a
NotImplementedError into to the definition of
Resource.__init__.

I'm pretty certain that that method is never called,
unless perhaps somewhere else in zope there is another
class that inherits from it first.

Cheers,

John.


--- Stephan Richter [EMAIL PROTECTED]
wrote:

 On Tuesday 19 September 2006 03:47, FB wrote:
  (Please correct me if I'm wrong, I'm not a Python
 guru :-) )
 
  Whenever you inherit from two classes, only the
 first class'
  __init__ method is called implicitely on create of
 a new instance.
 
  class First(object):
 ... def __init__(self):
 ... print 'init 1-before'
 ... super(First, self).__init__()
 ... print 'init 1-after'
 ...
  class Second(object):
 ... def __init__(self):
 ... print 'init 2-before'
 ... super(Second, self).__init__()
 ... print 'init 2-after'
 ...
  class Join(First, Second):
 ... def __init__(self):
 ... print 'init 3-before'
 ... super(Join, self).__init__()
 ... print 'init 3-after'
 ...
  Join()
 init 3-before
 init 1-before
 init 2-before
 init 2-after
 init 1-after
 init 3-after
 __main__.Join object at 0xb7b5fb6c
 
 
 Regards,
 Stephan
 -- 
 Stephan Richter
 CBU Physics  Chemistry (B.S.) / Tufts Physics
 (Ph.D. student)
 Web2k - Web Software Design, Development and
 Training
 ___
 Zope3-users mailing list
 Zope3-users@zope.org
 http://mail.zope.org/mailman/listinfo/zope3-users
 




___ 
Yahoo! Photos – NEW, now offering a quality print service from just 8p a photo 
http://uk.photos.yahoo.com
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Re: NTLM credential plugin

[Simon Hang]

Good news. I believe I found a way to do NTLM 4-way handshake with
zope3 and using PAU's plugin. But I need to modify zope3's http server
a little bit, to let zope3 support HTTP/1.1 persistent connection.

Currently I can 
1. send NTLM challenge
2. receive NTLM type-1 message
3. send NTLM type-2 message
4. receive NTLM type-3 message.

Only thing to do is decode type-3 message.

My concern is I need to modify zope3's http server, althogh only add
several lines. Is there anybody can validate my modifcation and
implement the change in proper zope3's way?

Currently I modified zope.server.http.httptask.HTTPTask, method
prepareResponseHeaders(). to let this function also check
accumulated_headers before decides to close the connection. Sorry, I
left the modified code in my other pc, can't post the detail.

Anybody can help?

Thanks,
SimonOn 9/15/06, Simon Hang [EMAIL PROTECTED] wrote:
Hi,

Why zope3 can not maintain active connections? Is this because
zope3 is using asynchronous socket(asyncore.py) to serve the request?
Errr... why zope3 is doing this? Won't this method cause overhead?

Sorry for lots of questions, but I don't understand.

Thanks,
Simon
On 9/13/06, Gary Poster 
[EMAIL PROTECTED] wrote:
On Sep 13, 2006, at 2:30 AM, Philipp von Weitershausen wrote:
 Simon Hang wrote: Hi,
I'm thinging to write a NTLM credential plugin for zope3. But as I know, ntlm use 4-way handshake procedure, that means it needs two round-trips between server(zope3) and client(browser).
When I look in the credential plugins, it has challenge mothed. But seems it is only design for 1 round-trip protocol. It can issue one challenge, and return to parent script.
 I don't see how the PAU only allows one round-trip.AIUI (I just looked up NTLM last night out of curiosity: see http://
www.innovation.ch/personal/ronald/ntlm.html
), the problem is that the4 way handshake has to happen *within a single connection*.Apparently MS abuses HTTP to perform this.Implementing it inpluggable auth made me scratch my head a bit, so I didn't reply.You
would need to slurp the request, then push back to the response, thenslurp the same request again, then push back to the response, thenslurp one more time, and finally reply with the real request.Describing the problem to Benji, he mentioned WSGI--that does seem
like the only way I can imagine this working, and that would betricky enough, especially if you needed to reach into Zope for themanaged credentials.Once the WSGI plugin did its magic, it wouldneed to put something in the WSGI request that a pluggable auth
plugin was willing to accept as authentication.On the bright side, if you did this with WSGI you might be able tooffer this as a generic Python WSGI NTLM tool that required onlyminimal integration with the back end app server.
I'm glad I'm not tasked with this. :-DIt sounds interesting,though.Also, maybe I misunderstand: read the link if you want tocome up with your own interpretation.Gary___
Zope3-users mailing listZope3-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] Zope 3.2.1 make check issues...

[Felipe Barousse Boue]

Hello:
I'd appreciate your comments on the issue shown below which happens on
Fedora Core 5, stock python 2.4.3 (with python-devel 2.4.3 installed)
and Zope 3.2.1.

[EMAIL PROTECTED] Zope-3.2.1]$ ./configure --prefix /usr/local/Zope-3.2.1
--force --with-python /usr/bin/python2.4

Configuring Zope installation

Using Python interpreter at /usr/bin/python2.4

[EMAIL PROTECTED] Zope-3.2.1]$ make
/usr/bin/python2.4 install.py -q build
[EMAIL PROTECTED] Zope-3.2.1]$ make check
/usr/bin/python2.4 install.py -q build
/usr/bin/python2.4 test.py -v
Running tests at all levels
Running unit tests:
  Running:
..
***many dotted lines removed***
..
  Ran 8045 tests with 0 failures and 0 errors in 574.133 seconds.
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
func(*targs, **kargs)
  File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown
h.flush()
  File /usr/lib/python2.4/logging/__init__.py, line 718, in flush
self.stream.flush()
ValueError: I/O operation on closed file
Error in sys.exitfunc:
Traceback (most recent call last):
  File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
func(*targs, **kargs)
  File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown
h.flush()
  File /usr/lib/python2.4/logging/__init__.py, line 718, in flush
self.stream.flush()
ValueError: I/O operation on closed file

This is run as a NON root user. 
As you can see above, all tests are passed sucessfully (that's what it
seems, at least). 
Installation instructions on
http://www.zope.org/Products/Zope3/3.2.1/README.txt clearly state that
Zope 3 requires that Python 2.4.2 or newer be installed. (we have
python 2.4.3).
Have tried the same procedure on several FC5+Python 2.4.3+Zope 3.2.1
with exactly same results everytime.

I am missing something ?  Thanks in advance for your assistance,
comments, enlightenment

I am willing to, if required, update the installation docs, once we get
this resolved, including fixing the requirements or dependencies notes
of Zope 3, if any.

Thanks.

Felipe

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Conflicting configuration actions for protectName __setitem__

[Rob Campbell]

I know I read about this error somewhere before, but I haven't been able 
to find anything through Google searches.  I have a container that also 
has it's own attributes.  I am calling 
zope.app.container.constraints.contains from IFosterRecord, is that what 
is causing the __setitem__ problem?


Here is the traceback I have been getting:

zope.configuration.config.ConfigurationConflictError: Conflicting 
configuration

actions
  For: ('protectName', class 'rats.foster.FosterRecord', '__setitem__')
File /opt/zope/instance/lib/python/rats/configure.zcml, line 
25.2-45.2

class class='.foster.FosterRecord'
  implements

interface='zope.app.container.interfaces.IContainerNamesContainer'
  /
  require
permission='zope.View'
interface='zope.app.container.interfaces.IReadContainer'
  /
  require
permission='zope.ManageContent'
interface='zope.app.container.interfaces.IWriteContainer'
  /
  require
permission='zope.View'
interface='.interfaces.IFosterRecord'
  /
  require
permission='zope.ManageContent'
set_schema='.interfaces.IFosterRecord'
  /
/class

--
Rob Campbell
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Conflicting configuration actions for protectName __setitem__

[Darryl Cousins]

Hi Rob,

__setitem__ is likely also part of your IFosterRecord interface.

class IFosterRecord(IContainer)   #?

and this is causing the conflict.

Regards,
Darryl

On Tue, 2006-09-19 at 15:35 -0700, Rob Campbell wrote:
 I know I read about this error somewhere before, but I haven't been able 
 to find anything through Google searches.  I have a container that also 
 has it's own attributes.  I am calling 
 zope.app.container.constraints.contains from IFosterRecord, is that what 
 is causing the __setitem__ problem?
 
 Here is the traceback I have been getting:
 
 zope.configuration.config.ConfigurationConflictError: Conflicting 
 configuration
 actions
For: ('protectName', class 'rats.foster.FosterRecord', '__setitem__')
  File /opt/zope/instance/lib/python/rats/configure.zcml, line 
 25.2-45.2
  class class='.foster.FosterRecord'
implements
  
 interface='zope.app.container.interfaces.IContainerNamesContainer'
/
require
  permission='zope.View'
  interface='zope.app.container.interfaces.IReadContainer'
/
require
  permission='zope.ManageContent'
  interface='zope.app.container.interfaces.IWriteContainer'
/
require
  permission='zope.View'
  interface='.interfaces.IFosterRecord'
/
require
  permission='zope.ManageContent'
  set_schema='.interfaces.IFosterRecord'
/
  /class
 

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users