Re: AW: [Zope3-Users] How to check access on a view?
Am Sonntag, 17. Februar 2008 12:41 schrieb Roger Ineichen: Hi Hermann Betreff: Re: [Zope3-Users] How to check access on a view? [...] Hi, For a simple menu, I need to check if the current principal has permissions to access a view. I understand that I can use the canAccess()/canWrite() function on object attributes but how could I do this for views? import zope.security zope.security.canAccess(myView, '__call__') should work. Or if the view provides a render method, you can check zope.security.canAccess(myView, 'render'). Yes, many thanks, this did the trick! Best Regards, Hermann -- [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: AW: AW: [Zope3-Users] z3c.form - howto ignore the context for singlewidgets in an Edit form?
Am Sonntag, 10. Februar 2008 19:39 schrieb Roger Ineichen: Hi Christophe Betreff: Re: AW: [Zope3-Users] z3c.form - howto ignore the context for singlewidgets in an Edit form? [...] class ISubscribeSchema(zope.interface.Interface): The subscription form. password = zope.schema.Password( title=_(u'Password'), description=_(u'The password for the applicant.'), required=True) confirm = zope.schema.Password( title=_(u'Confirm password'), description=_(u'The password for the principal.'), required=True) @zope.interface.invariant def confirmPassword(task): if task.password != task.confirm: raise zope.interface.Invalid( _(Password doesn't compare with password confirmation.)) if len(task.password) 6: raise zope.interface.Invalid( _(Password must be at least 6 characters long.)) class SubcriptionForm/form.Form): Subscription form. ignoreContext = True fields = field.Fields(ISubscribeSchema) [...] On the other hand, the password is already used in the definition of the Principal (ex: in IInternalPrincipal), so you get overlapping definitions of the password, and you need to explicitly omit() the Principal password in the form generation. Or maybe you think it's better to use different schemas for the Principal itself and for the subscription? Yes, I think using a different schema for password confirmation is the right concept. This let us define a invariant in the schema too. Both the invariant and the confirmation field are not a part of the (real) data model. Of corse that's not the only one solution, but most of the time this works very well. It also allows you to use a very simple form implementation without any magic widgets etc. Yes, although a confirmation widget looked appealing at first, I also agree with Roger now and implemented this similar as shown above. Back to z3c.formwidget: What do you think should this package exactly contain: - Only widgets? - Combinations of schemas and widgets? - Also schemas without widgets (like an Email schema that inherits from a TextLine and thus uses a TextWidget)? Best Regards, Hermann -- [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: AW: [Zope3-Users] eggsplosion again
Am Sonntag, 10. Februar 2008 15:09 schrieb Roger Ineichen: Hi Christophe Betreff: [Zope3-Users] eggsplosion again [...] But I fear that in a near future we will need to start any interfaces.py with : import zope.schema import foo.schema import bar.schema (...) import mycoolnamespace.schema I agree with your point that the implementations are found everywhere and that is hard to get the full picture of what's available and what's not. But I also think a package is not the right place to collect widgets or fields etc. Because this will very quickly end in unmanagable dependencies. Well, but where would we put such quite generic stuff such an EMail field? I don't think it makes much sense to create some z3c.email package. And I can think of numerous generic and simple fields, e.g. for telephone numbers, a choice for the gender, etc. What about the following layout: - z3c.fields: extra fields but no widgets; The code does not depend on extra packages such as z3c.form etc. This would be a place for the EmailTextLine field, a Currency field etc. People developing packages would commit their specific fields to this package and use it from their package. - z3c.formwidget: widgets for z3c.fields and also alternative widgets for fields. In this case, I only have to import from z3c.fields and - in case I'd like to override widgets - register widgets for fields from z3c.formwidget. Another advantage would be that we could provide skeletons (interfaces, classes, tests etc.) in these packages that show people how to implement their own fields/widgets in a good style. Best Regards, Hermann -- [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
AW: AW: AW: [Zope3-Users] z3c.form - howto ignore the context for singlewidgets in an Edit form?
Hi Herman Betreff: Re: AW: AW: [Zope3-Users] z3c.form - howto ignore the context for singlewidgets in an Edit form? [...] Back to z3c.formwidget: What do you think should this package exactly contain: - Only widgets? - Combinations of schemas and widgets? - Also schemas without widgets (like an Email schema that inherits from a TextLine and thus uses a TextWidget)? The importest thing for me is that I don't have to use packages that I don't need. This means we should use for each package a own namespace like: z3c.formwidget.email z3c.formwidget.mynicedojowidgetwith20mbjavascript For me it's inacteptable to have more code installed at a server the I need to. I really like to get rid of this additional unneeded packages and dependencies. The overall concept for eggs is all about explosion and the component architecture supports this too. Write monolitc packages which contains solutions for everything is very bad since we use eggs. Small usfull libraries are welcome. PS; I really like to get the memory usage for a single zope server below of 30 MB in the near future. Regards Roger Ineichen Best Regards, Hermann -- [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: AW: AW: AW: [Zope3-Users] z3c.form - howto ignore the context for singlewidgets in an Edit form?
Roger Ineichen a écrit : Hi Herman Betreff: Re: AW: AW: [Zope3-Users] z3c.form - howto ignore the context for singlewidgets in an Edit form? [...] Back to z3c.formwidget: What do you think should this package exactly contain: - Only widgets? - Combinations of schemas and widgets? - Also schemas without widgets (like an Email schema that inherits from a TextLine and thus uses a TextWidget)? The importest thing for me is that I don't have to use packages that I don't need. This means we should use for each package a own namespace like: z3c.formwidget.email z3c.formwidget.mynicedojowidgetwith20mbjavascript For me it's inacteptable to have more code installed at a server the I need to. I really like to get rid of this additional unneeded packages and dependencies. The overall concept for eggs is all about explosion and the component architecture supports this too. Write monolitc packages which contains solutions for everything is very bad since we use eggs. Small usfull libraries are welcome. PS; I really like to get the memory usage for a single zope server below of 30 MB in the near future. Hi Roger Some thoughts on this topic (hoping this has not been already deeply discussed and concluded) I see that what I called the worst case (1 egg per widget) is exactly what you would like to see. Actually I don't understand the reason, unless you're working on an embedded zope that must fit in a really small system, which is not the most common case. I don't see a problem in having some unused code. If this code is not import(ed) in python, or include(d) in zcml, it will not be used nor loaded in the memory (or am I wrong?) I find that having to wonder which tens of eggs to import and whether they really work with each others or not is more pain than just having fewer eggs, and searching inside them what they offer, while being sure they are consistent. I find it great to create an interface with several fields (all available in one egg), then to be able to have the system generate predefined forms automatically, without looking in the pypi for missing widgets. If some provided widget is not ok for my use, then I can search alternative widgets in separate eggs, or implement mine. This is particularly true for newcomers, that don't know how (and why) components are separated, and must understand a whole lot of things before knowing they must seek a particular egg for the micro-feature they want. Feature separation can be made at different levels: an egg contains several packages that contain several modules that contain several classes, and I think you will always have unused classes in a module, unused modules in a package and unused packages in an egg, unless there is one egg per class... What you really want is having control on what is eventually loaded. Isn't it already possible with zcml? Or maybe all this would be easier with meta-eggs? regards, Christophe Regards Roger Ineichen Best Regards, Hermann -- [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
AW: AW: AW: AW: [Zope3-Users] z3c.form - howto ignore the contextfor singlewidgets in an Edit form?
Hi Christophe Betreff: Re: AW: AW: AW: [Zope3-Users] z3c.form - howto ignore the contextfor singlewidgets in an Edit form? [...] PS; I really like to get the memory usage for a single zope server below of 30 MB in the near future. Hi Roger Some thoughts on this topic (hoping this has not been already deeply discussed and concluded) I see that what I called the worst case (1 egg per widget) is exactly what you would like to see. Actually I don't understand the reason, unless you're working on an embedded zope that must fit in a really small system, which is not the most common case. Yes, I'm working on a small as possible zope instance. The reason is that we need a fast and low memory using zope3 base. I don't see a problem in having some unused code. If this code is not import(ed) in python, or include(d) in zcml, it will not be used nor loaded in the memory (or am I wrong?) I find that having to wonder which tens of eggs to import and whether they really work with each others or not is more pain than just having fewer eggs, and searching inside them what they offer, while being sure they are consistent. I find it great to create an interface with several fields (all available in one egg), then to be able to have the system generate predefined forms automatically, without looking in the pypi for missing widgets. If some provided widget is not ok for my use, then I can search alternative widgets in separate eggs, or implement mine. For one of our application our customer a swiss bank, reviews the code we use and write. It's a realy pain to split existing unused code for this project. And we don't like to document code which we don't use. This is particularly true for newcomers, that don't know how (and why) components are separated, and must understand a whole lot of things before knowing they must seek a particular egg for the micro-feature they want. I guess it's better to learn what's going on then to develope for newcommers. I guess Grok is the right place for them. Not that Grok is bad, but the target of Grok, as far as I can see, is the ability to develop with minimal effort and everything should just work. I guess this is not true for zope as the component system. There you really have to know what's going on. Or at least you need to learn that if it comes to speedup optimisation. There is no Zope3 which fits for everything and z3c packages which most of them are base libraries are not the level to blow them up. I realy like to have small independent packages with minimal dependencies which I can assamble to the right thing for each project. Feature separation can be made at different levels: an egg contains several packages that contain several modules that contain several classes, and I think you will always have unused classes in a module, unused modules in a package and unused packages in an egg, unless there is one egg per class... What you really want is having control on what is eventually loaded. Isn't it already possible with zcml? The exclude directive form zc.configuration helps a lot to exlude configuration loading. But independent eggs make it more explicit and let people think one more time about their dependencies which is allways a good thing. Or maybe all this would be easier with meta-eggs? Yes, you are right, we can provide a egg with battery included. This let us include one egg which includes different packages with one single include. Regards Roger Ineichen _ END OF MESSAGE regards, Christophe Regards Roger Ineichen Best Regards, Hermann -- [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 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: AW: AW: AW: AW: [Zope3-Users] z3c.form - howto ignore the contextfor singlewidgets in an Edit form?
Hi Roger. You make great points here for why those serious about zope's potential really ought to consider explicit configuration. I also believe taking time to understand configuration, dependencies and what is actually being configured is better that implicitly trusting something automatic to do the right thing. Implicit automatic configuration is a good starting point howeverfor folks just starting z3 as you have pointed out but it is best for to learn this for the reasons you cited and more. Good points about concise packages with specific functionality also. Regards, David Roger Ineichen wrote: I guess it's better to learn what's going on then to develope for newcommers. I guess Grok is the right place for them. Not that Grok is bad, but the target of Grok, as far as I can see, is the ability to develop with minimal effort and everything should just work. I guess this is not true for zope as the component system. There you really have to know what's going on. Or at least you need to learn that if it comes to speedup optimisation. There is no Zope3 which fits for everything and z3c packages which most of them are base libraries are not the level to blow them up. I realy like to have small independent packages with minimal dependencies which I can assamble to the right thing for each project. Feature separation can be made at different levels: an egg contains several packages that contain several modules that contain several classes, and I think you will always have unused classes in a module, unused modules in a package and unused packages in an egg, unless there is one egg per class... What you really want is having control on what is eventually loaded. Isn't it already possible with zcml? The exclude directive form zc.configuration helps a lot to exlude configuration loading. But independent eggs make it more explicit and let people think one more time about their dependencies which is allways a good thing. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
