[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
dtml-var standard_html_header
centerbPlease Pick A Property Category/b/center
table align="center"
form action="edit_propertyCategory" method="POST"
trtd
SELECT name="PropertyCategory"
dtml-in "propertysheets.items()"
OPTION value="dtml-var sequence-key"dtml-var
sequence-key/OPTION
/dtml-in
/SELECT
/tr/td
trtdINPUT TYPE="SUBMIT" value="Edit Properties"/td/tr
/form
/table
dtml-var standard_html_footer
2. edit_PropertyCategory
dtml-var standard_html_header
dtml-if "REQUEST.has_key('PropertyCategory')"
dtml-in "propertysheets.items()"
dtml-let y=sequence-key
dtml-if "REQUEST.PropertyCategory==y"
dtml-let x=sequence-item
table border="1" align="center" cellspacing="0" cellpadding="4"
trth colspan="2" align="center"Edit dtml-var y
Properties/th/tr
form action="edit_propertiesChange" method="POST"
dtml-in "x.propertyItems()"
trtd
dtml-var sequence-key
/tdtd
input type="text" name="dtml-var sequence-key" value="dtml-var
sequence-item"
/td/tr
/dtml-in
trtd colspan="2" align="center"input type="SUBMIT" value="Change
Properties"/td/tr
input type=hidden name="PropertyCategory" value="dtml-var
PropertyCategory"
/form
/table
/dtml-let
/dtml-if
/dtml-let
/dtml-in
dtml-else
You have reached this page in error
/dtml-if
dtml-var standard_html_footer
3. edit_propertiesChange
dtml-var standard_html_header
dtml-if "REQUEST.has_key('PropertyCategory')"
dtml-in "propertysheets.items()"
dtml-let y=sequence-key
dtml-if "REQUEST.PropertyCategory==y"
dtml-let x=sequence-item
dtml-call "x.manage_changeProperties(REQUEST)"
dtml-var PropertyCategory Properties Changedbr
a href="dtml-var URL1"Back To Object/abr
a href="dtml-var URL2"Back To Container/a
/dtml-let
/dtml-if
/dtml-let
/dtml-in
dtml-else
You have reached this page in error
/dtml-if
dtml-var standard_html_footer
___
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 )
