- Zope-Dev - Zope lists

ASP like Syntax for DTML...
by Josh Robb 08 May '00

08 May '00

On Page 3 of the DTML Language Reference there is the following cryptic comment. 1. It is also possible to define additional syntaxes, although the mechanism for doing this is not currently documented. For example, a syntax that is similar to the syntax used by active server pages has been developed. Does anyone know what this refers to.... I started developing a ASP like syntax myself but will got no further if the above is true. Josh P.S. Please CC me in on replies as I am not subscribed to zope-dev.

1 0

Off topic: who is mcfletch @ zope.org?
by Mike Fletcher 07 May '00

07 May '00

Just trying to join zope.org so I could work on the interfaces Wiki, and discovered there's already someone there by that handle. Was weird, wondering if I've encountered another Mike C. Fletcher, or if I somehow got attached to the site while not looking. Oh well, now I get to choose a secret identity :) . VRMan to the Rescue! __________________________________ Mike C. Fletcher Designer, VR Plumber http://members.home.com/mcfletch

1 0

Re: Alternative Storages: (was RelationalStorage (was LocalFS))
by Jerry Spicklemire 07 May '00

07 May '00

Important Safety Tip: If you haven't yet realized, it was the topic of creating a ZOPE Storage based on a file system (such as ReiserFS) that generated a now immortal cautionary note. In response to Jim Fulton's "assurance" that while conceptually possible, the task could prove "a tad tricky", http://lists.zope.org/pipermail/zope-dev/1999-December/002682.html to which Michel Pelletier replied, 'When Jim [Fulton] says "tricky" it means your brain could explode.' http://lists.zope.org/pipermail/zope-dev/1999-December/002701.html now also: http://starship.python.net/crew/amk/quotations/python-quotes.html Later, Jerry S.

1 0

Re: PPropertyHandlers
by Phillip J. Eby 07 May '00

07 May '00

At 04:59 PM 5/5/00 +0000, Jason Spisak wrote: > >Which brings me to ask what I can do to bring PropertyHandlers to a today >solution? Do you have a model that I try to cut my teeth on? Or would you >like me to just clam up and wait until you sort things out. :-) Here's something to play with. It's not tested yet, not even tried to compile it yet. But it should give a basic idea of how PropertyHandlers might be implemented. One would use it like this: class MyZopeObject(...): myPropertyA = BasicPropertyHandler( id='myPropertyA', attr='_A' title='First Property', readPerm='Access MyZopeObject data', writePerm='Configure MyZopeObjects', dataType='int' ) You could then in DTML call "someobject.myPropertyA.set(3)", or use "someobject.myPropertyA.editForm()" to slap in an input box on a properties form. To get the value of the property, just use <dtml-var myPropertyA> or <dtml-var "myPropertyA()"> on the object. To read the value, you would need "Access MyZopeObject data" permission, and to set it you would need "Configure MyZopeObjects" permission. These permissions should be included in your class's __ac_permissions__ or otherwise defined in the Product so that roles could be mapped to them. The value of myPropertyA would actually be stored in the "_A" attribute of MyZopeObject instances. Last, but not least, properties possessing titles makes it easier to make a form that just walks through an object's properties and displays a prompt (using the title attribute) and an input field (using the editForm() method). Anyway, here's the sample code that will probably be our basis for eventual implementation. It doesn't handle all of the property types ZPublisher supports, and it doesn't support anything that well. There is no concept (yet) of how one knows what properties an object has. But it does showcase permission management support. One could, with a fair bit of work, build from this base a full-fledged Zope object capable of being configured through-the-web and placed on the Methods tab of a ZClass. Enjoy. from Globals import default__class_init__ from Acquisition import Implicit from AccessControl.PermissionRole import PermissionRole dataFormats = {} class BasicPropertyHandler(Implicit): """Encapsulate set/get marshalling and HTML editing of a property""" def __init__(self, id, attr, title='', inputFormat=None, readPerm='Read properties', writePerm='Set properties', dataType='string'): self._Read_properties_Permission = readPerm self._Set_properties_Permission = writePerm self.id=id self.title=title or id self.attr_name = attr self.dataType = dataType if inputFormat: self.inputFormat = inputFormat else: self.inputFormat = dataFormats.get(dataType, '<input name="%(id)s:%(type)s" type="text" value="%(value)s">' ) def __call__(self): """Get the attribute value""" return getattr(self.aq_parent,self.attr_name) def set(self,value): """Set the attribute value""" # type conversion here?? setattr(self.aq_parent,self.attr_name,value) def editForm(self): """Return an HTML snippet for editing""" return self.inputFormat % { 'id':self.id, 'type':self.dataType, 'value': self() } __ac_permissions__ = ( ('Read properties', ()), ('Set properties', ('set','editForm')), ) # This is because we can't set roles on __call__ :( __roles__ = PermissionRole('Read properties') default__class_init__(BasicPropertyHandler)

2 1

Re: [Zope-dev] Object hierarchy in RIPP
by Kevin Dangoor 07 May '00

07 May '00

Thanks for all of the messages, Phillip. Hopefully, you'll succeed in getting ZPatterns 0.3.0 out the door tomorrow. Even if you don't, when it *does* come out there will probably be many more people that are ready to use it. ----- Original Message ----- From: "Phillip J. Eby" <pje(a)telecommunity.com> To: "Kevin Dangoor" <kid(a)kendermedia.com>; <zope-dev(a)zope.org> Sent: Thursday, May 04, 2000 11:31 AM Subject: Re: [Zope-dev] Object hierarchy in RIPP > At 10:59 AM 5/4/00 -0400, Kevin Dangoor wrote: > > I have a database of products, built from ZClasses. Products are bundled > >into groups for convenience of management, and the URL of a product is based > >on its SKU. So, we can have a product at products/1/5, and that would be the > >item 1-5. This direct traversal to a product object is very useful. The > >products are all indexed in a ZCatalog, and I do use acquisition to get at > >some useful things for displaying these products. > > If I were doing what you're doing, I'd use a Products "Specialist" (fka > Implementor). Specialists implement bobo_traverse by asking their enclosed > Racks for the item. They also have a methods tab for shared/acquired stuff. OK. *Now* I'm a lot clearer on how these things should be used. I didn't realize that the Specialists implemented bobo_traverse. I assume that one difference between the Rack and my existing set up is that if I have a Specialist called "products" and go to products/manage I'm not going to see the standard Zope management interface listing out the products. Correct? I understand that Racks are meant to solve some of the issues with having "too many" items in one Folder, in which case you wouldn't *want* the standard Zope management interface. If/when the API defines search methods, it might be nice to create a standard "management interface" for Racks that would let you add instances, search for instances and delete them. > The only bit I'm not sure about is your mapping of 1-5 to 1/5, which seems > to me to imply that you have another hierarchy level in there, which Racks > don't handle per se. If you have something like a ProductGroup object > going on in there, then I would have a ProductGroups specialist retrieve > the ProductGroup, whose bobo_traverse would ask the Products specialist to > retrieve the product, wrapped with the ProductGroup for acquisition. You're correct about the "ProductGroup" sort of thing. I will probably eliminate that, since it sounds like Racks will quite comfortably handle lots of items. I see the difference you're getting at, as well. So, I wouldn't try to stuff a Specialist into another Specialist or onto a Rack. The ProductGroups Specialist just asks the Products Specialist for a given item. Makes sense. > That's less than optimal, however. In a future version of ZPatterns, we > want to make it possible for RackMountables to live anywhere in the ZODB > "file system" and still add propertysheets, etc. Right now, they have to > live in a Rack because that's where the external data management is. You > could hack this pretty easily, however, by making your Folderish objects > bobo_traverse methods call _setRack on retrieved sub-objects, and pointing > them to the Rack which is designated for managing their external data. > That's sort of how we'll be implementing the extension anyway, only we'll > be doing it in a lot more complicated way involving __of__. :) I agree that this flexibility would be nice... But, I don't mind having to put things in Racks in order to be able to flexibly store information in the ZODB and RDBMSes. > By the way, all my comments refer to ZPatterns 0.3.0, which I hope to > release tomorrow. 0.2.0 doesn't have Specialists, for example. 0.3.0 > supports arbitrary persistent propertysheets, and has a well-fleshed out > API (compared to earlier versions, anyway) for creating attribute providers > and sheet providers. Excellent! Kevin

5 9

Re: [Zope-dev] ZPatterns 0.3.0 and LoginManager 0.8.5nowuploaded
by Michel Pelletier 06 May '00

06 May '00

"Phillip J. Eby" wrote: > > At 11:40 AM 5/6/00 -0700, Michel Pelletier wrote: > > > >Still looking at it, I will probably get a better chance to eye it after > >the release. > > > > What release? A ZPatterns release or a Zope release? Sorry, Zope. -- -Michel Pelletier http://www.zope.org/Members/michel/MyWiki Visit WikiCentral for the latest Zen: http://www.zope.org/Members/WikiCentral

1 0

Re: [Zope-dev] ZPatterns 0.3.0 and LoginManager 0.8.5 nowuploaded
by Michel Pelletier 06 May '00

06 May '00

"Phillip J. Eby" wrote: > > > I was in the process of setting up a ZPatterns wiki in my zope.org home, > but its focus is more on conceptual introduction to the patterns and how to > use them. But I don't suppose that interface docs would be out of place in > the interface wiki. :) This was my idea, general ZPatterns Wikish discussion should go somewhere else, all I want here are straight up definitions of the existing interfaces, looking at the code can be confusing because they include implimentation specific code and methods. > It appears that you've done some looking at the code; please do let us know > if you have any comments or spot any subtle misunderstandings on our part > of how the Zope framework is actually supposed to work. Still looking at it, I will probably get a better chance to eye it after the release. -Michel

2 1

Re: [Zope-PTK] [Zope-dev] ZPatterns 0.3.0 and LoginManager0.8.5 now uploaded uploaded
by Steve Alexander 06 May '00

06 May '00

"Phillip J. Eby" wrote: > > At 09:21 AM 5/6/00 +0100, Tony.McDonald(a)newcastle.ac.uk wrote: > > > >Both the packages expand into lib/python and (probably?) need to go into > lib/python/Products - at least that seems to be the case for ZPatterns (it > has -I../../ZODB -I../../../Components/ExtensionClass in the Setup file). > > Eeek. You're right. I even remember seeing Ty moving them into lib/python > to do the tarball and it didn't even occur to me. Yes, they both belong in > Products. I had to download Zope source to get ZPatterns 0.3.0 running. The ExtensionClass header files are not in the tarball linux binary version. It is great fun though! Just created my first Specialist :-) -- Steve Alexander Software Engineer Cat-Box limited

1 0

RE: [Zope-dev] Version -> Version Control System??
by Brian Lloyd 05 May '00

05 May '00

> How about writing a CVS client that is a Zope product? I'll buy it - when will you have it ready? :^) > > This would allow us to avoid > > reinventing wheels and possibly give us the side benefit of > > supporting Delta-V directly with trivial effort if their > > architecture seems like a good fit. > > If DeltaV works then cool, otherwise, CVS is very standard, > could work without > much effort (is there a Python CVS client?!) Last time I looked, Delta-V was very CVS-like in its core approach (really, all of the DAV initiatives are very files- and-directories-centric), at least in terms of basic concepts and its "interface" to the outside world. I'm not suggesting that anyone actually wait for DV - I was just pointing it out as a possibly good starting point for thinking about config. management in terms of the web. Some of their issues might be useful to think about in terms of how to plug CVS into Zope. Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

2 1

Re: [Zope-dev] Warning! TransparentFolders and ZClasses
by Jason Spisak 05 May '00

05 May '00

Shane Hathaway: > Jason Spisak wrote: > > Thank you for the heads up! I was going to mail you this morning anyway. > > What are the potential drawbacks to having all forlders be > > TransparentFolders? > > A reasonable question, but other than the fact that every object lookup > would look through every folder on the entire system, making Zope > entirely useless once you have more than a few objects, there are no > drawbacks at all. ;^) > Nasty pointy teeth. How is this different from having the 30,000 objects that I have in one of my instace folders? All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

5 11