Re: [Zope3-Users] [Zope-dev] Problems with schema Date field - year is truncated
Hi Hermann, The z3c.form.converter.CalendarDataConverter, on which the DateDataConverter is based, explicitely sets the date format to 'short'. Overriding the latter with a 'length' attribute set to 'medium' will handle german dates as dd.MM.. Regards, Markus Kemmerling Am 27.08.2008 um 17:52 schrieb Hermann Himmelbauer: Hi, I'm somehow stuck on the following problem: I defined a Date() schema field in one of my interfaces. I currently have a de-AT locale, so I'd like to enter the value of my date as e.g. dd.MM., e.g. 01.02.1980 in my z3c.form based form. What happens is, that the locale silently assumes a format of dd.MM.yy, which means, that the YY / 80 is truncated and 01.02.19 is stored in my database, when updating. So, I'd like to know if: - It is possible to change the format to dd.MM., which is a lot more appropriate for my application (a birth date) - Make the application more strict, meaning that no data is truncated in any case. I tried to stick my nose into i18n.locales but was somehow overwhelmed by what I found. However, the following somehow seems to explain it: /dateFormatLength dateFormatLength type=medium dateFormat patterndd.MM./pattern /dateFormat /dateFormatLength dateFormatLength type=short dateFormat patterndd.MM.yy/pattern /dateFormat /dateFormatLength Nevertheless I don't know if there's a way to select a specific dateFormat, e.g. medium in my case. Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] z3c.form: hidden select widget id attribute
Hi,
there is a small issue with the template for a hidden select field
widget, select_hidden.pt, in z3c.form. It renders an input tag with
the same id as the *option* tag with the selected value in input mode
instead of the id of the *select* tag in input mode. I consider this
a mistake, since it makes the id depend on the selected value. The
hidden input tags represents the select field itself, not one of it's
items.
This probably sounds complicated, but is easy to see by closely
looking at the relevant parts in select.txt:
Input mode (id=widget-id):
print widget.render()
select id=widget-id name=widget.name:list
class=select-widget size=1
option id=widget-id-novalue value=--NOVALUE--
selected=selectedselect a value .../option
option id=widget-id-0 value=aa/option
option id=widget-id-1 value=bb/option
option id=widget-id-2 value=cc/option
/select
input name=widget.name-empty-marker type=hidden
value=1 /
Hidden mode (id=widget-id-1):
print widget.render()
input type=hidden name=widget.name:list
class=hidden-widget value=b id=widget-id-1 /
input name=widget.name-empty-marker type=hidden
value=1 /
The fix is so trivial that I almost hesitate to state it:
--- /Users/markus/eggs/z3c.form-1.8.2-py2.4.egg/z3c/form/browser/
select_hidden.pt 2008-08-19 20:33:32.0 +0200
+++ select_hidden.pt2008-08-20 09:19:24.0 +0200
@@ -3,7 +3,7 @@
repeat=item view/items
input type=hidden name= class=hidden-widget
tal:condition=item/selected
- tal:attributes=name name; value item/value; id item/id /
+ tal:attributes=name name; value item/value; id id /
/tal:block
input name=field-empty-marker type=hidden value=1
tal:attributes=name string:${view/name}-empty-marker /
Regards,
Markus Kemmerling
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Multi-level object structure
Am 08.08.2008 um 17:24 schrieb Jeronimo Jacobo:
Hi
I am new in Zope 3 world, i have read the book Web Component
Development with Zope 3 and I am designing a Zope application
which involves a multiple-level object structure in which the
father class has multiple instances of son class and the son class
has multiple objects of the grandson class.
Up to now i have managed to construct something like this:
class IGrandson(Interface):
age=Int(
title=_(u'Age'),
description=_(u'The age of the Grandson'),
required=True
)
name=TextLine(
title=_(u'Name'),
description=_(uThe name of the Grandson),
required=True
)
class ISon(Interface):
name=TextLine(
title=_(u'Name'),
description=_(u'Name of the Son'),
required=True,
)
grandsons=List(
title=_('Grandsons'),
description=_(A list of Grandsons),
required=False,
value_type=Object(
title=_('Grandson'),
schema=IGrandson
)
)
However, in this way i can only create Sons. Grandsons will be
added as an element of the Son''s grandsons list. If I want to
create a Grandson without father, how can I add it later to the
Son''s list?
Is the List the most effective way to store objects? I have tried
with BTrees, but then i have problems to construct the widgets and
views to add elements to the BTree and i think BTrees is not an
interfaces so I cannot do something like:
grandsons=OOBTree(
title=_('Grandsons'),
description=_(A list of Grandsons),
required=False,
value_type=Object(
title=_('Grandson'),
schema=IGrandson
)
)
nor
grandsons=Object(
title=_('Grandson'),
schema=OOBTree
)
Also, considering that the structure can grow up to four
generations (granpa, father, son, grandson), what will be the best
approach to achieve this mult-level structure?
My initial idea was to present in the first view the Granpas. When
selecting one of them, its attributes will be shown, among them its
sons (the Fathers). Then when selecting one of them, the process
will repeat until the grandson.
I appretiate much your help and ideas. Thanks in advance.
Jeronimo
You could implement everybody as a container for objects of the same
type as the container itself, something like this:
IGenealogy(IContainer):
...
IPerson(IContained, IContainer):
contains('. IPerson')
containers('. IPerson', IGenealogy)
age=Int(
title=_(u'Age'),
description=_(u'The age of the Person'),
required=True
)
name=TextLine(
title=_(u'Name'),
description=_(uThe name of the Person),
required=True
)
This way the father-son relation will only be a matter of the parent-
child relation and not a feature of the defining interface itself
(some day every son may become a father himself ;-).
Regards,
Markus Kemmerling
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Interface confusion (still)
Am 15.07.2008 um 20:53 schrieb Tim Cook: If interface B inherits from interface A and class B implements interface B; do I need to explicitly state that class B provides interface A? An instance of a class provides not only the interface the class declares to implement, but also all base interfaces of this interface. In particular an instance that povides any interface, will always provide 'Interface'. Concrete example: class IElement(Interface): value = Object( schema=IDataValue, title=_(uvalue), description=_(uData value of this leaf.), required=False ) class IDvText(IDataValue): ... class DvText(DataValue): implements(IDvText) classProvides(IDvText) The last line doesn't make any sense here. As I tried to explain before, if a class declares to 'implement' an interface, all of it's instances will provide it, whereby 'classProvides' declares the *class itself* to directly provide the interface. Note: classes *implement* interfaces, their instances *provide* them. Will Element.value allow instances of DvText or do I need to change the DvText classProvides call to: classProvides(IDataValue,IDvText) You probably don't want to use 'classProvides' at all. The 'implements(IDvText)' statement is enough for all instances of 'DvText' to provide 'IDataValue'. Regards, Markus Kemmerling ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Set List constraints
Am 10.07.2008 um 16:44 schrieb Tim Cook: When constraining the membership of zope.schema List and Set; is it valid to say that this will work: value=List( title=uValue, constraint=classProvides(IMyClass) ) where IMyClass defines the schema for the MyClass and is the only objects allowed in the List? I would rather say: value=List( title=uValue, value_type=Object(schema=IMyClass) ) Anyhow, such a constraint is of limited use only, since it does not prevent you from adding any object you like to the list *after* it got assigned to the 'value' attribute. Regards, Markus Kemmerling ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Set List constraints
Am 10.07.2008 um 21:56 schrieb Tim Cook: On Thu, 2008-07-10 at 16:59 +0200, Markus Kemmerling wrote: I would rather say: value=List( title=uValue, value_type=Object(schema=IMyClass) ) Can you elaborate why? You want to restrict the elements of a list to instances that provide a given interface IMyClass, right? That's exactly what a field's value_type attribute is for: It validates every element in a sequence or, more generally, a collection, before setting it. When you set the value_type to Object(schema=IMyClass) a validation error, SchemaNotProvided, will be raised for every list element not providing IMyClass (which in turn will raise a WrongContainedType error for the list itself). The (rarely used) classProvides you used in your code example: value=List( title=uValue, constraint=classProvides(IMyClass) ) is meant to be used in class definitions to declare that a class itself -- not is instances -- provides a given interface. Anyhow, such a constraint is of limited use only, since it does not prevent you from adding any object you like to the list *after* it got assigned to the 'value' attribute. Okay, but that would be badly behaved code; correct? Probably. But then I would consider using a tuple instead of a list (and a frozenset instead of a set). In my implementation I am creating instances and committing them to a ZODB repository. My thoughts were that copies of those instances would continue to constrain the types allowed in that attribute. Is that incorrect? I am not sure if I get this. If you set an instance of a mutable type like a list as an attribute of some other instance described by a schema, it will be validated, but still remain mutable (finally your other object only holds a reference to your mutable). It doesn't matter if it is persistent or not, or if it was copied before. But I might misunderstand your intention here. Regards, Markus Kemmerling ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Securitypolicy issues when moving to eggs
Hi Jesper, Am 06.11.2007 um 13:02 schrieb Jesper Petersen: Hi, I recently moved my webapp from z3.3.1 tarball to all eggs. It's working great except for my securitypolicy, which seems to sort of half-work. For example, earlier an authenticated member could view http://myhost/mysite/@@footest.html with and without the @@ but now it's only viewable with them. Note that with the @@ you traverse the view via the 'view' namespace traverser defined by the zope.traversing package, without them Zope uses the ItemTraverser defined by the zope.app.container package. Both traversers perform an adapter lookup for your view 'footest.html'. One possible reason for your problem might be that the security declarations for the traversers themselves differ. Regards, Markus Kemmerling___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Interfaces with circular references
Hi Hermann, Am 21.09.2007 um 14:03 schrieb Hermann Himmelbauer: Hi, Does someone know how to create interfaces with circular references? E.g.: class IHusband(Interface): wife = Object(schema=IWife) class IWife(Interface): husband = Object(schema=IHusband) What's the suggested solution to this problem? Perhaps I should modify the classes after they are declared, e.g.: class IHusband(Interface): pass class IWife(Interface): pass IHusband.wife = Object(schema = IWife) IWife.husband = Object(schema = IHusband) Or is there a better solution? I don't think dot notation works for schema fields, you should use mapping notation. Otherwise I had a similar problem some time ago and coded it similarly, although slightly simpler: class IHusband(Interface): wife = Object(schema= Interface) class IWife(Interface): husband = Object(schema= IHusband) IHusband['wife '].schema = IWife Regards, Markus Kemmerling ___ Medical University Vienna Core Unit for Medical Education P.O. Box 10 A-1097 Vienna phone: +43-1-40 160-36 863 fax: +43-1-40 160-93 65 00 http://www.meduniwien.ac.at/bemaw/ Best Regards, Herman -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Problem with z3c.form security when rendering error
Hi Yuan, Am 20.09.2007 um 18:17 schrieb Yuan HOng: I am new to z3c.form. In my first AddForm, I encountered the following problem: When the form is submitted which contains some input error, like missing required fields, the rendering of the error message causes an system error. I'm happy to see that someone else encounters this error, too ;-) See my posting about security concerns with `z3c.layer`'s trusted traversers one or two weeks ago. [...] So it seems the default z3c.form security declaration only allows access to 'update', 'error' and 'render' attributes of an ErrorViewSnippet object. I tried to work this around the by adding the 'widget' attribute to the IErrorViewSnippet interface and the system error is no longer raised. However, this time, another exception is raised saying the 'label' property of the widget is not accessible. Try to add security declarations for the widgets you use as well (see the posting mentioned above). How can I setup my security properly to use z3c.form smoothly? Shouldn't 'widget' not be in IErrorViewSnippet since it is evidently externally used in the rendering template? Probably. Thanks for suggestions. -- Hong Yuan Regards, Markus Kemmerling ___ Medical University Vienna Core Unit for Medical Education P.O. Box 10 A-1097 Vienna phone: +43-1-40 160-36 863 fax: +43-1-40 160-93 65 00 http://www.meduniwien.ac.at/bemaw/ ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Prevent an event
Am 16.09.2007 um 21:00 schrieb [EMAIL PROTECTED]: Is there away to prevent the catalog from auto-indexing upon creation of the catalog? Why would you want to do this on the catalog level? You can exclude objects from being auto-(re-)indexed by implementing `zope.app.catalog`'s marker interfaces `INoAutoIndex` and `INoAutoReindex`, respectively. Regards, Markus Kemmerling ___ Markus Kemmerling Medical University Vienna Core Unit for Medical Education P.O. Box 10 A-1097 Vienna phone: +43-1-40 160-36 863 fax: +43-1-40 160-93 65 00 http://www.meduniwien.ac.at/bemaw/ ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Prevent an event
Am 17.09.2007 um 19:45 schrieb Philipp von Weitershausen: Kevin Smith wrote: Thanks for your reply, I'm having scaling issues and want to be in control of the indexing process. I have a large number of documents already in the system. I believe the best case for me in the short run is to prevent the initial indexing on catalog creation and if understand it correctly, recursively touching all of my objects. Just to be clear: As far as I remember, nothing happens on catalog creation. Stuff happens on *index* creation. When you add an index to a catalog that is already aware of objects, it will make sure that the newly added catalog is up to date by forcing an indexing procedure. And yes, this will wake up all the objects in your catalog (which isn't a recursive process, nor does it mean touching in the sense of modification). Unfortuantely, there isn't a way to prevent the execution of a selected event subscriber (which is probably what you want; you don't want to prevent the event as a whole). Why not just disable the `indexAdded` event subscriber, add the indices, and enable it again? Ok, that means two server restarts, but there will probably be a time when you could do that and adding the indices themselves is *not* time consuming. Or am I missing something? Regards, Markus Kemmerling ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Trusted traversers in z3c.layer: security concerns
Hi, In our applications we use `z3c.pagelet` together with the `IPageletBrowserLayer` defined by `z3c.layer.pagelet`. The latter registers two traversers, `SimpleComponentTraverser` and `ItemTraverser`, as trusted adapters. I do not completely understand the reason for doing so (as explained in the `trusted` layer's README), but it seems to me that doing so raises a security issue. (BTW, there seems to be no difference at all between the `IMinimalBrowserLayer` and the `ITrustedBrowserLayer`, all three subpackages in `z3c.layer` register both traversers as trusted adapters.) Registering a traverser as a trusted adapter means that the adapted object will not be security protected. Normally this will be no problem, since the traversed object will be explicitely security proxied by the publication traverser's `traverseName` method (defined by the `zope.app.publication.publicationtraverse` module). The problem arises if the traversed object is not the object itself, but a view on it--assuming the view is called via the default namespace and not via the 'view' namespace, i.e. without '@@' prepended. To see the problem consider what happens if you traverse to a container view via the default namespace: * `traverseName` looks up the traverser by querying for the adapter providing `IPublishTraverse` and calls it's `publishTraverse` method. * In the case of a container the traverser will be the `ItemTraverser` (defined by the `zope.app.container.traversal` module) which will return the view registered for the container. Since the traverser is trusted, it's context isn't security proxied. Therefore the container won't be security proxied either when adapted by the view. So after traversing the view itself will be security proxied (by the `traverseName` method), but access to it's context container will *not* obey any security restrictions. In other words, the security declaration for the container itself will be ignored. This does not happen of course when traversing via the `view` namespace, since the `view` traverser is not registered as a trusted adapter by the `IPageletBrowserLayer`. I verified the described behaviour by commenting out the security declaration for some container. Doing so I was able to traverse to it via the default namespace, but not via the 'view' namespace. Now, in our applications, we not only use pagelets, but also `z3c.form` based forms . When I tried to run our tests without registering the traversers as trusted adapters, it turned out, that a number of additional security declarations are necessary to make the tests pass again. E.g., I had to explicitely allow access to widgets like class class=z3c.form.browser.text.TextWidget allow interface=z3c.form.interfaces.IWidget / /class and also to add a `widget` attribute to the definition of the `IErrorViewSnippet`. Since I can't believe that everybody else using `z3c.form` is also using trusted traversers, I wonder if I am missing something crucial here ... Regards, Markus Kemmerling Medical University Vienna Core Unit for Medical Education P.O. Box 10 A-1097 Vienna phone: +43-1-40 160-36 863 fax: +43-1-40 160-93 65 00 http://www.meduniwien.ac.at/bemaw/ ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: AW: [Zope3-Users] Trusted traversers in z3c.layer: security concerns
Hi Roger, thank you for the quick reply. Am 11.09.2007 um 17:47 schrieb Roger Ineichen: [...] Stephan and I hade a couple of discussions about to write a introspection test framework which shows us what can get accessed and what not, based on the configure.zcml directives registered all over the project. Probably we can take another look at this and write some minimal hacker tool wich tries to hack a running server by trying acessing all views and adapters etc. We are definitely interested in such a tool and I would be glad to spend some time on this at the sprint. Such a tool should also be able to generate a PDF report showing the security settings. But that's another story... ... but the easier one, considering tools like RML and z3c.rml at hand ;-) Regards, Markus Kemmerling Medical University Vienna Core Unit for Medical Education P.O. Box 10 A-1097 Vienna phone: +43-1-40 160-36 863 fax: +43-1-40 160-93 65 00 http://www.meduniwien.ac.at/bemaw/ ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
