RE: [Zope] overriding __str__ method?
Seb Bacon writes: > I know how to create a form that does what I want (update properties, > whatever). What I don't know is how to include it as part of the rendered > content programmatically. At the moment users have to go to > www.widgets.com/manage_content, log in, and see a set of forms loosely based > on the Zope manage interface. Instead, I'd like them to go to the same url, > and see exactly the same website as someone who's not logged in, except they > have these lovely little "edit this" buttons next to each editable content > element (by which I mean image, text snippet, etc). > > Now I *could* do a > > > edit this > > > in each content element. But I'd much rather be able to subclass or mixin an > 'editable' class for each content element in question. The question is, > what methods should I be providing to manipulate how the content is > rendered? For example, I can provide a new 'view' method in the 'views' tab > for a ZClass, but this does not get called when an object is rendered as > part of another document. The reason I was going on about __str__ is > because that seems to be the only place that you can interfere with how the > content is rendered inline? > > Hope that's clearer, I now do understand it better. Though, I have to admit that others understand you first problem statement better than I did. DTML renders an object by 1. looking it up 2. calling it, if it is callable 3. stringifying the result by calling "str" Thus, for callable objects, changing the "__str__" will not help. For callable objects, "__call__" would need to be modified. However, I would strongly discourage to make such a drastic change to Zope objects: * a modification of "__call__" would not only affect rendering but also other use of objects (e.g. if DTML methods are used to validation and should return "0" or "1". * the pages could be littered with "edit me" buttons. It is (in general) not easy for your content manager to determine the object boundary which the "edit me" applies to. * we use DTML objects sometimes to factor out common "object"s such as e.g. the option list for HTML tags. Automatically adding "edit me" would produce invalid HTML. I would rather suggest, you develop some method (or product), say "content_render", that can render an object (emulation the normal DTML rendering process) and can add whatever is necessary to facilitate management (e.g. visualizing object boundaries, placing "edit me"). Rather than you would then use at places where the result would be usefull and legal (e.g. not inside a "select" tag). Have you looked at the PTK? You will find there some of your idea realized. However in a simplified form: a document contains a single "edit me" integrated to allow the owner to edit his content. Dieter ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] overriding __str__ method?
Seb Bacon writes: > ... "manage_content" to enable editing all relevant aspects > Now I want a way to give the user access to this screen. I could do a new > version of the folders tree view (manage_menu), but what I'd really like to > do is have a button next to each of these elements ("edit this") which calls > its manage_content method. The button would only appear when the user was > authenticated / authorised. > > My problem: > The only place I can think of doing this is in each object's __str__ method. Why do you want to tinker with the "__str__" method for this reason? "manage_menu" uses "". The tree tag provides you with sufficient flexibility to show an additional button and to make this conditional on the users roles. Dieter ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] overriding __str__ method?
so if i'm not mistaken you want to be able to include an object instance with say and, depending on the user being authenticated, have that object render with "edit this" button or without? overriding the __str__ method can afaik only be done inside a python product (read the python product tutorial) you could use lalo's "Renderable Base ZClass" product or call your instance like so: (or call it ) and in the "method_that_renders_myinstance" you'd render those "edit" buttons only if theres the correct role in AUTHENTICATED_USER hth peter sabaini. On Mon, 9 Oct 2000, Seb Bacon wrote: :Thanks for the reply, : :> Either I don't understand the problem or you're making it too :> complicated. : :I think both, but mostly the latter ;) : :Explanation MK II: : :I know how to create a form that does what I want (update properties, :whatever). What I don't know is how to include it as part of the rendered :content programmatically. At the moment users have to go to :www.widgets.com/manage_content, log in, and see a set of forms loosely based :on the Zope manage interface. Instead, I'd like them to go to the same url, :and see exactly the same website as someone who's not logged in, except they :have these lovely little "edit this" buttons next to each editable content :element (by which I mean image, text snippet, etc). : :Now I *could* do a : : :edit this : : :in each content element. But I'd much rather be able to subclass or mixin an :'editable' class for each content element in question. The question is, :what methods should I be providing to manipulate how the content is :rendered? For example, I can provide a new 'view' method in the 'views' tab :for a ZClass, but this does not get called when an object is rendered as :part of another document. The reason I was going on about __str__ is :because that seems to be the only place that you can interfere with how the :content is rendered inline? : :Hope that's clearer, : :seb. : : : : : :> :> You have a form to edit the properties. :> ... :> :> ... :> :> The action method of this form sets the REQUEST variables to the :> property names: :> ... :> :> ... :> (I generally use the same names for form vars and property names :> to avoid confusing myself) :> :> then: :> :> :> Does this help? :> > :> :> Seb Bacon wrote: :> :> > My strategy: :> > Each element that I want the user to be able to edit is a ZClass with a :> > manage_content method. This provides the custom management view (e.g. :> > combines properties and title/data into a single form). :> > Now I want a way to give the user access to this screen. I :> could do a new :> > version of the folders tree view (manage_menu), but what I'd :> really like to :> > do is have a button next to each of these elements ("edit :> this") which calls :> > its manage_content method. The button would only appear when :> the user was :> > authenticated / authorised. :> > :> > My problem: :> > The only place I can think of doing this is in each object's :> __str__ method. :> > But AFAIK there's no convenient way of overriding its default behaviour. :> > What I'd like to do is override it in the ZClass views interface. I can :> > override the 'View' method (from the ZClass 'views' tab), but :> that doesn't :> > get called in the course of rendering a component in a page. :> The problem :> > would seem to be that there's no equivalent of the __str__ :> method available :> > to override... Or is there? : : :___ :Zope maillist - [EMAIL PROTECTED] :http://lists.zope.org/mailman/listinfo/zope :** No cross posts or HTML encoding! ** :(Related lists - : http://lists.zope.org/mailman/listinfo/zope-announce : http://lists.zope.org/mailman/listinfo/zope-dev ) : -- _ peter sabaini, mailto: [EMAIL PROTECTED] - ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] overriding __str__ method?
Thanks for the reply, > Either I don't understand the problem or you're making it too > complicated. I think both, but mostly the latter ;) Explanation MK II: I know how to create a form that does what I want (update properties, whatever). What I don't know is how to include it as part of the rendered content programmatically. At the moment users have to go to www.widgets.com/manage_content, log in, and see a set of forms loosely based on the Zope manage interface. Instead, I'd like them to go to the same url, and see exactly the same website as someone who's not logged in, except they have these lovely little "edit this" buttons next to each editable content element (by which I mean image, text snippet, etc). Now I *could* do a edit this in each content element. But I'd much rather be able to subclass or mixin an 'editable' class for each content element in question. The question is, what methods should I be providing to manipulate how the content is rendered? For example, I can provide a new 'view' method in the 'views' tab for a ZClass, but this does not get called when an object is rendered as part of another document. The reason I was going on about __str__ is because that seems to be the only place that you can interfere with how the content is rendered inline? Hope that's clearer, seb. > > You have a form to edit the properties. > ... > > ... > > The action method of this form sets the REQUEST variables to the > property names: > ... > > ... > (I generally use the same names for form vars and property names > to avoid confusing myself) > > then: > > > Does this help? > > > > Seb Bacon wrote: > > > My strategy: > > Each element that I want the user to be able to edit is a ZClass with a > > manage_content method. This provides the custom management view (e.g. > > combines properties and title/data into a single form). > > Now I want a way to give the user access to this screen. I > could do a new > > version of the folders tree view (manage_menu), but what I'd > really like to > > do is have a button next to each of these elements ("edit > this") which calls > > its manage_content method. The button would only appear when > the user was > > authenticated / authorised. > > > > My problem: > > The only place I can think of doing this is in each object's > __str__ method. > > But AFAIK there's no convenient way of overriding its default behaviour. > > What I'd like to do is override it in the ZClass views interface. I can > > override the 'View' method (from the ZClass 'views' tab), but > that doesn't > > get called in the course of rendering a component in a page. > The problem > > would seem to be that there's no equivalent of the __str__ > method available > > to override... Or is there? ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] overriding __str__ method?
Seb Bacon wrote: > My strategy: > Each element that I want the user to be able to edit is a ZClass with a > manage_content method. This provides the custom management view (e.g. > combines properties and title/data into a single form). > Now I want a way to give the user access to this screen. I could do a new > version of the folders tree view (manage_menu), but what I'd really like to > do is have a button next to each of these elements ("edit this") which calls > its manage_content method. The button would only appear when the user was > authenticated / authorised. > > My problem: > The only place I can think of doing this is in each object's __str__ method. > But AFAIK there's no convenient way of overriding its default behaviour. > What I'd like to do is override it in the ZClass views interface. I can > override the 'View' method (from the ZClass 'views' tab), but that doesn't > get called in the course of rendering a component in a page. The problem > would seem to be that there's no equivalent of the __str__ method available > to override... Or is there? Either I don't understand the problem or you're making it too complicated. You have a form to edit the properties. ... ... The action method of this form sets the REQUEST variables to the property names: ... ... (I generally use the same names for form vars and property names to avoid confusing myself) then: Does this help? -- Tim Cook -- Cook Information Systems | Office: (901) 884-4126 8am-5pm CDT * It's easy to stop making mistakes. Just stop having ideas. * FreePM Project Coordinator http://www.freepm.org OSHCA Founding Supporter http://www.oshca.org ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )