[Zope-dev] Re: [Zope] Container Class questions
Robin Becker writes: > I would like to add properties in a property sheet, but cannot find a > neat way to see the properties on the base object and on the > propertySheet. > > So I would like my properties to show > id > title > > and the properties on my basic properties sheet. > > I can easily add properties directly to the object during the Thing_add > and Thing_addForm and these appear on the properties tab for added > objects. > > How do I get a tab for the property sheets? I am not sure, I understand precisely, what you want to reach. ZClass properties are managed on distinct property sheets. I do not know of a neat way to present (and change) properties from different property sheets (other than adapting the "manage_PropertiesForm" manually). To get a tab for a single property sheet (other than the default one), you define a "View" (in the ZClass) for it. I agree with you, that there should be a way to add properties to the "inherited" or "default" property sheet (or, more generally, any inherited property sheets, e.g. from inherited ZClasses). When I read the code, I had the impression that access to the default property sheet should be able via the property sheet name 'default'. Unfortunately, it did not work (Zope 2.2.2). Apparently, there is some missing link. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope] Container Class questions
Dieter Maurer wrote: > > Robin Becker writes: > > I would like to add properties in a property sheet, but cannot find a > > neat way to see the properties on the base object and on the > > propertySheet. > > > > So I would like my properties to show > > id > > title > > > > and the properties on my basic properties sheet. > > > > I can easily add properties directly to the object during the Thing_add > > and Thing_addForm and these appear on the properties tab for added > > objects. > > > > How do I get a tab for the property sheets? > > I am not sure, I understand precisely, what you want to reach. > > ZClass properties are managed on distinct property sheets. > I do not know of a neat way to present (and change) properties > from different property sheets (other than adapting the > "manage_PropertiesForm" manually). I wrote up some code (dated) to present generic forms for changing zclass properties, code to follow. i generally use it just to get a fast prototype for a system, example: picking a property sheet and harding coding a link to the second method. yes this code does find base class properties (including stuff like webdav, etc), or at least it did last time i used it (era 2.1.6). hope this helps Kapil three methods one to select a property sheet one to edit a property one to change a property sheet 1. edit_properties Please Pick A Property Category 2. edit_PropertyCategory Edit Properties You have reached this page in error 3. edit_propertiesChange Properties Changed Back To Object Back To Container You have reached this page in error ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns design questions
At 12:50 PM 10/7/00 -0700, Michael Bernstein wrote: >"Phillip J. Eby" wrote: >> >> Presentation logic lives with an object's class, and deals with what that >> object knows about presenting itself. UI implementation is "glue" >> presentation that lives in a Specialist for use by any object that needs to >> present UI related to objects of the kind the Specialist handles. The >> terms used here are "official" terminology with precise definitions, btw. >> I am just trying to answer your questions as best I know how. > >I'm not sure, but did you mean 'are not' in that last >sentence? Whoops. :( Yes, you're correct, I lost the 'not' somewhere along the way there. >Here is where my 'Specialist/Generalist' confusion came >from. It seems to me, that the simple implementation (you >might also call it the default implementation) for the >selector UI in your example should be contained in a >'Generalist' object that could be overridden by a >'Specialist'. This would help make crystal clear the line >between Presentation Logic and Implementation UI, and would >also serve as a useful starting point for creating the >overriding methods in the 'Specialist' by the framework >customizer. Hm. It seems to me to add too many entities without any real advantages. It's straightforward to have overrideable default implementations in a Specialist - note LoginManager's login, logout, and forbidden pages, which are UI snippets of this sort. >> Okay, you've got me there. I tend not to think of it that way, if only >> because there are many things less than satisfactory about its current >> state of implementation. For example, if we had it to do over again, I >> would re-work the internal API so that roles, domains, authentication, >> etc., could be controlled by plug-ins on the user sources. At that point >> there would be no need for different kinds of user sources, as they would >> all be fully generic. But anyway, I digress. > >In light of my own dificulties in adding SMB authentication >to PersistentUserSouce.py, and Bill Andersons dificulties >with password encryption on some Unices, I think that this >would be a *very* worthwhile effort. Such a project might >also give you the mandate to get DC to fix the Zope internal >acl_users interfaces that were getting in your way. > >How large of a project would this be? Not very hard, I think. Basically I think we'd warp the "Data Plug-Ins" plug-in group on UserSource to allow what I'll call "authorization plug-ins" to be included. And, we'd complement that with some of the work Ty's already done on mapping roles, domains, etc. back onto plain object attributes so that you can just use regular attribute providers or SkinScript to compute them. I'm not sure, but I think I recall that we even came up with a way to securely manage a password attribute, which we needed for one of our own applications a month or two ago. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Accessors for DataSkin attributes (was Re: [Zope-dev] Success!
At 09:14 PM 10/6/00 -0500, Steve Spicklemire wrote: > >OK.. allow me to summarize my very latest thought. Subclassing >is OK withing my own framework. Yep. >It's OK to require users of my >framework to create ZClasses that subclass from my core logic >Python classes, and from DataSkin. Sort of. To be more precise, as a framework provider you may require that participating objects provide a particular interface. The framework user may 1) create a subclass of one of your classes, 2) add an implementation of your interface to an existing class of theirs, or 3) use your class as is, using SkinScript or other means to form an "adapter" between your desired interface and their existing objects. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope] Container Class questions
In article <[EMAIL PROTECTED]>, Kapil Thangavelu
<[EMAIL PROTECTED]> writes
...
One of the things I wanted to do was to add a multiple selection
property to the default properties in the Thing_add method. In order to
do this in multiple zclasses I wanted to have a product wide
variable/property/method to use as the allowed list. I could find no way
to do that. As always with Zope there seem to be different
inheritances/scopes at different times. Statically I can add a property
to the product say projectList and it is visible when I add properties
to a property sheet. So product wide things are visible statically,
however projectList doesn't seem to be visible to my Thing_add method
when I use
manage_addProperty('projects','projectList','multiple selection') ie
I get an error saying projectList isn't known. Clearly product wide
methods are intended to be known at create time so why not properties?
--
Robin Becker
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
