Jonothan, I'm trying to do the following to create a folder in a localFS object if it isn't there: <dtml-if "not localFSobject.fileIds(folderNameVar)"> <dtml-call "localFSobject.manage_addFolder(folderNameVar)"> <dtml-else> Folder exists... </dtml-if> The problem is that this creates the folder in the folder containing the localFS object, not in the localFS object. I think I agree with Stephan Richter, that this is because the localFS object doesn't have a manage_addFolder method and so aquisition causes it to get executed on the folder containing the localFS object. Fair enough, so how do I do what I want to do? The frustrating thing is that, through the management interface, I can do exactly what I want in exactly the same way I'd do it with any other folder: add folder -> fill in form -> hit button. This suggests that I should be able to do an add folder in the same way programatically as I would for a normal folder. So: 1. Would the above work if localFSobject was a normal folder (ie is my method screwed in the first place ;-) 2. How should I be doing what I'm trying to do, with a local FS object? Many thanks, and it's still an amazing product even with these little niggles (which I'd guess are more my fault for not knowing how to do what I want to do, even on a normal folder ;-) Chris

LocalFS does not make use of the standard ZODB manage methods. It has its own methods to do everything. I once discussed that with Jonothan (the coder of Local FS) and he thinks (if I understood him correctly) that for some reasons it is inappropriate to make use of these methods, since the objects contained in LocalFS really do not exist in the ZODB nor have a similar state.

Well, I've been pretty hard-headed about not implementing the objectValues family of ObjectManager methods in the LocalDirectory object because it solves some very specific problems. Other than that I strive to reuse existing Zope interfaces, logic, and code as much as possible. The basic explanation for this problem is this. The manage_addFolder is an attribute of the Folder module. Just about every built-in Zope object and add-in product implements its own set of manage_addXXX methods. It would be prohibitive for me to try to duplicate them all in the LocalFS product. The Zope machinery actually adds all of these methods to the Folder object when it loads all of the products. I can't use the same technique because I don't know which order my product will be loaded in relation to the other products. The reason you can add folders using the management interace is because the LocalDirectory object implements _setObject. Here's basically what happens: - You select the Folder option from the Add form on the management screen. - This calls the manage_addProduct method of the LocalDirectory object with the value of "OFSP/folderAdd" (view source on the management screen to see how this is done). - manage_addProduct is technically not a method, it is a ProductDispatcher class instance, which is is implemented in App/FactoryDispatcher.py. The ProductDispatcher works its magic which basically redirects you to the folderAdd DTML method, which is implemented in OFS/folderAdd.dtml. - You submit the form, whose action is manage_addFolder. This manage_addFolder is an attribute of the Folder object that contains the LocalFS object. However, the 'self' argument passed to the method is the LocalDirectory object. - manage_addFolder creates a new Folder object and calls self._setObject to add it to 'self'. - This calls the _setObject method of the LocalDirectory object, which sees that the meta-type of the object is 'Folder', so it creates a directory in the local file system and all that jazz. The reason your DTML method doesn't work when it calls manage_addFolder is because the method is acquired from the containing folder, as you suspected, and because when manage_addFolder is called, the 'self' parameter is also the containing folder, so the call to self._setObject adds the new folder to the Folder object instead of the LocalDirectory object. The self parameter is passed automagically by the Zope machinery, and is not affected by using dtml-with. If you ask me, this is one of several serious problems with the current dtml-with implementation. Whew. Now that I've explained more than you ever wanted to know about the workings of the LocalDirectory management interface, here's a workaround: implement your dtml method as a local file with a .dtml extension and put it in the directory where you want to add files. Unfortunately, this will only allow you to add files to that directory. A better fix is to write an external method. Example: from OFS.Folder import Folder def addFolder(self, id, title=''): ob = Folder() ob.id = id ob.title = title self._setObject(id, ob) Then from DTML use: <dtml-call "addFolder(localFSobject, folderNameVar)"> Sorry if that was more information than you needed. Hope this helps you solve your problem. --jfarr

Jonothan, Is there an easy way to use your LocalFS product to point to ZDB instead? I want to be able to download and upload to Zope Web site easily, is this possible with your product? Thanks, Luis.

Hi, Jason I agree that RIPP, and the ability to use ZClasses as Pluggable Brains for SQL Methods, will make a big difference in making underlying storage transparent. I'm trying to incorporate RIPP into my thought patterns as I design new apps so that I can take advantage of multiple backend stores for things. My plan for this is that I would store things that do not require frequent writing in the ZODB. I think the ZODB is very easy to work with and pretty fast. For things that do need frequent writing, I would give those objects a separate propertysheet for those attributes and store them in an RDBMS. I think this would be a really clean, maintainable and scalable model. The nice thing about this also is you could always start with a full ZODB implementation of those attributes and then migrate to RDBMS later on. Would I be able to implement this today? Nope, I don't have enough ZPatterns and propertysheets Zen yet. But, I think it looks like a great way to go. BTW, when I say "frequent writing" above, I should really say "frequent updating". I think a discussion area would be just fine to store in the ZODB, because objects keep getting added, not updated. On the other hand, keeping track of banner ad views should be done in some other data storage area (RDBMS, file system). Kevin ----- Original Message ----- From: "Jason Spisak" <444@hiretechs.com> To: "Jonothan Farr" <jfarr@real.com> Cc: <zope@zope.org> Sent: Tuesday, May 02, 2000 1:26 PM Subject: [Zope] Local FS

How far away from being an alternative form of storage for Zope is LocalFS? I'm talking ZClass instances mostly. A robust data storage facility for Zope objects in files rather than a sigle large file. With the RIPP (ZPattern and the like) the backend is going to cease to make a difference to propertysheets, and having the local filesystem (XFS/ReiserFS) for write intensive stuff is a must have for Zope.

----- Original Message ----- From: "Jason Spisak" <444@hiretechs.com> To: "Kevin Dangoor" <kid@kendermedia.com> Cc: <zope@zope.org> Sent: Tuesday, May 02, 2000 2:37 PM Subject: Re: [Zope] Local FS

I have a question for Phillip Eby and Ty Sarna. Is there going to be a migration path for translating existing data stored in traditional propertysheets to the ZPatterns framework? Everyone is using propertysheets at some level right now, and many of us are using them to store isntance data in a hefty amount.

I'm not Philip or Ty, and I don't play them on TV, but I thought I'd speak up anyway :) ZPatterns, as far as I can tell, is really *just* a framework. I don't say that to lessen Philip and Ty's contribution, because it looks like a great framework. But, I think the idea is that the framework doesn't necessarily provide all sorts of really high level features. I think the idea is that you can use these design patterns in your own designs to make your code more flexible. I think everyone's requirements will be different and a generic solution will be difficult. I think it more likely that if you're migrating from having a particular propertysheet stored in the ZODB to storing it in an RDBMS or in the file system, you'll probably need to whip up a PythonMethod or something to migrate the data. It's really not very difficult... (Anecdotal evidence: the articles on Byproducts.com came into existence before ZClasses. They were stored as Folders with various properties. Then, ZClasses came along and I wrote KM|net News. I believe I used a DTML method to pull the data from the Folder objects and create new KMArticle objects. It wasn't very difficult, and I expect to do the same thing any time I make a significant shift in storage methods...) Kevin

On 2 May 2000 14:15:02 -0500, Jason Spisak wrote:

Jonothan:

I'm not sure if you have been folowing the thread between Michael B. and myself, but I would love your insight.

How far away from being an alternative form of storage for Zope is LocalFS? I'm talking ZClass instances mostly. A robust data storage facility for Zope objects in files rather than a sigle large file. With the RIPP (ZPattern and the like) the backend is going to cease to make a difference to propertysheets, and having the local filesystem (XFS/ReiserFS) for write intensive stuff is a must have for Zope.

Just wondering what your opinion on it is.

As long as the data is *only* changed from inside Zope, it shouldn't be a large problem. I wrote a few dumb 'LocalFS'-type file-system products which are queryable (and mineable) and also return ZRDB Results objects, including a couple of folderish directory classes which can be easily walked via dtml-tree. However, there is a big problem with object caching if you plan on a: caching and b: updating via the filesystem. I never did figure a way around those problems.

Jason Spisak wrote:

Kent Polk writes:

...

On 2 May 2000 14:15:02 -0500, Jason Spisak wrote:

...

How far away from being an alternative form of storage for Zope is LocalFS? I'm talking ZClass instances mostly. A robust data storage facility for Zope objects in files rather than a sigle large file. With the RIPP (ZPattern and the like) the backend is going to cease to make a difference to propertysheets, and having the local filesystem (XFS/ReiserFS) for write intensive stuff is a must have for Zope.

Just wondering what your opinion on it is.

As long as the data is *only* changed from inside Zope, it shouldn't be a large problem. I wrote a few dumb 'LocalFS'-type file-system products which are queryable (and mineable) and also return ZRDB Results objects, including a couple of folderish directory classes which can be easily walked via dtml-tree. However, there is a big problem with object caching if you plan on a: caching and b: updating via the filesystem. I never did figure a way around those problems.

Hmmm. Interesting. I am looking into implementing the RIPP model first in a system, then allowing the backend source to be more write intensive for instances. The Multiple ZODB files seems like a very back burner type issue. It was moved over to zope-dev as well.

If I still end up pursuing a fs-based object storage mechanism or even fs-sourced object caching (objects are built from fs info but not directly stored therein), I suspect it will be done as a separate server. I don't quite see how to get around the problems and having a separate server offers some interesting possibilities. Heck, the alternate server might even be a separate zserver... For my fs-based table objects I am still considering using the backend table methods that the new version of Gadfly is supposed to provide. Lose some object capabilities but gain some sql ones... My problem is that the tables are modified externally from zope so either I can cache the table objects or I can allow them to be updated outside of the filesystem, but not both. It sounds a bit like what you want can be handled entirely from Zope once the fs objects are loaded into the zodb, so it might be ok to only allow updates via zope unless you are willing to restart the zope server.