Re: [Zope3-dev] XML Schema support on Zope3
On 8/12/05, Julien Anguenot [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I started to add an XML Schema suppport on Zope3. It's within the z3ecm repository there : http://svn.nuxeo.org/trac/pub/browser/z3lab/zope/xmlschema/trunk/ You may check my related blog entry there : http://blogs.nuxeo.com/sections/blogs/julien_anguenot/2005_08_12_xml_schema_support_for Note it's using lxml as well (I love lxml :)) Having XForms support after this will be a lot easier ;) Comments / help are welcome. J. - -- Julien Anguenot | Nuxeo RD (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC/OFIGhoG8MxZ/pIRAvY+AKCEcPJb7CrM73xdm5aUgrW2gEbexwCgiQwu m1edCBXaQIVKQt4lFjxRwe0= =S8XP -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/alecmunro%40gmail.com If you will excuse the terminology, this is hot. :) I'm sure there are limitations, as Gary suggested, but simply having the schemas readily available in an XML format is great. On one hand, this gives me something Flash can use so it knows what to do with the data I pass it. That alone is very appealing. However we also have quite a bit of XML content that I want to import to Zope in the near future. If I'm able to use the existing schemas for that, that will be great. Thanks! Alec Munro ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Iterating over InternalPrincipal results in an infinite loop.
Perhaps this is intended behaviour, but if you create an instance of
InternalPrincipal, and then attempt to iterate over it, it will
infinitely return None.
The following code does the trick:
from zope.app.authentication.principalfolder import InternalPrincipal
joe = InternalPrincipal(joe, 123, Joe)
for key in joe:
print key
It took me a while to track this down, and now that I know what it is,
I'm sure I can work around it, but I thought it would be worth
bringing up. Here is InternalPrincipal's __getitem__
def __getitem__(self, attr):
if attr in ('title', 'description'):
return getattr(self, attr)
Alec Munro
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AttributeError: 'NoneType' object has no attribute '_implied'
Ar! Apparently, the problem was that the __getattr__ method in my adapter didn't raise an AttributeError if it failed. I do know better, but I really didn't expect it to manifest like this. Thanks for reading, and perhaps I can save someone else the day of debugging. Alec On 8/30/05, Alec Munro [EMAIL PROTECTED] wrote: This seems to be a regression, as I believe this was working with the beta. I don't have it pinned down entirely, but it seems to be related to an Annotation adapter I am using. The error occurs in zope.interface.interface, at the following location: def providedBy(self, ob): . spec = providedBy(ob) return self in spec._implied Printing spec gives: implementedBy zope.app.pagetemplate.simpleviewclass.SimpleViewClass from /usr/local/Zope-3.1.0c2/lib/python/zope/app/exception/browser/systemerror.pt Also, dir(spec) includes '_implied', so I really don't know what's going on. It isn't likely to be important, but I have commented out the import of the C optimized version of this method, so I could attempt to debug it. The error changed when I did this (it was AttributeError: 'NoneType' object has no attribute isOrExtends), but I assume that was simply because the C code was cloaking the error. I've attempted to track this down myself, but I really had no luck. I think I'll do some trial and error editing of my Annotations adapter, and see if that effects it. Thanks, Alec Munro ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Security mechanism finds permissions for Built-in principals, but not custom principals.
Well, it's gotten worse. I've been trying to narrow this down, and so far, haven't come up with anything promising. I'm now using the built in principal folder, and the associated principals, not ones of my own. My current failing test case boils down to: interfaces.py from zope.interface import Interface from zope.schema import TextLine from zope.app.annotation.interfaces import IAnnotatable class ISomeContent(Interface): text_content = TextLine( title = uText Content, description = uSome Text Content for testing) class ISomeContentAttributable(IAnnotatable): An object that can contain some content configure.zcml === configure xmlns=http://namespaces.zope.org/zope; xmlns:browser=http://namespaces.zope.org/browser; content class=zope.app.file.file.File implements interface=zope.app.annotation.interfaces.IAttributeAnnotatable .interfaces.ISomeContentAttributable / /content adapter for=.interfaces.ISomeContentAttributable provides=.interfaces.ISomeContent factory=.somecontent.SomeContent trusted=true / content class=.somecontent.SomeContent require permission=myproject.View interface=.interfaces.ISomeContent / require permission=zope.View set_schema=.interfaces.ISomeContent / /content browser:editform for=.interfaces.ISomeContentAttributable schema=.interfaces.ISomeContent label=Some Content name=content.html menu=zmi_views title=Some Content permission=zope.View / /configure somecontent.py = from zope.interface import implements from interfaces import ISomeContent KEY = somecontent.perm_tests class SomeContent(object): implements(ISomeContent) text_content = uapple def __init__(self, context): self.context = context So there's the code, if I change myproject.View to zope.View, everything works. I can grant myproject.View on the object itself, to the appropriate principal, and I will get an Unauthorized error. Yet if I change it to zope.View, it works. Any ideas? Thanks, Alec munro On 9/16/05, Alec Munro [EMAIL PROTECTED] wrote: Hi All, I have created my own principal source, as a bare derivative of principalfolder. My principals can log in, and are generally effective. However, there seems to be some lacking to them. Whenever I access any of a certain bunch of annotation adapters, I get a silent abort. That is, it prints abort on the command line, but no more information. My own personal experience is that these tend to be permission errors, so I assume it is something like that. What is especially odd is that I can assign the required permission to zope.anybody, and I am able to access the adapters. Doing a heavy sequence of print-based debugging, I found out that the error seems to occur during a sequence of calls to my adapters __getattr__ method. This method, in the case of my adapters, looks up the key in a mapping, and raises an attribute error if it is not there. In each case, the error occurs after it looks for a number of keys that aren't there, a long sequence of __parent__, and __conform__. These occur when I attempt to access a property of the adapter (any property). They also occur even when it works, such as if I'm using zope.anybody, so I don't think it is the calls themself that are causing there error. My impression is that the calls are related to zopes security machinery, and that for some reason they end up being executed in a place where they are unable to find the correct principal. I'm sure you need more information, but I'm not sure what would be helpful. Thanks, Alec Munro ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] xmlrpc introspection
I've run into precisely the same thing using JSON-RPC, and I did create a method to list all the other methods. However, I discovered through use that this was not nearly as simple as I thought. Because a single object can have multiple classes of JSON/XML methods, each one with their own or multiple view directives, and each view directive must specify the available methods, if each of those directives specifies a methodList method, then when you call it, you will likely get a list for a different class of methods than you were expecting. I'm sure there is some better way to implement it, but it seems it would require either some very messy coding, or some significant changes to the structure of Zope. Because it does not instantiate the view until after the method is requested, and it selects the view based on the requested method, it seems a generic methodList() is unlikely to be effective (unless you choose to keep all your methods for an object in a single view, which certainly would work in many cases, but was a pain for ours). Another possibility, it seems, would be to have a generic method that, in addition to introspecting the view it was called from, examined all the other views that might be applicable, and returned their methods. Any ideas for how to get around these limitations? I can't claim to be any sort of expert, so if I'm making false assumptions, or just plain wrong, please correct me. Take care, Alec Munro On 9/30/05, Tarek Ziadé [EMAIL PROTECTED] wrote: Hi all, I was wondering if there's actually any way to make xmlrpc introspection in Z3, so i can list methods from my rpc client. (it seems not, looking at the code and the agile doc there http://svn.zope.org/Zope3/trunk/src/zope/app/publisher/xmlrpc/README.txt?rev=38357view=markup) -- If not, i've found this proposal on the web: http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto-api-introspection.html I've thaught of wrapping my xmlrpc views with an adapter to provide the 3 extra methods in the view class: class IXMLRPCIntrospector(View): IXMLRPCIntrospector View [...] some constructor [...] def listMethods(): lists all xmlrpc methods implemented by the underlying view def methodHelp(method_name): returns the docstring of given method def methodSignature(method_name): returns the signature of given method ie the list of all arguments Any advice ? imo xmlrpc introspection can be useful in some cases (in my case i need such feature to actually let the client application remote-control the site) Would it be interesting to start a Z3 proposal on this topic ? Best regards, Tarek -- Tarek Ziadé, Nuxeo RD (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: tziade at nuxeo.com; tel: +33 (0) 6 30 37 02 63 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/alecmunro%40gmail.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
