Re: [Zope-dev] Re: ZMI / JavaScript brainstorm
Charles Y. Choi wrote: With ZMI, you can create different methods/objects and then edit them. The problem is that pretty much every other editor out there doesn't know a whit about the types of objects/methods they are creating. Does emacs really know the difference between a python method, dtml-method, dtml-document, and a page template? Not likely. *grinz* You never heard of a PUT_factory? You can (and I do) do this in Zope 2 already. Think about it, how does Windoze know the difference between a Photoshop file and a Windows Bitmap? Zope 2 is even clever than this, I have logic that says if the first character in a thing is a # then create a PythonScript from it... As for EMACS, it certainly knows about python (M-x python-mode), and there's HTML mode for page templates. If you wanna use DTML, you deserve to burn in hell anyway, so you ain't gonna need an editor ;-) 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: ZMI / JavaScript brainstorm
Chris Withers wrote: Charles Y. Choi wrote: With ZMI, you can create different methods/objects and then edit them. The problem is that pretty much every other editor out there doesn't know a whit about the types of objects/methods they are creating. Does emacs really know the difference between a python method, dtml-method, dtml-document, and a page template? Not likely. *grinz* You never heard of a PUT_factory? You can (and I do) do this in Zope 2 already. Think about it, how does Windoze know the difference between a Photoshop file and a Windows Bitmap? Zope 2 is even clever than this, I have logic that says if the first character in a thing is a # then create a PythonScript from it... As for EMACS, it certainly knows about python (M-x python-mode), and there's HTML mode for page templates. If you wanna use DTML, you deserve to burn in hell anyway, so you ain't gonna need an editor ;-) Yes, and though your PUT_factory override is a great thing, it's an unsupported patch: that is, it's not part of the standard packaging of Zope. The conventions you use (# for PythonScripts) are not clearly documented. And as much as I'd love to to chuck DTML, ZPT is still buggy in 2.5.0 - (try creating a page template for the view method of a ZClass). As far as emacs goes, it uses file extensions to automatically determine what mode to be in. Brain hurts, must sleep ... -cc ___ 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: ZMI / JavaScript brainstorm
Charles Y. Choi wrote: Yes, and though your PUT_factory override is a great thing, it's an unsupported patch: that is, it's not part of the standard packaging of Zope. Urm, PUT_factory has been a standard part of Zope for some time now... The conventions you use (# for PythonScripts) are not clearly documented. That's because I've overridden the default PUT_Factory, hich is one of its strengths, you can customise it ;-) And as much as I'd love to to chuck DTML, ZPT is still buggy in 2.5.0 - (try creating a page template for the view method of a ZClass). ZClasses are a waste of time, even more so than DTML. I've not experienced any bugs in ZPT when used in a sane context. As far as emacs goes, it uses file extensions to automatically determine what mode to be in. yes, and? *grinz* 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 )
[Zope-dev] RE: [Zope-CMF] Fieldindex searches very slow when anonymous.
THANK YOU This worked extremely well, and the site is almost faster than the squid cache now. :-) http://www.forskning.no is a major ZOPE site (for us), that will be released tomorrow noon local time. This is the first site that uses our soon to be opensourced TopicMap engine that builds on CMF. The engine lets CMF handle all Topic Map data items, giving us access to CMF functionality like versioning and workflow. It should be opensourced when we have time to clean it up a bit and document it. - Arnar Lundesgaard -Original Message- From: Tres Seaver [mailto:[EMAIL PROTECTED]] Sent: 9. april 2002 05:43 To: Arnar Lundesgaard Cc: [EMAIL PROTECTED] Subject: Re: [Zope-CMF] Fieldindex searches very slow when anonymous. What is killing your query is the test for effective range of content. If your site does not use the concept (i.e., all your content has 'None' for both its effective and expires dates), you can apply the following patch to remove the check:: -- patch starts here - --- CMFCore/CatalogTool.py4 Jan 2002 19:50:04 - 1.22 +++ CMFCore/CatalogTool.py9 Apr 2002 03:42:14 - @@ -186,7 +186,7 @@ user = _getAuthenticatedUser(self) kw[ 'allowedRolesAndUsers' ] = self._listAllowedRolesAndUsers( user ) -if not _checkPermission( +if 0 and not _checkPermission( CMFCorePermissions.AccessInactivePortalContent, self ): base = aq_base( self ) now = DateTime() -- patch ends here --- Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ 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: ZMI / JavaScript brainstorm
ZClasses are a waste of time, even more so than DTML. Words of comfort. :^) Nice never having spent the time to learn 'em. I've not experienced any bugs in ZPT when used in a sane context. Same here, after several months' usage. -- Two witches watch two watches. Which witch watched which watch? Nicola Larosa - [EMAIL PROTECTED] ___ 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] ZClasses useful! [Was: ZMI / JavaScript brainstorm]
At 09.04.2002 10:46 +0100, Chris Withers wrote: ZClasses are a waste of time, even more so than DTML. Chris, please stop that dissing of ZClasses. They are *very* useful indeed! No, not so much for the seasoned Python/Zope coder, but for the content manager (remember, Zope is a CMS after all!). I have successfully taught ZClasses to people who would not easily grasp how this (disk-based) Python stuff works, simply because they are content managers not software developers. And, IMO, they should not even need to care. I sure hope this part of Zope's audience is not forgotten in Zope3. I have always considered it a strength of Zope to allow unskilled users to create and deploy dynamic websites. We can fight this out at the BBQ if you like ;-) Stefan -- BLOWFISH n. - Preference for beef ___ 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] ZClasses useful! [Was: ZMI / JavaScript brainstorm]
On Tue, 09 Apr 2002 12:56:38 +0200, Stefan H. Holek [EMAIL PROTECTED] wrote: ZClasses are a waste of time, even more so than DTML. Chris, please stop that dissing of ZClasses. They are *very* useful indeed! No, not so much for the seasoned Python/Zope coder Even for the seasoned Python/Zope coder, ZClasses have a sweet spot that cant be beaten by any other zope technology. Toby Dickenson [EMAIL PROTECTED] ___ 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-CMF] Fieldindex searches very slow when anonymous.
Arnar Lundesgaard wrote: THANK YOU This worked extremely well, and the site is almost faster than the squid cache now. :-) http://www.forskning.no is a major ZOPE site (for us), that will be released tomorrow noon local time. This is the first site that uses our soon to be opensourced TopicMap engine that builds on CMF. The engine lets CMF handle all Topic Map data items, giving us access to CMF functionality like versioning and workflow. It should be opensourced when we have time to clean it up a bit and document it. Excellent -- I'm glad that helped. Note that for Zope 2.6, we have added some new index types to deal more directly with such problems: - DateIndex: a FieldIndex which knows it is for DateTimes, and indexes a much more efficient (both space and time!) representation; - DateRangeIndex: indexes a pair of DateTimes, allowing the specific query you had trouble with to go *much* faster; - TopicIndex: indexes values which pass user-defined filters, effectively precomputing a frequently-used catalog query. Tres. -Original Message- From: Tres Seaver [mailto:[EMAIL PROTECTED]] Sent: 9. april 2002 05:43 To: Arnar Lundesgaard Cc: [EMAIL PROTECTED] Subject: Re: [Zope-CMF] Fieldindex searches very slow when anonymous. What is killing your query is the test for effective range of content. If your site does not use the concept (i.e., all your content has 'None' for both its effective and expires dates), you can apply the following patch to remove the check:: -- patch starts here - --- CMFCore/CatalogTool.py4 Jan 2002 19:50:04 - 1.22 +++ CMFCore/CatalogTool.py9 Apr 2002 03:42:14 - @@ -186,7 +186,7 @@ user = _getAuthenticatedUser(self) kw[ 'allowedRolesAndUsers' ] = self._listAllowedRolesAndUsers( user ) -if not _checkPermission( +if 0 and not _checkPermission( CMFCorePermissions.AccessInactivePortalContent, self ): base = aq_base( self ) now = DateTime() -- patch ends here --- Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ 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: ZClasses useful! [Was: ZMI / JavaScript brainstorm]
Stefan H. Holek wrote: At 09.04.2002 10:46 +0100, Chris Withers wrote: ZClasses are a waste of time, even more so than DTML. Chris, please stop that dissing of ZClasses. They are *very* useful indeed! If you enjoy pain and suffering and no upgrade path. 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. No, not so much for the seasoned Python/Zope coder, but for the content manager (remember, Zope is a CMS after all!). Use the Types Tool in the CMF, its a lot closer to what ZClasses wanted to be. I sure hope this part of Zope's audience is not forgotten in Zope3. I have always considered it a strength of Zope to allow unskilled users to create and deploy dynamic websites. Yup, I have the same fear for Zope 3, but trying to stand up for one of the most difficult to learn and use pieces in the whole Zope architecture is not the way to go about it... We can fight this out at the BBQ if you like ;-) ...you're buying the beers though. 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 )
[Zope-dev] Re: ZClasses useful! [Was: ZMI / JavaScript brainstorm]
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. ___ 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] RedstrictedCreation proposal
Re: http://dev.zope.org/Wikis/DevSite/Proposals/RestrictedCreation This proposal from Itamar has been up on dev.zope.org for a while, proposing a way for a registered type to control whether or not it can be added to a container, or a per-container basis. I now have an implementation of this in CVS in the toby-metatypes-branch. I propose this goes into zope 2.6. Any comments? (Ive CCed everyone who has commented on the proposal; I hope thats OK) ___ 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: ZClasses useful! [Was: ZMI / JavaScript brainstorm]
On Tue, 9 Apr 2002, Martijn Jacobs wrote: 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. Actually, we find on #zope-dev that if we steer newbies away from zclasses and toward Products to begin with, they thank us later, and it reduces our support burden. The same can be said for this list. Chris does tend to be a little vociferous about it grin. We aren't generally dealing with content devloper types in either place. Learning ZClasses (because that's what was documented in the manual at the time) rather than going straight to python products was the *worst* mistake I made in starting to use Zope, myself. It probably set me back six to nine months. --RDM ___ 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] RedstrictedCreation proposal
IMO, this comes at this at the wrong direction. Objects should not decide whether they can be added to a given folder, the folder should be the one that makes that decision. It gives me the heebie geebies to think that every time the add list is rendered, a whole slew of class methods are potentially called to determine what gets put there. This also invokes my ui chaos alarm. It gives things such arbitrary ability to dynamically affect the ui, that it may cause mass confusion by users who can't understand why an object is addable in one folder but not in another (seemingly identical) folder. Granted, this is somewhat possible right now (using permissions), but this pushes it a bit over the edge for me. It smells too much like magic. -Casey Toby Dickenson wrote: Re: http://dev.zope.org/Wikis/DevSite/Proposals/RestrictedCreation This proposal from Itamar has been up on dev.zope.org for a while, proposing a way for a registered type to control whether or not it can be added to a container, or a per-container basis. I now have an implementation of this in CVS in the toby-metatypes-branch. I propose this goes into zope 2.6. Any comments? (Ive CCed everyone who has commented on the proposal; I hope thats OK) ___ 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] RedstrictedCreation proposal
IMO, this comes at this at the wrong direction. Objects should not decide whether they can be added to a given folder, the folder should be the one that makes that decision. It gives me the heebie geebies to think that every time the add list is rendered, a whole slew of class methods are potentially called to determine what gets put there. I think (correct me though, if I'm wrong!) that Toby actually implemented the suggestion that Jim made on the comments page of the proposal (add a filter to the meta type info, allowing products to do this without killing performance). We need to find a reasonable place to document the API addition for this before merging it. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ 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] RedstrictedCreation proposal
Toby Dickenson wrote: (Ive CCed everyone who has commented on the proposal; I hope thats OK) Could everyone stick to zope-dev only? One copy of each email is enough ;) ___ 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] RedstrictedCreation proposal
Brian Lloyd wrote: I think (correct me though, if I'm wrong!) that Toby actually implemented the suggestion that Jim made on the comments page of the proposal (add a filter to the meta type info, allowing products to do this without killing performance). ...but hasn't this problem already been solved with the wierd-interface-filter thing that Andreas did for the PluginIndexes stuff? 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] RedstrictedCreation proposal
On Tue, 9 Apr 2002 10:57:04 -0400, Brian Lloyd [EMAIL PROTECTED] wrote: IMO, this comes at this at the wrong direction. Objects should not decide whether they can be added to a given folder, the folder should be the one that makes that decision. Zope can already do that. Check out how ZCatalog.Indexes requires all of its contained items to implement the PluggableIndex interface. That works well when you have a special folder type, but it doesnt help when you want to control whether special objects can be added to ordinary folders. It gives me the heebie geebies to think that every time the add list is rendered, a whole slew of class methods are potentially called to determine what gets put there. One function per type, if it was specified during registration. This isnt configurable through-the-web. I think (correct me though, if I'm wrong!) that Toby actually implemented the suggestion that Jim made on the comments page of the proposal (add a filter to the meta type info, allowing products to do this without killing performance). Thats correct. I changed the parameter name from Jim's suggestion; 'filter' to 'container_filter'. We need to find a reasonable place to document the API addition for this before merging it. Im happy to keep any documentation up to date, provided it is already up to date. Is there any more than the docstring? Suprisingly, I couldnt find any at http://www.zope.org/SiteIndex/search?text_content=registerClass Toby Dickenson [EMAIL PROTECTED] ___ 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] [RFClet]: What about the request method and the client side trojan?
The issue of client side trojan recently came to my mind again. Looking at http://www.zope.org//Members/jim/ZopeSecurity/ClientSideTrojan I found nothing new since Oct. 2001, so I thought I bring up the issue again, maybe it's something which could be taken care of for zope = 2.6. I wrote something about that at the wiki, but let me repeat my proposal. I think zope's management methods (the potentially destructive ones) should not accept REQUESTs with REQUEST_METHOD GET. This is in accordance with the http/1.1 rfc (reposted from the wiki): Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered safe. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. The win would be that disabling javascipt would make a client save from this form of attack, AFAIK, OTOH I can't think of anything which would break ATM. cheers, oliver ___ 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] [RFClet]: What about the request method and the client side trojan?
The issue of client side trojan recently came to my mind again. Looking at http://www.zope.org//Members/jim/ZopeSecurity/ClientSideTrojan I found nothing new since Oct. 2001, so I thought I bring up the issue again, maybe it's something which could be taken care of for zope = 2.6. I wrote something about that at the wiki, but let me repeat my proposal. I think zope's management methods (the potentially destructive ones) should not accept REQUESTs with REQUEST_METHOD GET. This is in accordance with the http/1.1 rfc (reposted from the wiki): snip RFC citation... The win would be that disabling javascipt would make a client save from this form of attack, AFAIK, OTOH I can't think of anything which would break ATM. While I don't necessarily disagree about making GETs idempotent, this still doesn't make you safe, even with JS turned off. A quick example: images can be used as form submit buttons. If I can get you to visit a page and click on my innocent looking image... you're done :) This is hard, hard, problem. While some good ideas have been proposed, there is not really a quick fix that doesn't have some downside that some group somewhere considers a showstopper :( Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ 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] Speaking of 2.6...
...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final plan. I didn't get much (any?) response :( For a couple of things that were ready to go and fairly non controversial (like Toby's unicode work), I put on the BDFL hat and said merge it!. But there are still a lot of things on the proposed features that are undone, and some that are controversial enough that we need to get to closure on them. I'll volunteer to convert the current proposed feature list into a draft plan, where the conversion boils down to adding some columns to the table: Proposal - name and link to the proposal Resources - who is working on it Committed - Y/N whether the volunteers have committed to have the implementation and docs done by the first week in June. I'll fill in what I know has been committed to, people can update this (or let me know and I'll do it), and anything that doesn't get a 'Y' in a reasonably short time will be put in the cooler. Vetted - Y / N whether the community and / or the relevant BDFLs have come to some agreement on whether it *should* be done. The list of items without a 'Y' will be our next order of business. Getting to closure on those either via the list, IRC, or whatever is the main block on the critical path. Status - Complete or incomplete I've taken a first stab at this. I've set the committed to 'Y' for those things that I know I've gotten commitments for. For those set to 'N', please let me know if you can commit to the date (or change it yourself in the wiki). The updated plan is at: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures Once we get the commitments up to date, we can start wrangling with the vetting... Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ 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-Coders] Re: [Zope-dev] Speaking of 2.6...
Brian Lloyd wrote: Both me and Myroslav Opyr [EMAIL PROTECTED] are quite commited to do the proposed Object Links/References. Although from the emails we exchanged with you, I would've guessed that it was one of the controversial enough to be a Vetted item :-) Anyways I'm commited to do it. I do agree with your argument about link semantics but, at least for me, a link/reference is a link, and the semantics are perfectly defined i.e its not a RedirectObject. As in Unix, a hard link has different semantics from a soft link. I'm thinking of the hard link semantics. I guess that what I was getting at is that the semantics for this need to be spelled out in detail so that we can make sure that they make sense before something like this goes in. Ok. Let's find out what we have and what we want. First of all we have strict hierarchy in ZODB where each object appears only once in the tree. Thus to access to an object it is only one way from root down to an object through containers. All security in Zope is based on that pattern. I am omitting Acquisition machinery to simplify (and I do not see it clearly in the context here). The idea is to allow user to specify several points of presence (pop) for an object. Does this break security? Probably yes, but in what case? If an object from higly secure envionment appeared somewhere in Anonymous zone, what then? Yes, Anonymous is able to alter object. But there was reason for that! Is Anonymous able to get out of the shared object to secure environment? No in no simple way. Sure if an object was DTML and Anonymous placed trojan horse in the script and someone from secure environment executed the code then we run in a problem. But we can warn user! And we have a lot of Restricted... techniques, maybe one can be applied here? Comparing it to Unix hard links is fine, but Unix doesn't use Acquisition to handle security, so the comparison is not apples-to-apples :) We need to spell out the exact semantics (*especially* wrt security, but also in terms of its effect on ZODB identity semantics, effects on undo, etc.) Ok. I am not too well in English but I'll try to do my best. If it is not hard for you give several words of explanation of ZODB identity semantics and effects on undo, not everything is clear for me. Security in particular is very concerned with *containment* path (rather than just acquisition path) in order to prevent stealing access through acquisition wrappers. Having objects with more than one place may introduce much the same problem, so we'll need to write up in detail the effects on the security machinery or its application to domain objects (or if the security machinery does not need to change, we need to spell out why). Why we are not willing to allow such scenario? AFAIK there was and are a lot of concernes refarding soft- and hardlinks in /tmp folder, with sticky bit, etc... But they are usually solved with different means. Yes, Zope and ZODB is much more complex. But why we have to limit ourselves because something is difficult. Why not mark the feature as experimental (red button, a lot of warnings, for instance) and make it available to SuperManager only ;) I'd be glad to get feedback, thanks, Myroslav -- Myroslav Opyr zope.net.ua http://zope.net.ua/ ° Ukrainian Zope Hosting e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] cell: +380 50.3174578 ___ 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: ZClasses useful! [Was: ZMI / JavaScript brainstorm]
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. Sure but many people ask more experienced developers for advice. I agree saying ZClasses suck totally is unhelpful. For people who dont know coding or want to do quick prototyping they have a place. However if someone asks me how to do a product, I normally give them the choice: use ZClasses but I would strongly recommend using a Product etc (and then be ready with the reasons why which is the next question). Unfortunately people deciding the right and wrong ways for other people to code is a trait sometimes found in Python / Zope world. But dont get me started on that :) -- 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 )
