Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation
Brandon Craig Rhodes wrote: Tres Seaver [EMAIL PROTECTED] writes: Martijn Faassen wrote: IFoo.adapt() for normal adaptation IFoo.multiadapt() for multi adaptation I'd rather have 'adapt' take *args for the contexts, and keywords for extras (like name). And you could make the default= another possible extra! In which case our proposals at the moment compare something like this: Brandon Utility? IFoo() Single adaptation IFoo(a) ... with default IFoo(a, default=y) Multi adaptation IFoo(multi=(a,b)) ... with default IFoo(multi=(a,b), default=y) Named multi adapter IFoo(multi=(a,b), name='z') ... with default IFoo(multi=(a,b), name='z', default=y) This syntax is pretty comfortable because you get code completion for free if you are using an ide (ex. eclipse pydev). At the moment IFoo() invokes the factory of an object (if registered). IMO the current implementation is a miss-feature because you can't assign any parameters. I would prefer that IFoo() does look up the default utility and IFoo(name='z') the named one. But this change could break existing code. Martijn/Tres Utility IFoo.adapt() Single adaptation IFoo.adapt(a) ... with default IFoo.adapt(a, default=y) Multi adaptation IFoo.adapt(a,b) ... with default IFoo.adapt(a,b, default=y) Named multi adapter IFoo.adapt(a,b, name='z') ... with default IFoo.adapt(a,b, name='z', default=y) Well, I have to admit, yours are a lot prettier. The word adapt takes no more characters than my multi, and parenthesis disappear! And though I might quibble that adapt() would be better spelled utility(), there is a nice symmetry about your idea. - Both patterns make it explicit to anyone reading the code when a default value is being passed, which should vastly reduce surprise. +1 - Mine feels more natural and Pythonic to people who, like PvW in his book, think of adaptation as being like casting. +1 -- Dominik Huber Perse Engineering GmbH Alte Landstrasse 6 CH-4658 Däniken Telefon +41 56 500 01 40 Direkt +41 56 500 01 41 E-Mail [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation
Marius Gedminas wrote: On Wed, Sep 26, 2007 at 09:09:37PM -0400, Tres Seaver wrote: Why does the caller care? She just wants an object which will provide the 'IFoo' contract on behalf of the passed context. If 'x' is capable of providing 'IFoo' without help, then failing (or worse, returning a less-specific factory result) when calling 'getAdapter' is the Wrong Thing (a least surprise violation, if nothing else). FWIW it was a big surprise to me when I discovered that IFoo(x) has different semantics from getAdapter(x, IFoo). That's true. I spent hours debugging errors related to the adaption mechanism. The different api's and its differing lookup mechanism is only one piece in the collection of obscurities. Other pieces are caused by different frameworks that using the underlying adaption mechanism: One problem is that sometimes implemented or adapted objects got treated in different way (ex. form-framework: it's modified event notification). Another problem is that an adapted context might not locatable if its adapter does not implement ILocation or does not get location proxied implicitly (ex. local/global security). All those examples and solutions are based on assumptions about implementations and that is causing the adaption-voodoo. Lookup by interfaces and therefore the adaption asserts a higher logical abstraction layer which should encapsulate such implementation details (like adaption-, localisation- and lookup-mechanism) in a *reasonable* way. If code that relies on this abstraction has to differ the underlying mechanism and the kind of the result, it is *necessary* to provide an api that covers those needs - IOW why should the caller care or make voodoo if he gets what he wants? It would be great, if we could handle other adaption-derivations by the proposed unified, reasonable adaption-api too. Example using the IFoo()-syntax: Single adaptation IFoo(a) ... with default IFoo(a, default=y) ... assert location IFoo(a, default=y, locate=True) ... no conform-call IFoo(a, default=y, coform=False) ... force adaptionIFoo(a, default=y, force_adaption=True) ... explicit context IFoo(a, context=specific_context) Multi adaptation IFoo(multi=(a,b)) ... with default IFoo(multi=(a,b), default=y) Named multi adapter IFoo(multi=(a,b), name='z') ... with default IFoo(multi=(a,b), name='z', default=y) ... assert location IFoo(multi=(a,b), default=y, locate=True) Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] OrderedMultiSelectWidget problem reloaded
Dear form-framework experts/users, Yesterday I applied the first time an editform to a schema containing a 'List' field of value_type 'Choice'. The OrderedMultiSelectWidget is invoked by default. At the first glance it works fine but by and by I discovered the following bugs/missfeatures: - Does not invoke adapted contexts correctly (source versus context, general problem of .utility.setUpEditWidgets()) - Does not take the _type attribute of the field into account (- .browser.itemwidgets.MultiDataHelper, .browser.sequencewidget.SequenceWidget) - Does not resolve vocabularies correctly in case of InputErrors (probably - overwrite _getFormValue of .browser.itemwidgets.ItemsMultiEditWidgetBase) - Does not differ choices in relation to the unique property of the field (- .browser.itemwidgets.OrderedMultiSelectWidget) - Does not handle missing_value of sequences (- .browser.itemwidgets.OrderedMultiSelectWidget) - Does not respect the min_length and max_length property of the underlying field like the sequence widget (- disable buttons) Afterwards I have seen that Adam reported already OrderedMultiSelectWidget problems (http://www.zope.org/Collectors/Zope3-dev/451). This issue was deferred by Jim. I spent a few hour to track down the problems on Zope 3.3.0 and produced the attached patch. Are people interested to resume this issue or not? Are there any objections in relation to the proposed patch? Regards, Dominik Index: browser/itemswidgets.py === --- browser/itemswidgets.py(revision 71100) +++ browser/itemswidgets.py(working copy) @@ -28,6 +28,7 @@ from zope.app.form.browser.widget import SimpleInputWidget, renderElement from zope.app.form.interfaces import IInputWidget, IDisplayWidget from zope.app.form.interfaces import ConversionError +from zope.app.form.interfaces import InputErrors from zope.app.pagetemplate.viewpagetemplatefile import ViewPageTemplateFile from zope.app.i18n import ZopeMessageFactory as _ @@ -144,7 +145,6 @@ It may be inherited from the mix-in classes SingleDataHelper\n or MultiDataHelper) - class SingleDataHelper(object): Mix-in helper class for getting the term from the HTML form. @@ -190,13 +190,14 @@ def _toFieldValue(self, input): See SimpleInputWidget if input is None: -return [] -if not isinstance(input, list): -input = [input] -try: -values = self.convertTokensToValues(input) -except InvalidValue, e: -raise ConversionError(Invalid value, e) +values = [] +else: +if not isinstance(input, list): +input = [input] +try: +values = self.convertTokensToValues(input) +except InvalidValue, e: +raise ConversionError(Invalid value, e) # All AbstractCollection fields have a `_type` attribute specifying # the type of collection. Use it to generate the correct type, @@ -209,7 +210,6 @@ else: return values - def _getDefault(self): # Return the default value for this widget; # may be overridden by subclasses. @@ -487,6 +487,36 @@ (no values)) _displayItemForMissingValue = False +def _getFormValue(self): +Returns a value suitable for use in an HTML form. +if not self._renderedValueSet(): +if self.hasInput(): + +# It's insane to use getInputValue this way. It can +# cause _error to get set spuriously. We'll work +# around this by saving and restoring _error if +# necessary. +error = self._error +try: +try: +value = self.getInputValue() +except InputErrors: +tokens = self.request.form.get(self.name, self._missing) +if isinstance(tokens, list): +return [self.vocabulary.getTermByToken(token).value for token in tokens] +elif not tokens: +return [] +else: +return [self.vocabulary.getTermByToken(tokens).value] + +finally: +self._error = error +else: +value = self._getDefault() +else: +value = self._data +return self._toFormValue(value) + def renderItems(self, value): if value == self.context.missing_value: values = [] @@ -519,7 +549,6 @@ extra=self.extra)) return '\n'.join(items) - class MultiSelectWidget(ItemsMultiEditWidgetBase): Provide a selection list for the list to be selected. @@ -539,27 +568,32 @@ template =
Re: [Zope3-dev] Weird error within __cmp__ method of KeyReferenceToPersistent
Hi Gary
Thanks for your inputs. I was also offline this days...
Gary Poster wrote:
[...]
Well, first of all, I suspect your situation, based on what I've seen
so far, looks something like this:
- code creates obj P1
- code puts P1 in intids, with connection.
- code does something incorrect (either your code or code that you are
relying on), probably involving a savepoint because of your discussion
below, that keeps keyreference to P1 in intids BTree, but rolls back
addition of P1 to connection. Right now we have the bad data (a key
reference to an object without a connection in the BTree), but we
don't know about it yet.
- Now code creates obj P2.
- code tries to put P2 in intids. If the BTree logic happens to make
it compare against the bad keyreference to P1, you get the __cmp__
error. This is a red herring for debugging: the problem has already
occurred (see above).
Yup.
Few more details:
There is a import handler which creates p1 , p2 to pn and sets those
object to a certain folder. After each addition of a certain p an
initializer subscriber listen to IObjectAddedEvent is invoked too. The
error occurs sometimes during this initialization. In case of an error
the creation and initialization of the error-prone p is rolled back by
an Importer (compare the following code):
class Importer(object):
def __call__(self, importhandelr)
[...]
for d in import_reader:
if not d[first].startswith('#'):
savepoint = transaction.savepoint()
try:
data = dict([(key, value for key, value in
d.items()])
importhandler(data) # - call importhandler
which creates the p
transaction.commit()
except Exception, e:
savepoint.rollback() # clean up
self.log.error(e)
I'm pretty sure your BTree is already bad by the time you get to the
failing __cmp__.
Yup
The only way I know to fix it at this late stage in the story is
drastic: you'll need to create a new BTree, iterate over the old one
and add all the contents except for the broken keyreferences, and
replace the old intid BTree with the new one.
I don't think that's appropriate error catching for the BTree code. I
think if you get the error you describe, you have a serious problem in
your code (i.e., code that you've written or code that you're
relying on in your stack, like Zope). How--and when--to handle it is
application policy, not something that should be in the base intids, I
think.
Yes, but the whole problem seems not so heavy:
1. If I restart the server no wrong intid entries are there.
2. If I patch the __cmp__ method of KeyReferenceToPersistent the
proposed way it only runs right after a wrong p creation into the
except. After another successful transaction commit I don't have any bad
intids entries
IMO that points that somehow the persistent data are ok. That we only
might have an 'old' volatile reference to a roled back intid somewhere,
that causes the error ... My problem is that I cannot the error
situation by a test case where intids are invoked. Probably it's a
problem of the order of invoked subscribers listen to the object added
event.
The error occurs after a savepoint.rollback. I can reproduce the
error within the basic error story (- see testcase). It happens if
we compare a commited persistent object with a rollbacked persistent
object.
The current implementation hurts the demeter's law. A fresh instance
does not support the db attribute, even though the situation showed
within the basic error story
from persistent import Persistent
p = Persistent()
p._p_jar.db().database_name
Traceback (most recent call last):
...
AttributeError: 'NoneType' object has no attribute 'db'
I remember knowing Demeter's law. ;-) I should look it up, but I've
already spent more time than I should have this morning. The above
behavior is expected. The connection.add(obj) code in the persistent
keyreference code gives the obj a _p_jar.
IMO the error should still be handled by KeyReferenceToPersistent
__cmp__ method.
This is too late. Anything at this stage in the game is going to be a
dangerous cover-up of an already serious problem.
Demeter says only long.dotted.name.calls() on references of an object
are leading to pretty instable code.
We have this problem in the current implementation as shown in the test
case. If we use rollback's we can produce an object state of a
persistent that does not allow to lookup p._p_jar.db().database_name.
That means the current implementation relies on an implicit interface
assumption too.
transaction.commit()
savepoint = transaction.savepoint()
p2 = P()
p2.__parent__ = top
keyref2 = KeyReferenceToPersistent(p2)
cmp(keyref1, keyref2)
-1
savepoint.rollback()
cmp(keyref1, keyref2)
Traceback (most recent call
Re: [Zope3-dev] soap and ZSI 2.0 patch
Hi Pete I'm very interested in that subject but I can't find any time at the moment. We have planned to use the ZSI to embed OPC-DAXML-Server in a customer-application based on Zope 3. So maybe I can give you some feedback in one or two month but I have to establish the essential know how first... Regards, Dominik Pete Taylor wrote: Hi all, I recently had reason to check out and use the soap product for Zope3. I needed it to work with the 3.2 HTTPRequest/Response api (setResult instead of self._body or setBody), so I made the changes I saw . I also wanted/needed it to work with the ZSI 2.0rc2 that's out now, so I updated that as well. I've created a branch: svn://svn.zope.org/repos/main/soap/branches/baldtrol-patch-001 which has my updates to soap/publisher.py. All the tests still run just fine, and I used the extant documentation to build my SOAPView, so it seems to need no changes either. I think it was just the publisher. This being my first actual contribution though, I was wondering if someone could go over the publisher.py in the branch, and let me know if it looks alright, maybe offer suggestions if anything doesn't make sense. Thanks for any help! Pete ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] What are zope.generic, z3c, ldapauth, et.al.?
Excuse my abscence. I'm a little busy and cannot find the time to track
the list daily.
Small summary of zope.generic:
it's a not-yet-fully-implemented, experimental prototype trying to find
a high-level-usage pattern or framework for zope 3.
During the easter-sprint I decided to put the code into the zope
repository. We came up with the name
zope.generic and Stephan told us it would be ok to put the stuff into a
dotted-named top level package.
We are using this code within two customer projects. We like the main
direction, but there is a lot stuff that has to be refactored (as usual)
and a lot of missing stuff that has to be implemented before we would
announce anything. We plan the first alpha-release in december.
Regards,
Dominik
Target
--
The zope.generic package should provide a higher level abstraction or
usage of the ca.
It should empower people with a analytical and technical background
(none- or fun-programmer) use the zope infrastructure.
Therefore the abstraction should allow to configurate components using a
generic logical pattern, to reuse features and a way to extend the
functionality with simple python function without knowing a lot about
the whole ca.
The behavior of those components (logical pattern) should be abstract,
but highly derived from object-orientation too, because the target
audience is pretty comfortable with that model (- comparable
abstraction would be ZClasses or object-oriented Requirement Analysis).
The application domain should be composed individually, that means
people should declare their own domain types rather than using a fix
domain types (- cms application - document, news, event, etc.)
The domain types itself should be composed using generic sub-component
and features.
Those features should be developed and implemented orthogonal and
generic manner. Such a feature implements technical functionalitiy. For
example there might be a document feature. You can enable the document
feature for a certain domain type. Afterward this domain type should
provide the feature. A feature requires some configuration of the
underlying domain type or an instance and it provides a certain api by
adaption. This configuration aspect should be solved generically using a
memento pattern.
Simplify by automation (- provide a complementary option to phillips
simplification-direction).
Design Goals
-
After the experiences with tiks. We decided to base the implementation
heavily on a marker interface pattern. That means there are only a few
generic base implementation (such as Object, Contained, Container,
Folder,...) that can be decorated by domain-specific
marker-interfaces.We decided to provide a mechanism that declares the
most important interface (key interface - keyface). This keyface is an
equivalent to class. The keyface can be used to look up the
corresponding configurations of a marked component. Those configurations
can be annotated directly to the object itself or might be provided by a
corresponding information providers (utilities) globally. We introduced
a new memento-implemenation called configuration. This is similar to
annotation but it is using configuration interfaces as keys instead of
id-string. Those configuration interfaces allows us to introspect
annonations more efficiently and to implement any configuration with a
generic base implementation.
Example
-
Step 1: Define your Key Interfaces: interfaces.py
class IMeasuringSystem(IWebApplication):
Mark the measuring system application.
contains('bopp.ms.measuringsystem.IProductionOrder')
containers(IWebPlatform)
class IOrder(Interface):
Mark an abstract order of the measuring-system.
class IProductionOrder(IOrder):
Mark a production order of the measuring-system.
contains('bopp.ms.measuringsystem.IProductionBatch')
containers(IMeasuringSystem)
class IProductionBatch(IOrder):
Mark a production batch of production order.
containers(IProductionOrder)
Step 2: Define dedicated configuration interfaces if necessary:
interfaces.py
class IMeasuringSystemConfiguration(Interface):
Input configuration of a messuringsystem.
data = TextLine(title=_(u'Data Directory'),
description=_(u'Main data directory.'),
required=True,
constraint=os.path.isdir,
max_length=255)
class IOrderConfiguration(Interface):
Abstract order.
aufnr = OrderID(title=_(u'Auftrag-Nr. (FAUF)'),
description=_(u'Fertigungs-Auftrag-Nummer der Charge'))
class AnyBatchEvent(ObjectEvent):
Notify any batch event
Step 3: Implement dedicated handlers in python if necessary: app.py
orderConfiguration = {'aufnr': u'9'}
def setup(context, *pos, **kws):
# make the folder to a site
ensureSite(context)
# add an int id utility
ensureIntIds(context)
ensureCatalog(context, IOrderConfiguration,
name=toDottedName(IMeasuringSystem), key=u'Catalog')
def anyBatchEventHandler(context, *pos,
Re: [Zope3-dev] help with directlyProvides
luis wrote: Jean-Marc Orliaguet wrote: luis wrote: are you sure? I tried with: [EMAIL PROTECTED] ~/Zope3/src $ python2.4 Python 2.4.2 (#1, Dec 4 2005, 15:28:38) Type help, copyright, credits or license for more information. from zope.app.file import file f = file.File() f zope.app.file.file.File object at 0xb7cbad2c import zope.interface class IMarker(zope.interface.Interface): ... Marker interface ... zope.interface.directlyProvides(f, IMarker) list(zope.interface.directlyProvidedBy(f)) [InterfaceClass __main__.IMarker] IMarker.providedBy(f) True yes.. that's why I say that it seems very strange... the call to directlyProvides works as you show with your example, ... *but*, after you add your file to a folder, something removes the IMarker interface (or it doesn't get saved for some reason ) directlyProvides( f, IMarker ) if not IMarker.providedBy( f ): raise Error myfolder['f'] = f if you put something like that in an Adding-Form, no exception is raised and the object f is added to the container. so the directlyProvides does work...but then, if you take a look at the object f in the zmi introspector, you will see something like: DirectlyProvided interfaces nothing so what I'm saying is not that directlyProvides doesnt work, but that provided-list gets lost somewhere on the way into the database... (but if f is a Folder, then the provided-list is kept ) luis If there is a bug in the container framework my assumption would be that that the following part of code causes your problem. The regular container asserts IContained either by the directlyProvides mechanism if the item provides ILocation or else by a ContainedProxy. zope.app.container.contained line 325: [...] if not IContained.providedBy(object): if ILocation.providedBy(object): zope.interface.directlyProvides( object, IContained, zope.interface.directlyProvidedBy(object)) else: object = ContainedProxy(object) [...] First try to provide IContained to your File implementation using the following zcml entry: class class=.to.your.File implements =.zope.app.container.interfaces.IContained / /class That should solve the problem. If yes, could you track down if the problem: Is it caused by the directlyProvided mechanism or by the ContainedProxy? (If no, perhaps a persistency problem?) Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dominik.huber%40perse.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Reducing the Amount of ZCML Directives ready for review
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Dominik Huber wrote: I really appreciate your effort in all other cases, but in this case I think its not a simplification. At least in case of class/implements it is. I'm merging two directives, class/implements and five:implements into one. The case of class/factory is arguable, I admit. However, there I'm just following the rule of a) defining things in Python and registering them in ZCML and b) use more basic ZCML directives, less special ones. That rule is somewhat debatable (the debate seems ongoing). I think we could argue the following equally well: if you find a directive unuseful, *just don't use it*. Register *new* directives (perhaps in a new namespace, if you want to reuse the names) which do your simpler / cleaner thing. Deprecation is not always a reasonable model, given disagreement about the value of the simplification. + 1 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Reducing the Amount of ZCML Directives ready for review
Philipp, I really appreciate your effort in all other cases, but in this case I think its not a simplification. The today's arrangement of class subdirectives is not an evil at all. We use all offered subdirectives (including implements and factory) heavily in our use cases. IMO It's important that nested directives embrace things belonging together. This enhances readability of the grouping and reduces redundant reference-informations. That's also a very important aspect of usability. I would be annoyed about the proposed changes. Regards, Dominik Philipp von Weitershausen wrote: Dominik Huber wrote: Philipp von Weitershausen wrote: * class/implements and class/factory weren't removed -- yet. I guess removing these might be a bit controversial. I'd therefore like to take this opportunity to bring this topic up again and to give everyone a chance to look at the proposal once again, before I start spending lots of time on the implementation. I'm -1 on moving implements out of the class directive Why? With a top-level implements directive, we get to deal with more general cases (not only classes can implement interfaces, functions can too). It will also let us get rid of the Five-specific five:implements directive for which there seems to be no good reason to be in the five namespace. With Reducing the Amount of ZCML Directives I'm looking mostly at consolidation of the existing stuff. It's ok to *introduce* a top-level implements, but not to *move*. and I'm still -1 on removing the factory subdirective. Would you care to explain why? I couldn't find a previous comment from you on that. [Zope3-dev] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives http://mail.zope.org/pipermail/zope3-dev/2006-February/018376.html Dominik Huber http://mail.zope.org/pipermail/zope3-dev/2006-February/018384.html Dominik Huber ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The Zope Software Certification Program and Common Repository Proposal
Stephan Richter wrote: On Wednesday 22 February 2006 10:58, Dominik Huber wrote: Do you have an other solutions for this problem? Honestly, I had not thought about this case, but it is clearly a valid use case. What about this structure? repos/main/ NAMESPACE/ branches/ tags/ trunk/ ...configure stuff here... NAMESPACE.PACKAGE1/ branches/ tags/ trunk/ NAMESPACE.PACKAGE2/ branches/ tags/ trunk/ [...] What do you think? I think this is the right way to do it, since it is a very logical procedure to flatten the namespace tree. We came up with the same solution first. But our problem appears within the following use case. A few developers are sharing code on application level (not package level!) for different dedicated customer projects. They have problems to setup identical dev-environments (packages with the same revisions etc.). So they want setup a dedicated application repository that brings different packages together using the svn:externals excessively. In the end developers should check-out this application repository (comparable to the Zope3/trunk) for joint development on application-level. The only way they could set the svn:externals-property using the above layout is the following: repos/main/ APPLICATION1/ branches/ tags/ trunk/ src/ - svn:externals: NAMESPACE url - svn:externals: NAMESPACE/PACKAGE1 url - svn:externals: NAMESPACE/PACKAGE2 url This scheme will work, but we have the disadvantage that they still cannot share application-specific configurations of NAMESPACE for further customer projects because they cannot link repos/main/APPLICATION1/trunk/src/NAMESPACE via svn:externals. The solution we came up was to put the '...configure stuff here...' *files* of the NAMESPACE not directly into the namespace itself, but in a dedicated *folder* for example 'configure': repos/main/ NAMESPACE/ branches/ tags/ trunk/ configure/ ...configure stuff here... That way we can move the svn:externals to the NAMESPACE folder of the APPLICATION1 repository: repos/main/ APPLICATION1/ branches/ tags/ trunk/ src/ NAMESPACE/ __init__.py - svn:externals: configure url - svn:externals: PACKAGE1 url - svn:externals: PACKAGE2 url This enables the developers to share this NAMESPACE configuration for further customer projects for example the following PROJECT01: repos/main/ PROJECT01/ branches/ tags/ trunk/ src/ - svn:externals: NAMESPACE url* *url = repos/main/APPLICATION1/trunk/src/NAMESPACE Did you catch our purpose? We think that could simplify joint development. So we might include such a 'configure-folder' convention or 'never-put-any-configure-stuff-inside-a-namespace' rule in the ZSCP and CRP-proposal. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The Zope Software Certification Program and Common Repository Proposal
Benji York wrote: Dominik Huber wrote: We came up with the same solution first. But our problem appears within the following use case. A few developers are sharing code on application level (not package level!) for different dedicated customer projects. They have problems to setup identical dev-environments (packages with the same revisions etc.). I need to carefully reread your message and reply with more detail later, but I'll make a drive-by comment first. :) Ultimately, reproducible developer buildouts can never be represented solely with Subversion (or likely any RCS). If you've been able to structure your projects such that it works, that's great, but that use case shouldn't be a driving force behind the common repository layout. Yes, I know that. I'm fully aware that our suggestion is kind of a workaround, but it works fairly good in pratice for a wide range of applications. Packages are one story of development. Other stories are exemplary applications that depends on a certain set of packages. Such a set is an important fine tuning (- matching revisions or tags etc.) in other words such a set is know-ledge about package combination that could be shared between different projects relying on the same exemplary application. It might minimize the barrier for new contributors and early adopters - IMO that's fairly important too. That's my driving force :) Regards, Dominik -- Dominik Huber Perse Engineering GmbH Jurastrasse 9a CH-5406 Baden E-Mail: [EMAIL PROTECTED] Telefon: ++41 44 586 6886 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives
Philipp von Weitershausen wrote: [...] I would vote to leave at least the class/factory and class/implements subdirectives. The class/implements subdirective is debatable because putting an interface on a class might be considered some sort of policy. So I don't feel too strong about it. Thanks :) The class/factory case however is clearly about automation. Yes, one aspect. This aspect is very important too. I love this automation and I'm probably not the only one. Look at Gary's statement I'll miss class/factory, As demonstrated in the proposal, the Python version with a simple utility directive is only two or so lines longer and essentially moves most of the information from ZCML to Python code. The move from ZCML to Python is often better, but not always. I tried to sketch the use case *including a class from an external library into an application*. My balance based on the attached example [1] summarizes the following: A) Extensive today: 10 text-lines in zcml B) Lazy today: 6 text-lines in zcml C) Exentsive proposed: 1O text-lines in zcml, 8 text-lines in py-module + retyping the IFactory-import each time D) Lazy proposed: 1O text-lines in zcml, 8 text-lines in py-module + retyping the IFactory-import each time So, the proposed solution is about 3 times (*not* 3 lines ;) costlier than the laziest-manner. It also reuses the well-known utility directive which makes registering factories very coherent: No matter whether they are custom or based on a callable like a factory from class, you just use the utility directive. Coherence is one of the initial problems I state in the proposal so I rather feel strongly about the class/factory case. I really support coherence and less-magic attempts, but in this case the price is definitely to high and the intended simplification is fairly questionable. The class/factory and createObject-pattern was always understandable for the Newbies I've met during the mini-sprints. The whole component-architecture in particular the adapter- and utility-mechanism was much more magic for them. Automation will stay a magic, but it enables often people to do things they don't fully (deeply) understand. IMO it's more important to offer coherent magics on a certain application-layer than to evangelise assembler or even quantum mechanics. As well there the magic will come back at a certain point on a deeper application level :) Still a very strong -1 on removing class/factory. Regards, Dominik [1] Example: A) Extensive today -- Today I have to write one ZCML...: class class=.alias.SydneyBristow implements interface=.interface.ISydneyBristowPolicyMarker / factory id=external.library.SydneyBristow title=Agent Sydney Bristow description=Sydney is an undercover agent working for the CIA / ... /class B) Lazy today - or in the laziest manner (B): class class=.alias.SydneyBristow implements interface=.interface.ISydneyBristowPolicyMarker / factory / ... /class Remark: Afterward I can use the zope.component.createObject(external.library.SydneyBristow) to create instances. C) Extensive proposed - After the proposed change I have to do the following: additional module for example alias.py: from zope.component.factory import Factory from external.library import SyndeyBristow sydneyFactory = Factory( SyndeyBristow, # a callable, e.g. a class title=(u'Agent Sydney Bristow'), description=(u'Sydney is an undercover agent working for the CIA') ) ZCML to register the class and the factory utility: class class=.alias.SydneyBristow implements interface=.interface.ISydneyBristowPolicyMarker / ... /class utility component=.alias.sydneyFactory provides=zope.component.interfaces.IFactory? http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ReducingTheAmountOfZCMLDirectives/editform?page=IFactory name=alias.SydneyBristow? http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ReducingTheAmountOfZCMLDirectives/editform?page=SydneyBristow / D) Lazy proposed dito - 2 text lines ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives
Philipp von Weitershausen wrote: Now that this proposal has been dealt with, I will turn my focus of attention to http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives. Since my initial announcement of the proposal I made some minor ammendments regarding the 'content' directive. Please check them out and give me feedback. I plan to start working on the implementation this week. I like those simplifications, but I have two little objections... The factory directive particularly within the class directive is very convenient and I use them fairly often. So I would miss that shortcut, because it saves a few lines of replicated code :( In addition the coupling of class/factory and class/implements is very concise and handy too, if you like to include 'external' packages into your application. In such a case I don't like to write an extra modul for the factory implementation and the class-implements-declaration. IMO this use case is focused to a component registration aspect and zcml would be the right place to cover it. I would vote to leave at least the class/factory and class/implements subdirectives. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Z3 widgets overview
Adam Groszer wrote: Hello, I had some time to finalize the widgets overview. You can download it from here in various formats: http://www.zope.org/Members/adamg/widget thanks, super! dominik -- Dominik Huber Perse Engineering GmbH Jurastrasse 9a CH-5406 Baden E-Mail: [EMAIL PROTECTED] Telefon: ++41 56 534 7730 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Jim Fulton wrote: I've updated the proposed APIs. I changed wording from provide to register as unprovide doesn't make sense. (This also conglicts less with existing APIs.) I like the new wording. Do you offer the new wording within the zapi too? That would be cool. zapi.registerAdapter() zapi.unregististerAdapter() ... Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Jim Fulton wrote: One issue with subscribers currently is that ZCML subscriber directives can't be overridden. We need a fix for this. In my understanding this usecase is covered by the new implementation, isn't it? Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Jim Fulton wrote: Dominik Huber wrote: Jim Fulton wrote: I've updated the proposed APIs. I changed wording from provide to register as unprovide doesn't make sense. (This also conglicts less with existing APIs.) I like the new wording. Do you offer the new wording within the zapi too? I'd prefer to get rid of zapi. Back when we used context wrappers, there were a lot more dead chickens in our code that zapi helped to manage. I personally never (well almost never) use zapi anymore. I would say that, in general, indirection is bad. In many cases, indirection is also good. It should only be used when the good of a particular indirection significantly outweighs the bad. IMO, the benefits of zapi don't outweight it's inherent obfuscation. +1, but then I have to change my question. Do you reflect the new wording within zope.component too? zope.component.registerAdapter ... and deprecate the old ones eventually zope.component.provideAdapter ... Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Jim Fulton wrote: Dominik Huber wrote: Jim Fulton wrote: One issue with subscribers currently is that ZCML subscriber directives can't be overridden. We need a fix for this. In my understanding this usecase is covered by the new implementation, isn't it? What new implementation? The proposed interface IComponentRegistry says: def unregisterSubscriptionAdapter(factory=None, adapts=None, provides=None, name=u''): Register a subscriber factory ... factory This is the object used to compute the adapter. The factory can be None, in which case any factories registered to implement the given provided interface for the given required specifications with the given name are unregistered. I thougt the planned component registry implementation covers that use case in principle, doesn't it? Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Stephan Richter wrote: On Thursday 02 February 2006 07:38, Jim Fulton wrote: Comments and questions are welcome. I like the proposal in general. The big missing use case that is missing for me is the task of unregistering or reregistering a persistent component. I like the proposal too, but if we start to allow utilities within the content-space, this unregistering or reregistering should be highly transparent for end-user. Therefore it might be still usefull to provide a marker interface such as ILocalUtility that can be triggered by little un/re-registering framework using the annotation of an utility to remember its registration-dependencies. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Interface implementation declaration weight (was Re: View lookup changes in Zope 3.2?)
Gary Poster wrote: I'm pretty sure there's a proposal on the wiki somewhere with Jim's full lookup algorithm that you want, but the iro for the pertinent object(s) usually gets me far enough. That might be the proposal you mentioned http://dev.zope.org/Zope3/ComponentArchitectureSimplification Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
Steve Alexander wrote: Who will use these interfaces? In what parts of the code will they be present? I think these marker interfaces are used only in infrastructure code to do with setting up layers and skins. In this case, they will not be typed often, and will not even be read often. So, I think it is more important that the name be clear than the name be short, so that it can be understood quickly upon reading it. As I mentioned, the dotted name already provides some semantics. IMO zope.app.publisher.browser.ISkinType does explicitly means that such a type is used for browser applications, otherwise it should be not within the browser package (unwritten convention). want your layer interface to show up for TTW view registration, you'll need ILayerType so that it shows up in the Browser Layers vocabulary and thus among the list of selectable layer interfaces. I strongly support this being an optional feature; a price you pay only if you care about TTW stuff. Me too. That said, I still think that in the long term, local registration should not be done TTW. So this optional notion of ILayerType might not be necessary in the future after all. For filesystem-based development I don't find any compelling usage for it at all. Me too. I'm not a TTW-fan at all, but IMO it is important that such a framework supports potential use cases as long we don't get unacceptable drawbacks. I'm really not interested in the never-ending file versus ttw development debate ;) Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
Philipp von Weitershausen wrote: (http://dev.zope.org/Zope3/SimplifySkinning) yet another overhaul. Basically, it now proposes to go one step further: Layers and skins will always be simple interfaces extending IBrowserRequest. The only difference between skins and layers is that only skins are registered as local utilities under a human readable name whereas layers are plain old boring interfaces with no extra marker (it's not needed at all). Along with that we can get rid of the browser:skin / and browser:layer / ZCML directives and simply reuse existing, much simpler directives from the standard Component Architecture (interface / and utility /). This is not only a good step towards reducing the ZCML directive proliferation, it's also a reflection of what's going on under the hood. If we simplify under the hood, the Zope 3 developer should benefit from that simplification as well. That's now happening. The rest of the changes deal with small harmonizations that should make the understanding of certain patterns easier (if they're always the same). Looking-for-comments-as-usual-ly +1 in general, but two cosmetics-change-requests. 1. The brand *skin* and *layer* are fairly common and they are reflecting two logical uses cases. At a first glance the usage for a layer type is not given, but the layer concept is still interesting to build modular skins. The layer audience could be the developers which like to share layer specific informations. IMO an use case for an Browser Layer Names utility could be a corresponding online-documentation within the api-doc. I would suggest to register the layers like skins using a ILayerBrowserType interface: interface interface=.interfaces.I18NFeatures type=zope.publisher.interfaces.browser.IBrowserLayerType / 2. I liked the naming ISkinType and ILayerType much more (instead of IBrowserSkinType/ IBrowserLayerType), because this browser-specific differentiation is already given by the package hierarchy and those ILongCamelCaseWordingsThatTriesToExplainEverything are hard to type and at the end they confuse newcomers even more than the simple ones. Please keep the naming also simple and stupid like the skinning simplification itself :) Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning
Phillip's Proposal: Furthermore, I propose to remove the |IDefaultLayer| interface. We've been using the |default| layer as a connotation of always being available unless overridden by a more specific layer. However, this does not apply all the time: When the |default| layer is not included in a specific skin, nothing from the |default| layer will be found even though the ZCML statements suggest that it would always be available. I therefore propose to make the |default| skin layer an alias for |IBrowserRequest|. Anything registered for |default| will obviously always be available then, no matter what your skin layer looks like. -1 I really appreciate that I can disable all registrations if I do not derive a skin from the default layer. That's very important use case for us. We introduced a minimal layer that is providing only the most important functionality like traversers etc. Regularly we derive end-user skins from this minimal layer and then we register all views explicitly so that we have full controll over accessibility of information. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning
Martijn Faassen wrote: Philipp von Weitershausen wrote: Looking for your comments at http://dev.zope.org/Zope3/SimplifySkinning. This is a follow-up proposal from http://www.zope.org/Collectors/Zope3-dev/444. I rather like having the *concept* skin to talk about. While implementation-wise things may become cleaner, being able to talk about a skin is I think a bit more clear than if you talk about skin layers. Similarly, I think it's a useful concept to talk to a layout developer about 'layers' as a separate concept, to indicate to them that a layer is not something necessarily directly exposed to an end user. I think that this use case is less strong than the one for maintaining the word 'skin', though. In various use cases, for instance Silva, there's a class of users that just wants to select from a list of skins installed for their site, and has no knowledge of how they're implemented. You don't want to show all layers to them. It would therefore be nice to have a way to mark particular skin layers as actual skins you want to expose to end-users, not just as things useful as a building block. This is something we use the skin mechanism for now, and that facility would, if I understand it correctly, go away in this proposal. +1 to all those Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dominik.huber%40perse.ch -- Dominik Huber Perse Engineering GmbH Jurastrasse 9a CH-5406 Baden E-Mail: [EMAIL PROTECTED] Telefon: ++41 56 534 7730 begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Security Proxy/isinstance
Andres Freund wrote: Hi, I'm working with the combination of Zope3 and sqlobjet over sqlos and discovered a problem (about SecurityProxy as i already asked about in #zope3-dev). Some code in sqlobject is using isinstance() to decide what to do. The problem is, that sometimes sqlobject gets securityProxied objects from Zope, which theoretically is no problem. But in praxis it uses isinstance and the SecurityProxy doesn't cooperate with that. Now i searched a bit in the web and discovered, that according to this: http://mail.python.org/pipermail/python-bugs-list/2003-February/016098.html it should be possible to make the Proxies a bit more transparent. Did i understand that correctly? I dont understand to much about python and especially about zope, but i think, that should be the way to go, or am i mistaken? After a short look at _zope_proxy_proxy.c i think that this shouldn't be too hard to implement (although i never touched the python c bindings before, so it not unlikely that I'm mistaken). You can use zapi.isinstance (zope.security.proxy orig. place). This function is useful because it works even if the instance is security proxied. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Event fixes
Florent Guillaume wrote: Dominik Huber wrote: The modification descriptiors were introduced by Uwe Ostermeier to handle the versioning and cataloging stuff. I'm not an expert in that field, but in my understanding the modification descriptors are more general and your case is a subset that could be handled with them. As a developer, I would still prefer one concept, because it's easier to adapt. Sufficiently fundamental cases are always a shaky discrimination to differ two concepts for future implementation decisions. If you don't feel that containment boundaries are a sufficiently fundamental concept, then we have a strong disagreement. An object modified event consumer such as a versioning or cataloging tool should handle modifications. In that respect the handling of ordered contaiment isn't more fundamental than handling of other ordered sequences and all use cases covered by modification descriptors today. I stand by what I checked in. IMO such a design decision would require a proposal :) And BTW with modification descriptions I couldn't write a simple adapter for this. I'd have to have a generic adapter for IObjectModifiedEvent, then iterate over all the descriptions and filter by hand. Yuck. OTOH, it is pretty hard for versioning or cataloging tools to guess derived subtypes of IObjectModifiedEvent and handle them generically. So, we still have to introduce kind of a mechanism similar to the modification descriptors to decouple our components. Perhaps the solution might be at least a mixture of both concepts. So we can derive subtypes *and* provide additionally modification descriptiors too. But then we would need - like Jim mentioned - a general strategy for modification descriptions.. 1. Sequence modification description: a. Sequence(IOrderedContainer) without any keys. 2. Dedicated modification descripton for the container framework ??? 3. Attributes modification description: a. Attributes(IOrderedContainer, 'updateOrder') b. Attributes(IEnumerableMapping, 'keys') Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Event fixes
Florent, But at least the event notifications within the setitem function is kind of redundant. An add-, move- and remove- event is a part of the container framework. Therefore we can assume that the underlying container referenced by the event.object.__parent__ has changed too. file: zope.app.container.contained.py: def setitem(container, setitemf, name, object): ... if event: notify(event) notifyContainerModified(container) Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Event fixes
Florent Guillaume wrote: I didn't follow Dominik's suggestion of using IModificationDescription because I feel this a case sufficiently fundamental that we really want a subclass. Excuse my intervention... The modification descriptiors were introduced by Uwe Ostermeier to handle the versioning and cataloging stuff. I'm not an expert in that field, but in my understanding the modification descriptors are more general and your case is a subset that could be handled with them. As a developer, I would still prefer one concept, because it's easier to adapt. Sufficiently fundamental cases are always a shaky discrimination to differ two concepts for future implementation decisions. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository
Philipp von Weitershausen wrote: Really, I'm quite tired of trench wars like Zope 2 vs. Zope 3. Like Martijn said, we need to come together, not apart. I'm starting to get the feeling that some Zope 3 developers rather see Zope 2 die than embrace some of its experience and community. At the moment Zope 2 depends from Zope 3. I'm fully aware that Zope 2 is a major user of the technology now and actively want to evolve towards Zope 3. So I'm aware that we have to cooperate some way. But I'm not shure, if such a fully reunite is the right step. It's possible to move *important and long term* packages from the Zope 2 to Zope 3 repository and support them at that place, because we already have that dependency. But and that's my point, there is really no clue bringing *everything* into Zope 3. Total reunite is never a winning strategy because it increases complexity of a system. IMO we already reached a critical level of complexity within Zope 3. The winning strategy would be to select important parts and push off the needless. Such a partial reunite strategy was never intended to be a war Zope 2 vs. Zope 3. It's just a question of the personal resources. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Philipp von Weitershausen wrote: Stephan Richter wrote: I will always vote -1 on such a move. I just simply punishes all those early adopters of Zope 3 and throw it in their face. Great appreciation! You know I can turn this around and say that by focusing all development on Zope 3, the Zope development team left Zope 2 out there to die in its old ways of doing things, despite the fact that some sort of transition capabilities were promised for a long time (maybe I needed to remind of you of this...). A rewrite from scratch is always easy, but dealing with the transition and deprecations is the hard work which is now left up to people who were early adopters of Zope *2* and hoping for that promised transition. Great appreciation! Philipp, I can't take that answer for bare, you are supporting the hick-hack too. Both parts had the opportunity to choose their strategies (Marketing/Business/Short term versus Technology/Long term). All strategies have cons and pros: 1. The spliting of the zope-community started when different frameworks like Plone, Silva etc. were pushed. We could observe in Switzerland two parties: the 'framework' developers and other zope developers. The latter regonized that all those frameworks can never be frameworks for a broad adoption in different fields and therefore they will never be a satisfying technical solution for envolving (long run) business domains. 2. At that time some people started to support Zope 3, because they recognized the true potential of Zope 3 and they assessed that only Zope 3 is able to hold the technological long term assurance and is able to hold the community together on a fundamental framework layer (Sharing packages and code). Some decided to go this 'idealistic' way and it was a trip through the desert (and the others had a nice time to make business ;) 3. This year we wanted to re-embrace the Zope-Community in Switzerland introducing the new technology (One of our idealistic targets). Therefore we organized 9 Zope 3-Mini-Sprints to close the gap between Zope 2 and Zope 3 developers. But - and that is an empiric fact and not an assumption - most of the established Zope 2 developers gave a shit about Zope 3: They never visited such a sprint or they stayed consequently in their waiting position until Zope 3 is finished/stable/usable. Most of the participants were customside 'framework' super users/developers that were interested in the new technology, because they were kind of tired of the 'framework' marketing fairy-tales. 4. Now the Zope 3 framework is stable and all people discover the fruits on the tree... Zope 3 dudes will enjoy their paradise, because they have a product that fullfills the marketing fairy-tales much better. The others have to make efforts to close up and fill the gap. In the end the amount of work is constant even though there were different ways (strategies). Are you physicist, aren't you? ;) Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: CustomWidgetFactory and widgets having different __init__ signature
Johan Carlsson wrote: Anywhere I can read up on what's happening with this issue/bug? - The class attribute of the widget-directive can handle a custom factory or a widget class. - The __call__ method of custom widget factory (zope.app.form.CustomWidgetFactory) invokes collection, choice and regular fields correctly (respection specific signatures) - Custom widget sequence factory (zope.app.form.CustomSequenceWidgetFactory) is deprecated because it does not satisfy the IViewFactory interface. Use the CustomWidgetFactory instead. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: CustomWidgetFactory and widgets having different __init__ signature
Johan Carlsson wrote: Dominik Huber wrote: Johan Carlsson wrote: Anywhere I can read up on what's happening with this issue/bug? - The class attribute of the widget-directive can handle a custom factory or a widget class. - The __call__ method of custom widget factory (zope.app.form.CustomWidgetFactory) invokes collection, choice and regular fields correctly (respection specific signatures) - Custom widget sequence factory (zope.app.form.CustomSequenceWidgetFactory) is deprecated because it does not satisfy the IViewFactory interface. Use the CustomWidgetFactory instead. This is in the trunk right? /Johan Yup. -- Dominik Huber Perse Engineering GmbH Jurastrasse 9a CH-5406 Baden E-Mail: [EMAIL PROTECTED] Telefon: ++41 56 534 7730 begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] __init__.py interfaces.py guidelines?
Martijn Faassen wrote: I don't think using any of these patterns is a big style problem (I'm much less opinionated about this than about code in __init__.py); it's hard to recommend a single practice, so perhaps we shouldn't. +1 Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: CustomWidgetFactory and widgets having different __init__ signature
Adam Groszer wrote: As I'm digging through zope.app.form.browser to fix the CustomWidgetFactory collector issue, I found the following: IWidget has no __init__ defined class Widget(object): def __init__(self, context, request): class ItemsWidgetBase(TranslationHook, SimpleInputWidget): def __init__(self, field, vocabulary, request): class ItemsEditWidgetBase(SingleDataHelper, ItemsWidgetBase): def __init__(self, field, vocabulary, request): class ObjectWidget(BrowserWidget, InputWidget): def __init__(self, context, request, factory, **kw): class SequenceWidget(BrowserWidget, InputWidget): def __init__(self, context, field, request, subwidget=None): class SequenceDisplayWidget(DisplayWidget): def __init__(self, context, field, request, subwidget=None): class SourceDisplayWidget(zope.app.form.Widget): def __init__(self, field, source, request): class SourceInputWidget(zope.app.form.InputWidget): def __init__(self, field, source, request): class SourceSelectWidget(zope.app.form.browser.SelectWidget): def __init__(self, field, source, request): CustomWidgetFactory fails on these different signatures. This affects the ZCML browser:widget field=... class=.../. Simple widgets will work, widgets with different signatures of course not. class CustomWidgetFactory(object): implements(IViewFactory) def __call__(self, context, request): class CustomSequenceWidgetFactory(object): implements(IViewFactory) def __call__(self, context, field, request): In fact, CustomSequenceWidgetFactory violates the IViewFactory interface with the different __call__ signature. That causes setUpWidget to fail. I'm wondering if this worked for anyone anytime. No, the widget stuff was broken long time ago. Phillip did some fixes within a branch, but this branch got deleted during the last repository cleaned up. I'm not shure which change the widget-refactoring will bring, that was the reason why I never was digging deeper. (svn://svn.zope.org/repos/main/Zope3/branches/f12gsprint-widget). Now I'm stuck a little bit. How does a good solution look like? My half-baked solution was up to today for Itemswidgets (which caused the error for me) to mark it with a different interface and look for that in CustomWidgetFactory and pass different arguments. Now I'm not so sure that this is the right one. The current solution does not covers ObjectWidgets. My solutions are half-baked too, but maybe we can collect them to get an overview (see attached file). The problem can be split in two parts: 1. __call__ with different signatures 2. creation/customization of widgets using the setattr(instance, name, value) Regards, Dominik from zope.component.interfaces import IViewFactory from zope.interface import implements from zope.schema.interfaces import IChoice, ICollection class CustomWidgetFactory(object): Custom Widget Factory. implements(IViewFactory) def __init__(self, widget_factory, *args, **kw): self._widget_factory = widget_factory self.args = args self.kw = kw def _create(self, args): instance = self._widget_factory(*args) for name, value in self.kw.items(): setattr(instance, name, value) return instance def __call__(self, context, request): return self._create((context, request) + self.args) class CustomSequenceWidgetFactory(CustomWidgetFactory): Custom sequence widget factory. def __call__(self, context, request): if not ICollection.providedBy(context): raise TypeError, Provided field does not provide ICollection. args = (context, context.value_type, request) + self.args return self._create(args) class CustomVocabularyWidgetFactory(CustomWidgetFactory): Custom vocabulary widget factory. def __call__(self, context, request): if not IChoice.providedBy(context): raise TypeError, Provided field does not provide ICollection. args = (context, context.vocabulary, request) + self.args return self._create(args) class TemplateWidgetFactory(CustomWidgetFactory): The view kw attribute is called like a ViewPageTemplateFile. def _create(self, args): instance = self._widget_factory(*args) for name, value in self.kw.items(): if name is 'view': setattr(instance, name, value(instance, instance.request)) else: setattr(instance, name, value) return instance class TemplateSequenceWidgetFactory(CustomSequenceWidgetFactory): The view kw attribute is called like a ViewPageTemplateFile. def _create(self, args): instance = self._widget_factory(*args) for name, value in self.kw.items(): if name is 'view': setattr(instance, name, value(instance, instance.request)) else: setattr(instance, name, value) return instance begin:vcard
Re: [Zope3-dev] How to provide some default utilities for sub-site
Hi Adam You need location information (- __parent__) for this setup. Regularly the object knows that information not until its addition to a container. Subscribe to ObjectAdded event and do the same setup within the handler and it will work. Regards, Dominik Adam Groszer wrote: I'd like to provide some default utilities for my sub-site. As I checked there is the nice ensureUtility method but as it turns out it failes with ... Module szscreen.app, line 339, in __init__ 'WorkflowUtility', WorkflowUtility, 'wfu') Module zope.app.appsetup.bootstrap, line 66, in ensureUtility name, **kw Module zope.app.appsetup.bootstrap, line 74, in addConfigureUtility utility_name = addUtility(root_folder, utility_type, utility_factory, **kw) Module zope.app.appsetup.bootstrap, line 83, in addUtility package = getSiteManagerDefault(root_folder) Module zope.app.appsetup.bootstrap, line 105, in getSiteManagerDefault package = traverse(root_folder, package_name) Module zope.app.traversing.api, line 96, in traverse return traverser.traverse(path, request=request) Module zope.app.traversing.adapters, line 120, in traverse curr = IPhysicallyLocatable(self.context).getRoot() Module zope.app.location.traversing, line 90, in getRoot raise TypeError(Not enough context to determine location root) TypeError: Not enough context to determine location root when it checks the existence of the utility it uses sm = root_folder.getSiteManager() but when it wants to add the non existing utility package = getSiteManagerDefault(root_folder) which in turn wants to traverse like this package_name = '/++etc++site/default' package = traverse(root_folder, package_name) Is there any way to easily solve the task? Excerpt from szscreen.app: class IApplication(IReadContainer, IPossibleSite, IAttributeAnnotatable): class Application(Persistent, SampleContainer, SiteManagerContainer): implements(IApplication) def __init__(self): SampleContainer.__init__(self) sm = LocalSiteManager(self) self.setSiteManager(sm) ... ensureUtility(self, IWorkflowUtility, 'WorkflowUtility', WorkflowUtility, 'wfu') -- Dominik Huber Perse Engineering GmbH Jurastrasse 9a CH-5406 Baden E-Mail: [EMAIL PROTECTED] Telefon: ++41 56 534 7730 begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] How to provide some default utilities for sub-site
Hi Adam First you have to assert that you object (obj) provides ISite. Then I would use the following attachted helper function `addLocalUtility` to add the your utiltiy. Least, you could use multi-subscriber for events providing IObjectEvent, then you don't have to check for IApplication. Putting all together you get the following (unproved) registration and code: subscriber handler=.app.App_boot for=.IApplication zope.app.container.interfaces.IObjectAddedEvent / def App_boot(obj, event): if not ISite.providedBy(obj): helper.addSiteManager(obj) helper.addLocalUtility(obj, 'wfu', 'WorkflowUtility', WorkflowUtility()) Regards, Dominik Adam Groszer wrote: Hello Dominik, I tried it using a subscriber. subscriber handler=.app.App_boot for=zope.app.container.interfaces.IObjectAddedEvent / def App_boot(event): # precondition obj = event.object if not IApplication.providedBy(obj): return ensureUtility(obj, IWorkflowProcessRepository, 'WorkflowProcessRepository', WorkflowProcessRepository, '') ensureUtility(obj, IWorkflowUtility, 'WorkflowUtility', WorkflowUtility, 'wfu') It works, but it adds the utilities to the global site manager :-( If the behavior is OK this way, then why do I have to pass the root_folder? I don't really get it. If I start to go my own way and copy+modify the zope.app.appsetup.bootstrap.py: def getSiteManagerDefault(root_folder): sm = root_folder.getSiteManager() #default = zapi.traverse(folder.getSiteManager(), 'default') #package_name = '/++etc++site/default' #package = traverse(root_folder, package_name) package_name = 'default' package = traverse(sm, package_name) return package then it is working. The 2 utilities land in the local site manager. Friday, November 4, 2005, 12:48:57 PM, you wrote: Hi Adam You need location information (- __parent__) for this setup. Regularly the object knows that information not until its addition to a container. Subscribe to ObjectAdded event and do the same setup within the handler and it will work. Regards, Dominik Adam Groszer wrote: I'd like to provide some default utilities for my sub-site. As I checked there is the nice ensureUtility method but as it turns out it failes with ... Module szscreen.app, line 339, in __init__ 'WorkflowUtility', WorkflowUtility, 'wfu') Module zope.app.appsetup.bootstrap, line 66, in ensureUtility name, **kw Module zope.app.appsetup.bootstrap, line 74, in addConfigureUtility utility_name = addUtility(root_folder, utility_type, utility_factory, **kw) Module zope.app.appsetup.bootstrap, line 83, in addUtility package = getSiteManagerDefault(root_folder) Module zope.app.appsetup.bootstrap, line 105, in getSiteManagerDefault package = traverse(root_folder, package_name) Module zope.app.traversing.api, line 96, in traverse return traverser.traverse(path, request=request) Module zope.app.traversing.adapters, line 120, in traverse curr = IPhysicallyLocatable(self.context).getRoot() Module zope.app.location.traversing, line 90, in getRoot raise TypeError(Not enough context to determine location root) TypeError: Not enough context to determine location root when it checks the existence of the utility it uses sm = root_folder.getSiteManager() but when it wants to add the non existing utility package = getSiteManagerDefault(root_folder) which in turn wants to traverse like this package_name = '/++etc++site/default' package = traverse(root_folder, package_name) Is there any way to easily solve the task? Excerpt from szscreen.app: class IApplication(IReadContainer, IPossibleSite, IAttributeAnnotatable): class Application(Persistent, SampleContainer, SiteManagerContainer): implements(IApplication) def __init__(self): SampleContainer.__init__(self) sm = LocalSiteManager(self) self.setSiteManager(sm) ... ensureUtility(self, IWorkflowUtility, 'WorkflowUtility', WorkflowUtility, 'wfu') -- Dominik Huber Perse Engineering GmbH Jurastrasse 9a CH-5406 Baden E-Mail: [EMAIL PROTECTED] Telefon: ++41 56 534 7730 ## # # Copyright (c) 2003, 2004, 2005 Projekt01 GmbH and Contributors. # All Rights Reserved. # # This software is subject to the provisions of the Zope Public License, # Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution. # THIS SOFTWARE IS PROVIDED AS IS AND ANY AND ALL EXPRESS OR IMPLIED # WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED # WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS # FOR A PARTICULAR PURPOSE
Re: [Zope3-dev] hurry.query in Zope 3.2?
Martijn Faassen wrote: Hey, Martijn Faassen wrote: Would there be any interest in merging hurry.query into Zope 3.2? Apparently not, or at least people are lacking in time, which is understandable as I do too. :) I'll try in more advance for Zope 3.3. We find it very useful here at Infrae, but of course it works just fine as a stand-alone library too. Lacking in time I just read the query.txt and I would appreciate this package. Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
Hi Stephan, I just looked at the examples. I like the current implementation much more, because a viewlet is adapted to its original context (- complex example) and content providers (or viewlet managers) can render itself. Those changes are providing a better encapsulation and a more ca-like comprehension. Cool - Thank you very much! IMO it is very important to provide a standardized way to handle complex, formbased views properly (- prefix like nested widgets) and to sketch the difference between widgets and viewlets out. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
Stephan Richter wrote: On Tuesday 11 October 2005 12:41, Philipp von Weitershausen wrote: If anyone here really needs WYSIWYG, please make a point, but I doubt that there will be one... It's a top priority for Jim. Uwe and I agreed we would prefer ReST. I would definitely prefer ReST too. Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Security mechanism finds permissions for Built-in principals, but not custom principals.
Hi Alec Your derivative of principalfolder is a local authentication. Therefore it can be only invoked if a location can be computed and the pricipalfolder can be found starting from it. Content objects are regularly locatable but adapters not. To force locations to adapters you can derive them from Location or set the adapter-directive-attribute `locate` to True, that they get location-proxied if necessary. Regards, Dominik Alec Munro wrote: 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/dominik.huber%40perse.ch begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Should major for-reaching changes be made for purposes of style?
Jim Fulton wrote: A change in style, if applied everywhere can lead to massive code changes. This can have serious downsides. If people are working on branches, where most new work should be done, then merging is made more difficult. People who read the checkins have a lot of extra code to review for a small benefit. (I don't read the checkins regularly myself and really *really* *REALLY* appreciate the efforts of folks that do and don't want to make their job harder.) OTOH, consistent style is beneficial. :) I'm interested in hearing what people think about this in general. Should we make far reaching code changes to enforce a consistent style? Or should we update style when making other changes? I tend to do the later. I think that the developers of Python prefer that changes like this be made more gradually. They've been burned by mass changes in the past. Thoughts? Consistent style is very important and IMO it's great that some code-cleaner look after 'none-stylish' code. It might just a problem of timing that code-refactorer and code-cleaner don't hurts each other. Perhaps we just have to separate cleaning and merging periods more explicitly. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] problems with browser:widget
Adam Groszer wrote: I'm having problems with using browser:widget. I have an interface: class ISzerep(Interface): name = TextLine( title=uSzerep nev, description=uSzerep nev, required=True ) szemelyek = List( title=uHozzarendelt szemelyek, description=uHozzarendelt szemelyek, required=False, value_type=Choice(vocabulary=szemely) ) If I add a simple add (or edit) form: browser:addform schema=szscreen.interfaces.ISzemely content_factory=szscreen.app.Szemely label=Uj Szemely name=AddSzemely.html permission=zope.ManageContent set_before_add=name /browser:addform everything goes well, an OrderedMultiSelectWidget is displayed in the browser by default for the *szemelyek* field. If I modify the addform configuration by adding the widget: browser:addform schema=szscreen.interfaces.ISzemely content_factory=szscreen.app.Szemely label=Uj Szemely name=AddSzemely.html permission=zope.ManageContent set_before_add=name widget field=szerepek class=zope.app.form.browser.OrderedMultiSelectWidget/ /browser:addform You cannot register the widget class directly, but you have to provide a specific widget factory. Example edit.py within your browser directory: from zope.app.form import CustomWidgetFactory from zope.app.form.browser import OrderedMultiSelectWidget szerepek_widget_factory = CustomWidgetFactory(OrderedMultiSelectWidget) Example registration within the configure.zcml: browser:addform schema=szscreen.interfaces.ISzemely content_factory=szscreen.app.Szemely label=Uj Szemely name=AddSzemely.html permission=zope.ManageContent set_before_add=name widget field=szerepek class=.edit.szerepek_widget_factory/ /browser:addform Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: security frustrations
Florent Guillaume wrote: Does it work to just set __parent__ to the container? Or does the zopesecuritypolicy require more accurate context? Yes, the unset location is the problem, why the local security cannot be looked up. Martijn Faassen wrote: Benji York wrote: Martijn Faassen wrote: * after object creation but before the object is added, various things are done to the object. * authorization error: user cannot access various attributes. If these things are done by subscribers, would using trusted subscribers help? I guess it could; I've used a trusted adapter in a few places to get around security concerns. However, not everything is done by subscribers. I have a little workflow system that in some cases can create new versions of objects, for instance. My frustration is more that one has to do *something* special than that there aren't any solutions. Knowing to use trusted subscribers and having to design ones application around them would be another thing one would need to know to 'please' the security system. I know of course that security is hard, so maybe there's no way than to just bite the bullet... A year ago we wrote a little initializer framework (svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/initializer) that offers a possible *general* way to initialize components. A inializer subscribers is hooked in using the ObjectAddedEvent. At that time the component is already located within its parent and all intialisation actions can be performed (including utility registration etc.): Summary (svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/initializer/README.txt) - Offers class- or adapter-based inialisation ( - ClassInializer, - FeatureInializer) - Takes inheritence during initialisation (reversed rmo) of classes and adapters into account - Offers initalisation data handling using keyword arguments and a signature specifying those arugments - Supports the form framework (- add form, add wizard) General Subscriber Hook-Problem: - Those subscribers are not ordered. So I can imagine a scenario that other subscribers like to 'use' the object before it is initialized correctly (- For example catalog indexes and unpolished object). So far we had no concerns with that fact. (Addform example: Its only a conceptual exampe for the tiks.typing resp. tiks.system framework that is basing on generic implementation that gets typed/classified only by a marker interface. But there you will see how you can handle the inialisation including addforms and addwizards: (svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/demo/typing).) If you (or anybody else) are interessest to use or to extend the framework, we could move the package to the zope repos too. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] PAU trouble
Velko Ivanov wrote: Dominik Huber wrote: Provide ILocation by those adapters, use the 'locatalbe' attribute of the adapter directive (- location proxied) or set the permission explicitly to zope.Public. Thanks for the reply PsycopgAdapter inherits ZopeDatabaseAdapter, which provides ILocation via IContained. No adapter directives are used in the configuration file, zope.Public is the least acceptable workaround. There is a confusion between zope adapter and database adapter. Database adapters are regularly implemented as local utility (DA utility). Therefore a database adapter does provide IContained. The DA utitlity has to be invoked in your application somehow and that invocation *might* be happen with a zope adapter. If such an potential zope adapter does not provide Location (or locatable=True within its adapter directive) the local authentication cannot be invoked because its context cannot be evaluated (None locations are global). Whitout knowing further details about DA's, SessionCredentialsPlugin, etc your problem smells like a global/local-muddle. Maybe you could use the 'ZopeBasicRealm' and the 'No Challange if Authenticated' credential plugin to narrow the bug source. I use this configuration with different authenticator plugins and local/global principals. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] #316 : Looking for windows users
Julien Anguenot wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Could someone try to launch the tests with a Zope3 checkout under Windows this way ? : $ python bin/test -vpu --dir src\\zope\\ E:\dev\zope3_trunkpython test -vpu --dir src\\zope\\ Configuration file found. Running UNIT tests at level 1 Running UNIT tests from E:\dev\zope3_trunk Traceback (most recent call last): File test.py, line 27, in ? zope.app.testing.test.process_args() File E:\dev\zope3_trunk\src\zope\app\testing\test.py, line 1170, in process args bad = main(MODULE_FILTERS, TEST_FILTERS, LIBDIR) File E:\dev\zope3_trunk\src\zope\app\testing\test.py, line 799, in main files = find_tests(module_filter) File E:\dev\zope3_trunk\src\zope\app\testing\test.py, line 584, in find_tes s d = find_test_dir(d) File E:\dev\zope3_trunk\src\zope\app\testing\test.py, line 576, in find_tes _dir raise ValueError(%s does not exist! % dir) ValueError: src\\zope\\ does not exist! but... E:\dev\zope3_trunkpython test -vpu --dir src\zope\ Configuration file found. Running UNIT tests at level 1 Running UNIT tests from E:\dev\zope3_trunk 3904/5574 ( 70.0%): test_merge_conflict (...c.tests.test_fsmerger.TestFSMerger) diff3 doesn't work, diff3 tests disabled 5572/5574 (100.0%): toxml (zope.xmlpickle.xmlpickle) - - Ran 5574 tests in 106.754s OK Just to check if this bug still exists with the trunk or not. 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 iD8DBQFC5MFTGhoG8MxZ/pIRAvB5AJ9u0S1aOfPOlV0lXarASLLq4yKAZQCfVI4v ZVkmoi258tjqHN7wKtlFJv0= =n4yT -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dominik.huber%40perse.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] #316 : Looking for windows users
Julien Anguenot wrote:
Is it supposed to work with the double \ ('\\') on windows ?
The error reported was different on this issue but seems to be related
though.
I don't know. I never used it with double '\' before.
Dominik
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] local-utility location and registration
Garanin Michael wrote: Ok, but my setup code very like your code with little difference: - your code: default[folder_name] = utility - my code: site[folder_name] = utility (my question: is it legal?) As result i have url MySite/PAU/USERS instead MySite/++etc++site/default/PAU/USERS. And it is works. Ok, finally I got it :) You try to register a 'content' component within the utility registry. Certainly the registered component does not have to live directly inside site folder in order to get invoked by the utility mechanism (compare global registrations), but it was a design goal of zope 3 to divide content- and software space (- convention). In that respect it would a more adequate solution putting your pau regularly into the site manager and adding an additional content component or view that allows to manage the pau-utility within the content space. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Make widget / subdirective support sequence/items widgets
Philipp von Weitershausen wrote: Actually, I'm not entirely satisfied with the implementation yet. It still doesn't work sufficiently with subwidgets of sequence widgets. I'm not sure if I use the sequence widgets correctly. Two days ago I used the sequence widget the second time (The first time I used them within X3.0. Everything seems to be equal except that the CustomWidgetFactory cannot used for custom sequence widgets anymore (-CustomSequenceWidgetFactory)). Are there other ways sequence widgets should be used? interfaces.py: - class IFoo(Interface: attribute1 = TextLine() attribute2 = TextLine() attribute3 = TextLine() class IFoos(Interface): foos = Tuple(title=_( default=(), value_type=Object(schema=IFoo)) edit.py: --- from zope.app.form import CustomWidgetFactory, CustomSequenceWidgetFactory from zope.app.form.browser import ObjectWidget, SequenceWidget from app import Foo foo_widget = CustomWidgetFactory(ObjectWidget, Foo) foos_widget = CustomSequenceWidgetFactory(SequenceWidget, foo_widget) browser.zcml: -- browser:editform for=.interfaces.IFoos schema=.interfaces.IFoos label=Edit Foos name=edit.html menu=zmi_views title=Edit Manager permission=zope.ManageContent widget field=foos class=.edit.foos_widget / /browser:editform What exactly doesn't work sufficiently with subwidgets in your opinion? IMO, it woud be cool if there is a way to hide and order the fields of the subwidgets. So, I will likely merge after 3.1, but possibly on both 3.1 branch and the trunk. I consider this a bugfix. This example pattern does not work anymore with the current trunk, but with your branch. It would be better if you could merge before 3.1, because IMO this seems to be a bug too. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 and LocalFS functionality
H Jansen wrote: Thanks so much to point me to the serverasset package. However, after installing the serverasset package and (re)starting Zope, I cannot access de server through the browser anymore (something goes wrong apparently in the startup...). As with the zwiki package (which works fine) I've installed (an exact copy: cp -a serverasset) the serveraccess directory as install-dir/X3-3.0.0/lib/python/serverasset directory. Like zwiki, I've also added a serverasset-configure.zcml file that reads include package=serverasset / in the install-dir/X3-3.0.0/instance/etc/package-includes directory. It does not work for me... Am I still doing something wrong? --Henk tiks is the base package. so you should try: install-dir/X3-3.0.0/lib/python/tiks/serverasset (don't forget the __init__.py within tiks) include package=tiks.serverasset / but there might be dependencies to other tiks packages (at least to .i18n, .testing). IMO the best (easiest) way for a first impression would be copying the whole tiks package to install-dir/X3-3.0.0/lib/python/tiks and all its package includes (svn://svn.tiks.org/repos/Tiks/trunk/package-includes-tiks) to install-dir/X3-3.0.0/instance/etc/package-includes regards, Dominik Huber (p.s. attention their is a bug using the fs directory manager in combination with the intid utility.) On Mon, 2005-06-06 at 10:49, Dominik Huber wrote: H Jansen wrote: I have build a very useful website in Zope2 in which I used the LocalFS product for web access to my local file system. New to Zope3 I'm looking for similar functionality. I'd like to hear if anyone has dealt with this issue before in Zope3? How should I go about it, will I have to go deep and start writing the thing from scratch ... :sad: Thanks. Within the tiks svn-repository we have such a local file system implementation: svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/serverasset usage: - add local directory utility (Local Directory Utility) to a site with the name 'xy' - switch to the content area - add file system directory manager (FS Directory Manager) select directory 'xy' - you can add and remove new files and directories regards, Dominik Huber ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] site.zcml (ftesting.zcml) extension
We should have an application/framework-level hook within the site.zcml that is processed before *-configure.zcml are invoked. Problem: A framework package 'b.x' registers a dedicated menu 'b_views'. A package 'a.x' using 'b.x' should be able to register menu items refering 'b_views'. The initialisation will fail because 'a.x' is loaded before 'b.x' and therefore 'a.x' cant register any view to 'b_views' because the menu does not exists yet. Proposed solution: package includes named *-app.zcml will be invoked before the regular *-configure.zcml package includes (Compare example site.zcml below) Any objections? Regards, Dominik example site.zcml: configure xmlns=http://namespaces.zope.org/zope; include files=package-includes/*-meta.zcml / include package=zope.app / !-- Provide application or framework specific configurations-- include files=package-includes/*-app.zcml / !-- Provide package specific configurations-- include files=package-includes/*-configure.zcml / !-- Provide local overrides of standard configurations-- includeOverrides file=overrides.zcml / include file=securitypolicy.zcml / include file=principals.zcml / /configure ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Multi Interface Types Registration
Stephan Richter wrote: IMO multi-typed interfaces would make sense. Would you have any objections if I change the code the following way: module: zope.app.component.interface.py, line 78 75if iface_type is not None: 76if not iface_type.extends(IInterface): 77raise TypeError(iface_type, is not an interface type) 78directlyProvides(interface, iface_type, directlyProvidedBy(interface)) I would like to see a use case first. Once we can agree that the use case is really necessary, this change will be fine. It's not just a matter of use case, it's also a matter of potentially unintended misconfiguration and side effects: The directly-provide-implementation decision allows multi-typed interfaces on python level. As soon the interface directive is invoked manipulation on python level will be 'removed' by a single type information. Such behavior complicates the live of developer knowing the interface package only. Use case: Typing interfaces within orthogonal application domains: - CMS-Domain - IContentType, IEventType, ... - Business-Domain - IAnyBusinessDomainType Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] site.zcml (ftesting.zcml) extension
Stephan Richter wrote: On Monday 25 April 2005 09:03, Dominik Huber wrote: Problem: A framework package 'b.x' registers a dedicated menu 'b_views'. A package 'a.x' using 'b.x' should be able to register menu items refering 'b_views'. The initialisation will fail because 'a.x' is loaded before 'b.x' and therefore 'a.x' cant register any view to 'b_views' because the menu does not exists yet. I am pretty sure we had a solution for this problem already. I think you simply do: include file=a-configure.zcml inside b-configure.zcml in package-includes. 'a' does not know 'b', but 'b' depends on 'a'. The menu 'b_view' is in that respect something like a meta-information on the application/framework level. Within Zope this application-level-part is handle by the direct iclude 'include package=zope.app /' which is proceeded before all *-configure.zcml's. Other application/framework may need similar kind of configurations for establishing theirs meta-application-level. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] site.zcml (ftesting.zcml) extension
Shane Hathaway wrote: Dominik Huber wrote: We should have an application/framework-level hook within the site.zcml that is processed before *-configure.zcml are invoked. Problem: A framework package 'b.x' registers a dedicated menu 'b_views'. A package 'a.x' using 'b.x' should be able to register menu items refering 'b_views'. The initialisation will fail because 'a.x' is loaded before 'b.x' and therefore 'a.x' cant register any view to 'b_views' because the menu does not exists yet. Proposed solution: package includes named *-app.zcml will be invoked before the regular *-configure.zcml package includes (Compare example site.zcml below) Any objections? That might be a reasonable band-aid. However, directives ought to have no load-time dependencies on other directives. The configuration directives should defer any interconnections and registration until the whole configuration is loaded. In principle +1, but their are still cases where that idealism will break. Zope solves that problem using the direct include include package=zope.app / that is processed before the others *-configure.zcml. It's the old dispute between holism and reductionism. In the modern system theory it is the differentiation between heap and system. In that respect we need a way to register *parallel* systems (applications or frameworks) including zope.app. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: So at the moment I do not see any another possibility to set those permissions than using an additional class.. directive. All 'bugs' related to this issue (that I'm aware of) including the zwiki-bug that was reported uses the above pattern and breaks. The reason for my branch was to solve this kind problem :) But your original fix caused other problems. Only if somebody is memorizing (and pickle) adapters. Please be honest, that's not the most ordinary application. (at least there were definitely more application using the above pattern. ;) This isn't about the the specific pickling problem. It's about the unexpected problems from implicitly proxying something. Proxies are a technology that should be used only when necessary. This whole discussion is about providing the convenience of not having to subclass Location in an adapter class when an adapter is going to be security proxied. While I think this convenience has value, the value does not justify always adding the location proxy. Yes and No. It's convience, but it's also fact that security lookups do need a location (unless zope.Public) to invoke local security settings correctly. So, we have two cases: 1. the developer is *fully aware* of the security and adapter machinery. 2. the developer is *not aware* of the security and adapter machinery. Today dev 2 is going to struggle and he will have a hard time to find the bug. The current branch prevents that dev 2 struggles. Dev 1 might be disturbed by an implicit location proxy, but he is able to handle the problem deriving his adapter class from ILocation. ... 2. the resulting adapter requires the permission defined by class.. adapter factory=.wikipage.MailSubscriptions provides=.interfaces.IMailSubscriptions for=.interfaces.IWiki *permission=any.Permission* trusted=true / class class=.wikipage.MailSubscriptions require permission=zwiki.EditWikiPage attributes=getSubscriptions / require permission=zwiki.EditWikiPage attributes=addSubscriptions removeSubscriptions / /class IMO case 2. happens (experimental verification only, I do not understand all magics within _protectedFactory). The status-quo is pretty implicit too. I looking forward to explain such stuff to newbies ;) In this case, the designer needs to do one of: - Make their adapter class a location - Factor their adapter into separate adapters that each do one thing and need a single permission. I just thought of another alternative in the case of single adapters. The adapter directive lets you name multiple factories in the factory attribute. You could list the location proxy constructor as a factory in the ZCML: adapter ... factory=.MyOriginalFactory zope.app.location.LocationProxy Here, we are *explicitly* saying that we want to combine an aplication factory with a location proxy. This works for the example above. Yup. -1 That's might be *to much explicitness* for dev 1 and complecates the adapter directive too. We missed us. Question: What should the precedence be if I use the sample zwiki registration (modified example above)? At the moment (trunk) the permission attribute of the adapter... is ignored and the permission-set of the class... is invoked (experimental verification only). I couldn't tell you what the precedence should be because I didn't anticipate that someone would do both. Here's what I want: The adapter directive grows a new feature. If the adapter directive has a permission directive with a permission other than zope.Public and the adapter adapts one or more objects, then we provide a factory that: - Adds a location proxy if it doesn't provide ILocation, and - Sets the __parent__ if the existing value is not None Dis you implement this? I tried to implement your solution [Revision 30053], but then I noticed the following problems: 1. no permission (None) and zope.Public within a trusted adapter registration provokes different behavior (example below KeyReferenceToPersistent) OK, sounds like a bug. 2. the zwiki bug and my related implementations bugs still exists, because regularly folks that registering trusted adapters using adapter... and class...do not set any permission within adapter.., but only within class (That kind of permission declaration causes the invocation of the regular-trusted-adapter-factory.) Therefore I reverted 'your' solution back to the first implementation [Revision 30059, 30060]. That's not acceptable I assumed that it will be less evil to do without two different trusted adapters factories (regular (zope.Public and None) and the locating one (other permission)). + we can fix the zwiki bug and related implementations bugs easily + we can omit the unclear permission-precedence if the adapter... class... pattern is used for trusted adapters o the untrusted adapters with no location get only location-proxied if
Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: Dominik Huber wrote: Jim Fulton wrote: ... Here are 2 other alternatives to consider: 1. Add a locate option to the adapter directive, which defaults to false. If true (locate=1), then a location proxy is always added to the adapter. Yup. -1 That's might be *to much explicitness* for dev I really don't think so. 1 and complecates the adapter directive too. Actually, I think it simplifies it a little. It separates trusted-ness from location-ness. 2. Option 1 but default to true if a non-public permission is specified. These alternatives are explicit and hande the case where permissions are declared in a separate directive. In both sugestions the problem is not solved, that the public permission declaration within the adapter directive cannot be adapted to all trusted adapters, because the 'valid' security-declartations might be registered within an addional class... I think you are mistaken. If you declare permissions in a class directive, you'd use a locate attribute in the adapter directive, as in: adapter factory=.myFactory trusted=1 locate=1 / class class=.myFactory require permission=X interface=IX / ... /class In this case you'd get the location even though the adapter directive doesn't specify a permission. Ok, I'm mistaken. That would be also fine with me. The only thing we have to do additionaly is to look for potential bugs like the zwiki example. Which alternativ do you prefer? I have time on wednesday to implement your selection within the branch. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: Dominik Huber wrote: Excuse me late response I was busy that weekend... Jim Fulton wrote: I fixed that issue within the branch 'Zope3/branches/dominik-locatableadapters' Jim, could you take a look at that please. Thank you very much in advance! [...] We should *only* add the location if the adapter requires a permission other than zope public. Key rereferences don't require a permission and should not be location proxied. Doing so makes them unpicklable. We're going to need to fix the trusted adapter factory to do this correctly. I suggest we create a new kind of trusted adapter factory, perhaps LocatingTrustedAdapter factory that adds the location. This should only be used when the adapter directive specified a permission other than zope.Public. Otherwise, the original trusted adapter factory should be used. May be I do not understand the problem correctly: IMO the permission declaration within the adapter directive has nothing to do with the permission declaration wihtin the class directive that mus be used if trusted adapters are invoked. Example KeyReference Adapter: adapter for=persistent.interfaces.IPersistent provides=.interfaces.IKeyReference factory=.persistent.KeyReferenceToPersistent trusted=y / class class=.persistent.KeyReferenceToPersistent require permission=zope.Public interface=.interfaces.IKeyReference / /class That's odd. I didn't notice the class directive. I don't know why the class directive is being used here. This is one of those rare cases where we have to make the security declaration on the adapter class. (In this case, it's because the adapters are pickled, which is also unusual.) It is not generally the case that you need to use separate security declarations with trusted adapters. I declare those additional class directive all the time if I'm using trusted adapters. IMO this kind of registration is the common pattern For example stephan richter uses this pattern within the wiki: adapter factory=.wikipage.WikiPageHierarchyAdapter provides=.interfaces.IWikiPageHierarchy for=.interfaces.IWikiPage trusted=true / class class=.wikipage.WikiPageHierarchyAdapter require permission=zwiki.ViewWikiPage attributes=parents path findChildren / require permission=zwiki.ReparentWikiPage attributes=reparent set_attributes=parents / /class permission declaration of the possible adapter instances (class ...). Therefore we can't switch the adapter factories within the adapter directive processing.. So, during the registration of an trusted adapter factory (adapter...) I can't do any prediction about the No, you can't do so implicitly. You can know about the permission used if a non-public permission was supplied. If a non-public permission is supplied, then it is reasonable to add the location. Otherwise, you should not try to guess. But the permission declaration within the adapter directive defines the permission that is nessecary to invoke the adapter factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. - How should we handle NullAdapters correctly? All the same I implemented your sugestion. The following question appears: What do you mean by NullAdapters? Are you talking about factories that return None? Id so, then, obviously, you should not proxy None. No, 'NullAdapter' are parameterless factories, for example x = IX() IMO this solution is pretty implicit and I do not like it at all. What solution? If you are talking about my suggestion to add a location to any adapter for whoch a non-public permission is specified, then I consider this far less impleicit than what you had before. It doesn't guess. If it knows a permission is required, it adds a location. Yes, the current solution in the branch. We should find a way to check the permission of the adapter instances inside a single trusted adapter factory: class IntelligentTrustedAdapterFactory(TrustedAdapterFactoryMixin): def _customize(self, adapter, context): p = ProxyFactory(adapter) checker = getChecker(p) if checker is CheckerPublic: return adapter else: return assertLocation(adapter, context) Questions: - performance - in the key refernce example it would be an dedicated checker. how could I guess if such an checker is Public? This is just too much magic. It has too many rules and is too slow. BTW, we are not just taking about trusted adapters. We are talking about *any* adapter for which a non-public permission is required. Yes, thats clear. We have two cases: 1. untrusted 2. trusted 1. if we register an untrusted adapter using the adapter directive we can make an correlation between adapter factory permission and adapter instance: if I have no permission to invoke the factory, I should not be able to use its instances. 2. if we
Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: It is not generally the case that you need to use separate security declarations with trusted adapters. I declare those additional class directive all the time if I'm using trusted adapters. IMO this kind of registration is the common pattern For example stephan richter uses this pattern within the wiki: adapter factory=.wikipage.WikiPageHierarchyAdapter provides=.interfaces.IWikiPageHierarchy for=.interfaces.IWikiPage trusted=true / class class=.wikipage.WikiPageHierarchyAdapter require permission=zwiki.ViewWikiPage attributes=parents path findChildren / require permission=zwiki.ReparentWikiPage attributes=reparent set_attributes=parents / /class This isn't a pattern I've used. I think that there are lots of other, and perhaps better ways to do things. We have the use case that we adapt a lot of additional functionalities to a pretty stupid content. Each additional functionality has differentiated permission-sets comparable to regular content objects. For example different permissions for reading and setting attributes of the provided interface. So at the moment I do not see any another possibility to set those permissions than using an additional class.. directive. All 'bugs' related to this issue (that I'm aware of) including the zwiki-bug that was reported uses the above pattern and breaks. The reason for my branch was to solve this kind problem :) But the permission declaration within the adapter directive defines the permission that is nessecary to invoke the adapter factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. Ah. You missunderstand. The permission is not the permission to to create the adapter. It's the permission necessary to use the provided interface on the adapter. Ok, missleading naming _protectedFactory within the adapter handler ;) But what happens in the following case? 1. the resulting adapter requires any.Permission 2. the resulting adapter requires the permission defined by class.. adapter factory=.wikipage.MailSubscriptions provides=.interfaces.IMailSubscriptions for=.interfaces.IWiki *permission=any.Permission* trusted=true / class class=.wikipage.MailSubscriptions require permission=zwiki.EditWikiPage attributes=getSubscriptions / require permission=zwiki.EditWikiPage attributes=addSubscriptions removeSubscriptions / /class IMO case 2. happens (experimental verification only, I do not understand all magics within _protectedFactory). The status-quo is pretty implicit too. I looking forward to explain such stuff to newbies ;) - How should we handle NullAdapters correctly? All the same I implemented your sugestion. The following question appears: What do you mean by NullAdapters? Are you talking about factories that return None? Id so, then, obviously, you should not proxy None. No, 'NullAdapter' are parameterless factories, for example x = IX() OK, so these cannot be locations. Yup, that my interpretation too. So those null adapters are global object with or without dedicated permission that can't be invoke by any local principal. What's the use cases for such object? IMO this solution is pretty implicit and I do not like it at all. What solution? If you are talking about my suggestion to add a location to any adapter for whoch a non-public permission is specified, then I consider this far less impleicit than what you had before. It doesn't guess. If it knows a permission is required, it adds a location. Yes, the current solution in the branch. OK, I'll take a look at that. Excuse me, but under those circumstances I have to retract my solution. IMO it will be not that what you are looking for... :( 2. if we register a trusted adapter this correlation breaks because the adapter instance itself might have highly differented security-permission (compare class...) In a complex situation like this, I suggest it's better to have people make their adapters locations in Python. It might more complex than a single permission, but its every day life. I only try to simplify independently if its complex or not :) So 1 is easy to handle in the adapter directive, but 2 not. The suggestion above tries to respect your requirments, but also allow to use. the registration pattern adapter... and class.. which is failry common and explicit. The current solution in the branch is not able to handle 2. correctly. Stephan's zwiki example: - The adapter directive has no permission (which is ok, because he doesn't need to protect the invocation of the adapter factory itself). - In that case the locating trusted adapter factory is not invoked within the registration. -
Re: [Zope3-dev] Form framework, adapters and pau
addendum... I tried to implement your solution [Revision 30053], but then I noticed the following problems: 1. no permission (None) and zope.Public within a trusted adapter registration provokes different behavior (example below KeyReferenceToPersistent) 2. the zwiki bug and my related implementations bugs still exists, because regularly folks that registering trusted adapters using adapter... and class...do not set any permission within adapter.., but only within class (That kind of permission declaration causes the invocation of the regular-trusted-adapter-factory.) Therefore I reverted 'your' solution back to the first implementation [Revision 30059, 30060]. I assumed that it will be less evil to do without two different trusted adapters factories (regular (zope.Public and None) and the locating one (other permission)). + we can fix the zwiki bug and related implementations bugs easily + we can omit the unclear permission-precedence if the adapter... class... pattern is used for trusted adapters o the untrusted adapters with no location get only location-proxied if permission is not None or zope.Public - we have to derive the KeyReferenceToPersistent adapter from Location to omit the pickle error Just now I added some optimization [30067]: Trusted adapters get regularly only protected if the adapted object is protected. Therefore we can omit the location proxy in cases where the trusted adapters get not protected. I wrote an other adapter factory (PartiallyLocatingTrustedAdapterFactory) which is only using location proxies if the adapter is protected and does not provide ILocation. If ILocation is provided the parent is still set if None. And this that solves the KeyRefernceToPersistent problem too. [revison 30068] Within the current branch there are the three adapter factories: - PartiallyLocatingTrustedAdapterFactory - LocatingTrustedAdapterFactory - TrustedAdapterFactory You can easily switch them within adapter() directive handler and look for the optimum. After all I would prefer the current solution. But I know the decision is up to you. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Wiki permissions and PAU [Zope3-dev] Form framework, adapters and pau
Paolo Invernizzi wrote: I've a problem with the wiki that I can't resolve... Zope3 trunk current. I've added a PAU to http://eye:8080/++etc++site/default/@@contents.html with a PrincipalFolder and some principals. I've activated the No Challenge if Authenticated and the Zope Realm Basic-Auth I've also granted some principals in http://eye:8080/@@grant.html some principal of the folder with the Site Manager role. While everything is working pretty well, the principal can login, administer the site etc,etc I've a problem... I added a Wiki. While the principal can access single pages, the search in http://eye:8080/the_wiki/@@search.html, see the contents in http://eye:8080/the_wiki/@@contents.html, if cannot access the Table of contents http://eye:8080/the_wiki/@@toc.html (You are not authorized). That's an artefact of the problem we dicussed currently in [Zope3-dev] Form framework, adapters and pau thread. Only the global authentication is invoked, because the trusted WikiPageHierarchyAdapter does not implement ILocation. Therefore your user does not 'exists' during the authentication and that is leading to this failure. Temporary workaround: zwiki\wikipage.py line 73, derive WikiPageHierarchyAdapter from Location from zope.app.location import Location class WikiPageHierarchyAdapter(Location): ... We' ve planed to fix that problem correctly: http://mail.zope.org/pipermail/zope3-dev/2005-April/014140.html Regards, Dominik Huber ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Form framework, adapters and pau
A few months ago the following code block was removed in editview.py, editwizard.py and schemadisplay.py (revision 29418): def _setUpWidgets(self): adapted = self.schema(self.context) if adapted is not self.context: if not ILocation.providedBy(adapted): adapted = LocationProxy(adapted) adapted.__parent__ = self.context self.adapted = adapted setUpEditWidgets(self, self.schema, source=self.adapted, names=self.fieldNames) As a consequence each trusted adapter class should now implement ILocation that the TrustedAdapterFactory can set the location of adapter instances correctly. Otherwise, only the global authentication is involved and the edit view fails if any local principal tries to edit a certain field (security.canWrite(source, name) in zope.app.form.utility line 207). I would like to revert those changes. IMO a framework like the form framework knows the context (location) and adapts that context to a certain schema. If the following procedures depends on location information, the framework itself should pass such informations in a smart way. It's an unnecessary se?lp=endep=/Mn4k.search=unnecessary expense se?lp=endep=/Mn4k.search=expense to force all schema adapters to implement ILocation: - The solution using the location proxy seems fairly famillar compared with the container framework and containment that does not provide ILocation. - An adapter that implements more than one interface cannot be registered with the implicit adapts and implements informations. - A regular schema does not extend ILocation therefore it is not obvious to write an adapter implementing ILocation. Any objections? Regards, Dominik Huber ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: Dominik Huber wrote: A few months ago the following code block was removed in editview.py, editwizard.py and schemadisplay.py (revision 29418): def _setUpWidgets(self): adapted = self.schema(self.context) if adapted is not self.context: if not ILocation.providedBy(adapted): adapted = LocationProxy(adapted) adapted.__parent__ = self.context self.adapted = adapted setUpEditWidgets(self, self.schema, source=self.adapted, names=self.fieldNames) As a consequence each trusted adapter class should now implement ILocation One could, as an alternative, use an non-trusted adapter that is public and rely on the underlying object protection. We can only use trusted adapters for our use case. that the TrustedAdapterFactory can set the location of adapter instances correctly. Otherwise, only the global authentication is involved and the edit view fails if any local principal tries to edit a certain field (security.canWrite(source, name) in zope.app.form.utility line 207). I would like to revert those changes. IMO a framework like the form framework knows the context (location) and adapts that context to a certain schema. If the following procedures depends on location information, the framework itself should pass such informations in a smart way. It's an unnecessary se?lp=endep=/Mn4k.search=unnecessary expense se?lp=endep=/Mn4k.search=expense to force all schema adapters to implement ILocation: - The solution using the location proxy seems fairly famillar compared with the container framework and containment that does not provide ILocation. Except that the object being location proxied is already security proxied. Location proxies were not designed to proxy security-proxied objects. Theory: I cannot assess this location-proxied securtiy proxy issue. Therefor I have a question about the order of containment proxies: 1. contained proxy security proxy component 2. security proxy contained proxy component So far I thought a component is created and proxied by their factory, afterwards it is contained proxied by the container if it does not provide ILocation. Therefor my statemets bases of 1. So for me it is not very obvious what the difference should be between location proxied containement and location proxied trusted adapters: location proxy security proxy trusted adapter Practise: The form framework does not work using trusted adapters which do not provide ILocation in combination with the local authentication information. This raises an Unauthorized exception if a local principal with enough privileges tries to access the edit view. (Reason: Because the unlocatable adapter invoke the global authentication only). We have three oportunities: a) status quo b) location proxy or simalar derivates c) extend security.canWrite(obj, name, context=None) d) ... History: Roger removed the location proxy code because at that time the security information get lost using location proxies (Reason multiple security proxies: security proxy location proxy security proxy trusted adapter). Afterward Garret fixed the proxy method of the Checker class. Since that time proxied object will be only proxied if their were not already proxied before (location proxy security proxy trusted adapter) - An adapter that implements more than one interface cannot be registered with the implicit adapts and implements informations. True. - A regular schema does not extend ILocation therefore it is not obvious to write an adapter implementing ILocation. True. If you answers the last two reasons with True then follows IMO a) is a bug. So we have to choose an other implementation alternative b), c) or d) would be ok for me. Any objections? Yes. :) Why not simply use an untrusted public adapter? Use case: We have within the site 's' an extendable containerish component 'f' (Class Fasade) that should fasade its containment . Inside 'f' we can put any component for example component 'any' (Class Any) providing 'IAny'.The IWriteContainer declaration of 's' requires the permission 'zope.ManageContent'. The IWriteContainer declaration of 'any' requires a dedicated permission for example 'zope.ManageInside'. Now we should provide an edit-view for 'f' that invokes the contained component 'any'. The edit-view should be accessable for local principal of s which have the 'zope.ManageContent' permission. Our design goal tries to satify the following two targets: - demeter's law (No direct access to 'any'). - different permission between inside and outside 'f' So we decided to access 'any' on the location of 'f' using an AnyForFasade adapter. IMO this adapter must be trusted to hide inside permission of 'any'. Regards, Dominik Huber ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail
