May 2002 - Zope-Dev - Zope lists

Can I get rid of standard_template.pt?
by Lennart Regebro 13 May '02

13 May '02

I'm not using it, and will never use it, so why does Zope 2.5.1 always create one for me? Grrr. Highly annoying. >:-[

7 8

Zope Backup/Recovery
by Richard McKinley 13 May '02

13 May '02

I recently managed to lock myself out of zope. Is there a way to recover/copy the database containing the DTML documents/ZSQL methods etc. to a new installation? I have had no success in logging into zope with the new superuser I created.. Thanks, Richard _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

2 1

Security-Bug
by Andre Schubert 13 May '02

13 May '02

Hi, could this be a bug in the security-machinery? Lets say we have a role foo, this role has the permission to view the management screens. Lets say we have a user bar which has the role foo. If i login into the ZMI a be able to go to Control_Panel/Products. And now if i want i be able to add a Zope Permission in every Product-Folder i found. Testet with Zope 2.4.3 Do i have misset any security-permissions or is this really a bug? Thanks in advance

2 3

Locked out of ZOPE! please help!
by Richard McKinley 13 May '02

13 May '02

Hi, I recently checked the encrypted passwords option under the security settings - applied it to previous users and lo an behold locked myself out.. Can someone please tell me how to 'fix' this situation? I've tried to create an emergency user at the dos prompt: >C:\Program Files\TestZope\bin>python "C:\program files\testzope\zpasswd.py" >access but after entering username/password, specifying cleartext and hitting n or return at the domain restrictions - the user does not appear to get created. Any advice on this appreciated, thanks, Richard _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

2 1

Permissions
by brian.r.brinegar.1 12 May '02

12 May '02

Hello, I would like to setup the security on a Zope server such that a user can edit permissions on something they own, but not grant more permissions than what they have acquired from the parent. If a user owns a folder they could grant "Owner" any permissions they want inside of that folder (Assuming they have the "Change permission" permission). Is there a way to limit which permissions a user can change? I would like to be able to delegate permissions. Such that if a user creates a folder they can grant other roles permissions up to the permissions they have acquired from the parent folder. Is this possible? I don't want that user to be able to grant themselves additional permissions. Thanks, -Brian Brinegar

2 1

Betreff
by Immer frischer Kaffee... 12 May '02

12 May '02

1 0

Re: ZPT and else
by Brent Hendricks 11 May '02

11 May '02

Quoting "Jeffrey P Shell": > The 'not' TALES namespace is valuable. The downside is that you > evaluate the expression twice. A good way to work within this is > something that I did earlier today, outside of this conversation, > where I evaluate an expression earlier and assign it to a variable: > > <div id="edit-area" > tal:define="editItems python:here.getMenuItem(...)"> > > <h3>Edit Menu Items</h3> > <form action="Delete" method="post" name="actForm" > tal:condition="editItems"> > > ... (form and table elements, and a loop over editItems > contained in here if there were results) ... > > </form> > > <div class="emph" > tal:condition="not:editItems"> > No menu items available > </div> > > </div> Another way to do this is to use the python test() function inside tal:replace to conditionally replace the "if" content with the "else" content. For example: <div id="edit-area" tal:define="editItems python:here.getMenuItem(...)"> <h3>Edit Menu Items</h3> <form action="Delete" method="post" name="actForm" tal:replace="python:test(editItems, default, 'No menu items available')"> ... (form and table elements, and a loop over editItems contained in here if there were results) ... </form> </div> This technique works well when you have one case which is more "involved" and can be the default, and another case which is simple text (like an error message). -- Brent ------------------------------------------------------------------------- "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures." -- Frederick Brooks, Jr., The Mythical Man Month

2 1

Re: ZClasses useful! [Was: ZMI / JavaScript brainstorm]
by Martijn Jacobs 10 May '02

10 May '02

> I will not stop dissing them until people stop using them and then complaining > when they break, don't do what they want or behave unexpectedly. What's your efford on this task? If people like to use them, let them! It's not up to you to decide for THEM what's best or not. The choice for YOURSELF not to use them is just as fair as other peoples choices. martijn.

12 28

Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
by Tim Hoffman 10 May '02

10 May '02

HI Jim It's a good point you raise. I personally don't consider tal: and metal: tags to really be a traditional programming language, more a way of including directives and/or python into an XML/html namespace. I think it would depend if you consider each tal: statement in a tag to be all part of a single statement. I view it as being a number of seperate attributes in a xml/html tag, and attributes within a tag are typically order independant. ie <img src="file.gif" border="0" vspace="1" hspace="1"> or <img border="0" vspace="1" hspace="1" src="file.gif"> render exactly the same thing. In addition event handlers in html ie onClick onBlur etc are all order independant. now adding tal: attributes that where order dependant would seem to fly in the face of that convention. (Admittedely there are probably no strange dependancies that could be introduced with different orders of border, src etc) It would also be potentially dangerous have specific authored ordering when non programmers start editing page templates, and accidentally change the order of tags because they looked nice in a different order, or when someone uses a graphical html editor, I have seen ones, where you are given a nice dialog box to edit attributes of a tag, and when it write the values back it always writes them in "it's internally specified order" not the order you specify. This I would imagine could introduce all sorts of nasty bugs. On the basis of in place ordering would it also mean that a attribute should be declared before a tal:attributes could be used. Within an attribute ie tal:define the statements are executed in the order they are specified, which does make sense. I suppose I have put forward more than 2c now ;-) T On Fri, 2002-05-10 at 09:30, Jim Penny wrote: > On Fri, May 10, 2002 at 09:07:26AM +0800, Tim Hoffman wrote: > > Hi > > > > Just my 2c worth, but I would like to defend order of execution of > > ZPT. What it does mean for me is I can guaruntee zpt commands will > > "always" be processed in a known order irrespective of where you > > put them in a tag, this I like ;-) > > Would you defend a python interpreter that always moved definitions > ahead of conditionals ahead of loops? > > Does even a "intentionally limited templating language" have the right > to second-guess the programmer and re-arrange the order of written > commands? > > Yes, I am aware that 'C' and fortran and many other languages may do > rearrangement of arithmetic expression, and that this may be > side-effectful. But, can you point me to any other language that > reorders looping and conditionals? > > Jim > > > > > > What I do miss is "else" clause but I think it would be probably > > be too hard to implement, and too much of encouragement for people > > to start putting more logic in the template, so on the whole it > > is probably best to leave it out. > > > > See ya

4 3

Re: Zope-Dev digest, Vol 1 #1682 - 11 msgs
by Godefroid Chapelle 10 May '02

10 May '02

At 06:13 10/05/2002, zope-dev-request(a)zope.org wrote: >'else' is tricky within the block oriented structure of anything XML-ish, >because of the concept of 'well-formedness'. The 'if' statement would have >to be singly wrapped, and the else block wrapped separately, looking at >least somewhat awkward any way you go about it. The best I can come up with >in my mind is this, in order to have the 'else' pick up on the condition >expressed in its surrounding container. But, yuck: > ><if ...> > true stuff > <else> > false stuff > </else> ></if> > > >A good page template way is something like this: > ><tal:if condition="myTalesExpression"> > truth ></tal:if> ><tal:else condition="not:myTalesExpression"> > false ></tal:else> > >The 'not' TALES namespace is valuable. The downside is that you evaluate >the expression twice. A good way to work within this is something that I >did earlier today, outside of this conversation, where I evaluate an >expression earlier and assign it to a variable: > ><div id="edit-area" > tal:define="editItems python:here.getMenuItem(...)"> > > <h3>Edit Menu Items</h3> > <form action="Delete" method="post" name="actForm" > tal:condition="editItems"> > > ... (form and table elements, and a loop over editItems > contained in here if there were results) ... > > </form> > > <div class="emph" > tal:condition="not:editItems"> > No menu items available > </div> > ></div> > > >This is something I did a lot in DTML too, setting a search result to either >a global variable, or inside of a large <dtml-let> namescape It is maybe not clear that the above is really usable and allowed. I do not know how and where to stress that the tal: marked tags are underdocumented what a pity. I have already tried : http://www.zope.org/Documentation/ZopeBook/AdvZPT.stx#3-44 Sorry that I am not able to explain it better... -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 18 / 202 1348 Louvain-la-Neuve Belgium Tel + 32 (10) 459901 Mob + 32 (477) 363942 TVA 467 093 008 RC Niv 49849

1 0