October 2000 - Zope-Dev

Future of Xron and method scheduling in Zope
by Loren Stafford 12 Oct '00

12 Oct '00

I would be happy to turn development of Zope scheduling capabilities over to someone else, because I currently have no demand for scheduling capabilities and am not actively working on Xron. This could take any of the following forms: 1. Transfering Xron to another developer. For historical reasons, Xron uses GPL. 2. Starting a new product from scratch, without reference to the Xron product. The new product could carry a different license. I would be happy to give up the Xron name, in this case, if anyone wanted it for the new product. 3. Building scheduling capabilities into Zope core. Any takers? -- Loren

1 0

Re: [Zope-dev] Strange permissions in the (built-in) API reference
by Michel Pelletier 12 Oct '00

12 Oct '00

KevinL wrote: > > >>> Michel Pelletier wrote > > Dieter Maurer wrote: > > 3. Jim is working on formal interface support for python and he's > > thinking hard about it, we definatly didn't want to think hard about it > > and then turn out we came up with a bad answer, the existing API docs > > are just that, docs, not interfaces. When format interfaces come about, > > API docs will probably be converted to that format. > > As in mods to python to give it interface support? Is that discussion taking > place anywhere public? It already did way back in the day.... <shimmery dream sequence> http://www.zope.org/Members/jim/PythonInterfaces/Summary It's suddenly become an issue for me, for a > non-related project... > > KevinL

1 0

Re: A couple of ZPatterns questions
by James Johnson 12 Oct '00

12 Oct '00

>2. I want to store a list of products, and give each one an >arbitrary >number of photos. I can use a Product ZClass, subclassed from >ObjectManager and store Image objects inside it. Would using the new ZPatterns based EMarket-0.2.0a2 help as a base system. I would also look at the updated information on SkinScript located here. http://www.zope.org//Members/pje/Wikis/ZPatterns/SkinScriptSyntax I hope this helps. Get your Free E-mail at http://tacoma.zzn.com ____________________________________________________________ Get your own Web-Based E-mail Service at http://www.zzn.com

1 0

SessionManager, BerkeleyDB, and license compatability
by Toby Dickenson 12 Oct '00

12 Oct '00

I understand from the SessionTracking wiki that this product may use BerkeleyDB http://www.zope.org/Wikis/DevSite/Projects/CoreSessionTracking/CurrentStatus The BerkeleyDB license at http://www.sleepycat.com/licensing.html indicates that it may only be distributed free of charge with software that is 'freely available and redistributable by others'. We are currently using Zope to develop an application that does not fall into this category. It would be a serious problem for us if Zope's core had a dependency on code with this type of license. Toby Dickenson tdickenson(a)geminidataloggers.com

2 1

Inheritable properties(sheets)? Anyone? Anyone? Bueller?
by Alexander Schonfeld 12 Oct '00

12 Oct '00

I want to inherit the properties of one zclass in another zclass, but it seems to cause some namespace clashing... shouldn't this be possible? Working with the instance of the class is fine, but inter-zclass inheritance (acquisition?) would be nice... Am I missing something? Thanks, Alex. 1010011010101001101010100110101010011010 0 Digital Garage　デジタル車庫　:) 1 Alexander Schonfeld 0 alex(a)garage.co.jp - pear - 03-5454-7219 1 http://www.zope.ne.jp/ http://www.garage.co.jp

1 0

Re: [Zope] Thanks for the comments
by complaw＠hal-pc.org 12 Oct '00

12 Oct '00

Just out of curiosity, how often do you update the book (i.e., the version on the web)? Or, put another way, how long should we consider that catching a typo or split infinitive will have already been brought to your attention but hadn't yet made it to the web site? If you update on a continuous basis, then my question is moot. However, if you update on a periodic basis, could you drop me (or this list group) a note to indicate that the next version is available for our hungry eyes? Just a suggestions... Ron ./. > Just thought we'd mention that we have gotten lots of great comments on > the Zope book so far, especially in the last week or so. You're all > helping make it a better book and ensuring Zope's future. if you've > felt in the past that you may not be technically proficient enough to > contribute to the technology of Zope, you can certainly contribute to > the documentation by catching our mistakes and making good observations > and asking good questions. It is really, really helping. Keep it up, > cuz we're not done yet!

3 4

Re: Zope-Dev digest, Vol 1 #752 - 13 msgs
by Itai Tavor 12 Oct '00

12 Oct '00

James Johnson wrote: > > >2. I want to store a list of products, and give each one an >>arbitrary >>number of photos. I can use a Product ZClass, subclassed from >>ObjectManager and store Image objects inside it. > >Would using the new ZPatterns based EMarket-0.2.0a2 help as a base >system. I would also look at the updated information on SkinScript >located here. >http://www.zope.org//Members/pje/Wikis/ZPatterns/SkinScriptSyntax >I hope this helps. It's extremely helpful. I missed that SkinScript Wiki page, and I've been following the discussions about the ZPatterns-based EMarket but didn't realize it's been released. Thanks! -- Itai Tavor "Je sautille, donc je suis." C3Works itai(a)c3works.com - Kermit the Frog "If you haven't got your health, you haven't got anything"

1 0

Re: [Zope-dev] Strange permissions in the (built-in) API reference
by Michel Pelletier 11 Oct '00

11 Oct '00

Dieter Maurer wrote: > > Recently, I read the "Interface Wiki". It covers most of > the methods contained in the API and its permission descriptions > made a very solid impression. Maybe, you can start from these > descriptions. The Interfaces Wiki is actually where all the API documention did come from. Are there inconsistencies? > It might also not be optimal wrt. maintainability > that the modules, their classes and their methods with > the respective docstrings have been recreated > just for API documentation purposes. > Probably, it would be preferable to use the docstrings > and the method prototypes from the source directly. > You might still want to control with methods are described > in the API and in which order. > Personally, I would control this, too, inside the source > documentation (a la javadoc), but I can imagine that an > external configuration might be advantageous. Yes, there are pros and cons on both sides, and Amos, Jim and I had some long converstations about this very subject. We decided to go with seperate documentation instead of autogenerating it because: 1. An interface should be a contract, not just an artifact of the code. 2. Python, being without first class support for interfaces, has no clear way of spelling an interface of a class. 3. Jim is working on formal interface support for python and he's thinking hard about it, we definatly didn't want to think hard about it and then turn out we came up with a bad answer, the existing API docs are just that, docs, not interfaces. When format interfaces come about, API docs will probably be converted to that format. Thanks for the comments! -Michel

1 0

Better user management: Usership vs. Membership
by Jonas Juselius 11 Oct '00

11 Oct '00

Hello, I had a look at the Membership product, but I could not get it to work. It seems that the PortalMember ZClass in the PortalMembership Product inherits from _ZClass_for_LoginUser, which is no longer in the LoginManager... But actually I don't care... I tried to contact Bill about the Membership Prod, but he seems to be unreachable because his mail address doesn't work. I found many nice ideas in the Membership product, and I think it would really be a good idea to develop it further. Does anybody know about any recent developments or what the current status is? Is there going to be a new release soon, is anyone even working on the Membership product? I also looked in dev.zope.org, and found proposals about a new user management system for Zope. Does anybody know anything about this? What I would like, is to take the Membership product and turn it into a flexible 'Usership' product. This would mean simplifying the Membership by removing all the joining stuff and the like, and instead concentrate on building a nice user management environment for user admins (which need not necessarily be 'Manager'). Here is a list of things that I would like to see: * users would be able to log in via a nice login screen * users have user info attached to them, which they may or may not change * users can change their passwords * adding users is not automatic (the user manager adds and removes users) * possibility to automatically create properly protected home dirs for users * perhaps logging of user activity My main point is that I think most sites are not interested in Membership in a Portal or half-Portal sense, but would like to be able to set up a nice env for their content managers/designers and other users who just log in to access restricted info like on an intranet... One of my main concerns is that I'm wasting my time... Many of the underlying products for a better user management system are still evolving rapidly, and anything built on top of these, is likely to break many times. Also, since there has already been discussions about a new user system, someone might already be working on it, and have better ideas. I would also be interested in hearing what DC has to say, and what their plans are... Best regards, jonas -- And what is good, Phaedrus, And what is not--- Need we ask anyone to tell us these things? [ PGP public key: http://www.iki.fi/jonas/pubkey.asc ]

2 1

AttributeProvider and type information
by John Eikenberry 11 Oct '00

11 Oct '00

I just want to ask a couple quick questions... First, when using the AttributeProvider class you are pretty much required to subclass it to add methods for altering the values of the attributes. Basically I want to be sure I'm not missing something criticle as there don't seem to be any methods on the default dataskin class for this (as there are for propertysheets)... and it seems like there should be. Related to this is dealing with typing information like PropertySheets used (via the _properties attribute). Wouldn't make sense to keep the AttributeProvider consistent with this... instead of the simple Attributes list? Seems like the type information and other meta information would as useful for handling attributes on the dataskin as for propertysheets. -- John Eikenberry [jae(a)zhar.net - http://zhar.net] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin

1 0