RE: [Zope] Help! UNDO bug...
So when I SAVED my VERSION, I typed in a series of comments in the provided text box. Part of my commentary included the "<TITLE>" tag. Well apparently zope (or rather my browser) doesn't like it when you include random tags. Now when I click on the UNDO tab, instead of providing me with a listing, it (IE5 *and* NS4.7) prints the first 2-3 lines and then ... nothingness.
Ack - Zope doesn't care, but your browser does and the extra tag(s) are wrecking its html rendering. I'm adding a fix for 2.1.0 for this. In the meantime if you want to fix this on your site, edit the file lib/python/App/undo.dtml in your Zope installation and change line 41 from: <strong><dtml-var description></strong> by <strong> to: <strong><dtml-var description html_quote></strong> by <strong> Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
ok so I am quite new to Zope, and I am wondering if this is a feature or a bug (using the zope site as an example): http://www.zope.org/Documentation results in the Documents page http://www.zope.org/Resources results in the resources page, BUT so does: http://www.zope.org/Documentation/Resources Whether it is a feature or a bug, how can I stop it from doing that? (PS. If it is a feature, I would appreciate any sort of explanation as to what is happening to make this occur.) Many Thanks, Sachin
Sachin Shah wrote:
ok so I am quite new to Zope, and I am wondering if this is a feature or a bug (using the zope site as an example):
http://www.zope.org/Documentation
results in the Documents page
results in the resources page, BUT so does:
http://www.zope.org/Documentation/Resources
Whether it is a feature or a bug, how can I stop it from doing that?
(PS. If it is a feature, I would appreciate any sort of explanation as to what is happening to make this occur.)
Ahh...the wonders of acquisition. The URL http://www.zope.org/Documentation/Resources has Zope first look in the Documentation folder for an object called Resources. When it doesn't find one, it goes up the 'namespace stack', which typically is the list of folders in the path in the URL. In this case, the parent to Documentation, the root folder, is searched next, where it does find an object called Resources. The power of this is that Resources, accessed from either location, _can_ behave differently because it has a different _context_. How do you prevent it? Well, you can't, but you can design your site so that you don't create links that take you to unwanted URLs like the above. For example, on the Zope site, the side bar has a relative link to "Resources". They don't worry about that because acquisition makes it possible. However, they could have the sidebar link to "/Resources", then it always goes to Resources from the root. I hope this clears thinks up a bit. Actually, it won't because acquisition still confuses a lot of us. :-) Cheers... Bruce -- Bruce Elrick, Ph.D. Saltus Technology Consulting Group Personal: belrick@home.com IBM Certified Specialist Business: belrick@saltus.ab.ca ADSM, AIX Support, RS/6000 SP, HACMP
Sachin Shah wrote:
http://www.zope.org/Resources results in the resources page, BUT so does: http://www.zope.org/Documentation/Resources Whether it is a feature or a bug, how can I stop it from doing that?
Bruce Elrick wrote:
Ahh...the wonders of acquisition. ... How do you prevent it? Well, you can't,...
Seems to me this is the dark side of acquisition. It prevents you from having total control over what URIs your web site exports to the world. All good web publishers know "Cool URIs don't change". http://www.w3.org/Provider/Style/URI.html That ideal is difficult to achieve under normal circumstances, but it becomes near impossible when you lose control over what URIs you publish to the world, doesn't it? -- | Don Porter dgporter@erols.com | | "Some days you just can't get rid of a bomb!" | | -- Adam West as BATMAN | |______________________________________________________________________|
don, you're right. cool URIs don't change. however, the deduction that you're left with less than total control isn't right IMHO. of course, it is true that when someone types arbitrary URIs from a zope site that person can come up with URIs that are not following these conventions. but if the zope site developer takes a little care when devising intra-site links those "changing" URIs will never appear. unless, like i said, someone actually sat down and typed arbitrary combinations into the browser's address field. greetings jens vagelpohl <snip>
Seems to me this is the dark side of acquisition. It prevents you from having total control over what URIs your web site exports to the world. All good web publishers know "Cool URIs don't change".
http://www.w3.org/Provider/Style/URI.html
That ideal is difficult to achieve under normal circumstances, but it becomes near impossible when you lose control over what URIs you publish to the world, doesn't it? </snip>
From: Don Porter <dgporter@erols.com>
Seems to me this is the dark side of acquisition. It prevents you from having total control over what URIs your web site exports to the world. All good web publishers know "Cool URIs don't change".
http://www.w3.org/Provider/Style/URI.html
That ideal is difficult to achieve under normal circumstances, but it becomes near impossible when you lose control over what URIs you publish to the world, doesn't it?
It is a tradeoff. For the price of making resources available via redundant addresses, you get the ability to do things like apply themes to pages-- http://acquisition.com/documents/boring.html --can also be available as-- http://acquisition.com/themes/christmas/documents/boring.html In /themes/christmas you find a new standard_html_header which puts a gaudy red and green theme on the text, and contains an /images folder with christmas-oriented versions of the page decorations. There might also be a /themes/escher. Silly example, but it demonstrates what you get out of the deal. Mike.
participants (6)
-
Brian Lloyd -
Bruce Elrick -
Don Porter -
Jens Vagelpohl -
Mike Pelletier -
Sachin Shah