Re: [Zope-dev] Re: Zope logic
Andy McKay wrote: Teehee, Googlebot once hit ZopeZen for about 3 days in a continuous loop. Just use absolute_urls. Always. Its one of Zope's golden rules. On a high volume site, the absolute_url can put a lot of unneccessary strain on the server :-S Mind you I've abused acquistion a few times, it comes in useful to be able to have a different / shorter url point to the same object... Indeed ;-) cheers, Chris ___ 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 logic
On Friday 31 May 2002 4:44 am, Tim Hoffman wrote: But whilst you might think acquisition looks like inheritance it isn't Please don't confuse the two, they really are different, and until you think about them differently, I believe you won't necessarily grasp the significance of acquisition, or use it properly. Agreed. Any tool/language/approach/methodology can be used incorrectly, But today implicit acquisition is forced onto almost every zope class, and every attribute lookup. Sometimes the way to use acquisition correctly is not to use it at all, but that is often an impossible option. These characteristics mean implicit acquisition is not a tool - its a disease. Imagine if you couldnt write a C++ class without including operator overloading functions.. ___ 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 logic
Hi On Fri, 2002-05-31 at 15:14, Toby Dickenson wrote: On Friday 31 May 2002 4:44 am, Tim Hoffman wrote: But whilst you might think acquisition looks like inheritance it isn't Please don't confuse the two, they really are different, and until you think about them differently, I believe you won't necessarily grasp the significance of acquisition, or use it properly. Agreed. Any tool/language/approach/methodology can be used incorrectly, But today implicit acquisition is forced onto almost every zope class, and every attribute lookup. Sometimes the way to use acquisition correctly is not to use it at all, but that is often an impossible option. These characteristics mean implicit acquisition is not a tool - its a disease. True, however all of my work to date in CMF, I haven't found that acquisition, to be a major problem, except once. However the most problems I have had, are with poorly thought out or poorly documented object hierarchies, so that it is not obvious or clear where and when you should override methods, try manage_afterClone some time, and I know this isn't an acquisition problem, or overriding some of the default behaviour for FTP methods. The lack of documented approach is far worse than the enforced acquisition, IMHO ;-) If how these things work and how to use them, was well documented , then strangeness with acquisition wouldn't be so strange, ie it would be documented and you could get your head around it. (I think we will be in a much better position with Zope 3) Also if it doesn't work the way it is documented you could call it a bug, whereas the current situation is hmm is this how it work or is it a bug, or am I missing something ;-) Rgds Tim Imagine if you couldnt write a C++ class without including operator overloading functions.. I hate C++ ;-) ___ 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 logic
Tim Hoffman wrote: However the most problems I have had, are with poorly thought out or poorly documented object hierarchies, You mean class hierarchies. so that it is not obvious or clear where and when you should override methods, try manage_afterClone some time, and I know this isn't an acquisition problem, or overriding some of the default behaviour for FTP methods. The lack of documented approach is far worse than the enforced acquisition, IMHO ;-) You'll like Zope3 then. There is no dependency on class hierarchies. The inheritance hierarchies throughout are either very shallow or non-existent. However, none of the power of expressing the affordances of objects is lost. Instead, this is expressed through the interfaces an object implements, which can be definied either in your class definitions, or elsewhere in zcml or in other classes/interfaces. If how these things work and how to use them, was well documented, then strangeness with acquisition wouldn't be so strange, ie it would be documented and you could get your head around it. There is only so much complexity that I can handle at a time. Often working on what should be an isolated part of Zope2 exceeds that threshold. (I think we will be in a much better position with Zope 3) :-) -- Steve Alexander ___ 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 logic
Hi On Fri, 2002-05-31 at 16:10, Steve Alexander wrote: Tim Hoffman wrote: However the most problems I have had, are with poorly thought out or poorly documented object hierarchies, You mean class hierarchies. Oops, yep, that's what I meant, so that it is not obvious or clear where and when you should override methods, try manage_afterClone some time, and I know this isn't an acquisition problem, or overriding some of the default behaviour for FTP methods. The lack of documented approach is far worse than the enforced acquisition, IMHO ;-) You'll like Zope3 then. There is no dependency on class hierarchies. The inheritance hierarchies throughout are either very shallow or non-existent. However, none of the power of expressing the affordances of objects is lost. Instead, this is expressed through the interfaces an object implements, which can be definied either in your class definitions, or elsewhere in zcml or in other classes/interfaces. Yeah, I have been following most of the Zope3 discussions. If how these things work and how to use them, was well documented, then strangeness with acquisition wouldn't be so strange, ie it would be documented and you could get your head around it. There is only so much complexity that I can handle at a time. Often working on what should be an isolated part of Zope2 exceeds that threshold. Tell me about it, I really can't do much without keeping an IDLE session going and trolling through all the source, try getting immutable unique ID's working for every object in a CMF site, that when you clone an object you get a new unique ID, man I had some trouble with that, it seemed where manage_afterClone changed in a release or two, so that things stopped working, after an upgrade. Having clearly defined public interfaces will certainly help. See ya T (I think we will be in a much better position with Zope 3) :-) -- Steve Alexander ___ 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 )
[Zope-dev] Re: Zope logic
gt; Looking at the zope.org logs, I once saw GoogleBot generate URLs like gt; this to zope.org of 1000 characters or more. Teehee, Googlebot once hit ZopeZen for about 3 days in a continuous loop. Just use absolute_urls. Always. Its one of Zope's golden rules. Mind you I've abused acquistion a few times, it comes in useful to be able to have a different / shorter url point to the same object... -- Andy McKay ___ 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 )
[Zope-dev] Re: Zope logic
Shane Hathaway [EMAIL PROTECTED] writes: Looking at the zope.org logs, I once saw GoogleBot generate URLs like this to zope.org of 1000 characters or more. I had this too, leading to heavy traffic what's more. Cf http://zwiki.org/TheRobotProblem. Since then, as a temporary measure I set the no robots meta header in standard_wiki_header. Also, I cleaned up various link holes that would lead to infinite urls, using page_url() and wiki_url(). Finally, all wiki links were changed to use absolute urls (now optional). These things should help, and in fact it should be safe to allow google into a modern zwiki. Back to the original poster: yes, to avoid getting hammered by search engines it is necessary to make sure you expose no links leading to infinite urls. This may not be as hard as you think. Hackers can make up urls, but search engines don't (yet). -Simon ___ 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 logic
On Thu, 30 May 2002, Andy McKay wrote: gt; Looking at the zope.org logs, I once saw GoogleBot generate URLs like gt; this to zope.org of 1000 characters or more. Teehee, Googlebot once hit ZopeZen for about 3 days in a continuous loop. Just use absolute_urls. Always. Its one of Zope's golden rules. Mind you I've abused acquistion a few times, it comes in useful to be able to have a different / shorter url point to the same object... I just wonder whether it's possible to add an attribute, say 'inheritable', so that everyone will be happy. I think only then it can be called a 'feature'. Otherwise an obtrusion. Wei He ___ 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 logic
But whilst you might think acquisition looks like inheritance it isn't Please don't confuse the two, they really are different, and until you think about them differently, I believe you won't necessarily grasp the significance of acquisition, or use it properly. Any tool/language/approach/methodology can be used incorrectly, Rgds Tim On Fri, 2002-05-31 at 10:46, Wei He wrote: On Thu, 30 May 2002, Andy McKay wrote: gt; Looking at the zope.org logs, I once saw GoogleBot generate URLs like gt; this to zope.org of 1000 characters or more. Teehee, Googlebot once hit ZopeZen for about 3 days in a continuous loop. Just use absolute_urls. Always. Its one of Zope's golden rules. Mind you I've abused acquistion a few times, it comes in useful to be able to have a different / shorter url point to the same object... I just wonder whether it's possible to add an attribute, say 'inheritable', so that everyone will be happy. I think only then it can be called a 'feature'. Otherwise an obtrusion. Wei He ___ 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 ) ___ 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 )
