[OPINIONS SOLICITED] Adding Batch Factory to ZMI "Add" menu OK?
Hello: I am about to release a new version of the ExternalFile and CVSFile products http://www.zope.org/Members/arielpartners/ExternalFile They are Zope objects that behave like standard Zope objects but retrieve their content from files anywhere in the file system. (kind of like a windows shortcut or UNIX symbolic link) I would like to include a way to automatically create an instance for every file within a directory: a "batch" flavor. Previously, one would have to select "ExternalFile" from the "Add" menu in ZMI for each and every file, one at a time. For large directories, this is a major pain. The way I have implemented this is to create a new "pseudo object" -- basically a factory for creating batches of ExternalFiles: "ExternalFileBatch" You select "External File Batch" from the "Add" menu in ZMI and you get a form that allows you to specify the directory. Here is the code for ExternalFileBatch.py: def manage_batch_add(self, target_dir, basedir='', REQUEST=None): """ Factory method to actually create a batch of instances of ExternalFile. """ message = "<h2>External File Batch Create Results:</h2>" try: filelist = dirlist(os.path.join(basedir,target_dir)) if len(filelist) == 0: message = message + "No files found." for fileid, filepath in filelist: message = message + "Object instance '" + \ fileid + \ "' successfully created, pointing to file: " + \ filepath + "<br/>" self._setObject(fileid, ExternalFile(fileid, '', '', filepath)) self._getOb(fileid).reindex_object() except OSError, e: message = message + str(e) return MessageDialog(title = 'results', message = message, action = 'manage_main') ################################################################ # ExternalFileBatch class ################################################################ class ExternalFileBatch: """ ExternalFileBatch is a factory for creating instances of ExternalFile a batch at a time """ meta_type = 'External File Batch' As you can see, ExternalFileBatch is not much of a class. It is really just a Factory for creating instances of another class, namely ExternalFile. An alternative would have been to create an additional tab in the ZMI for Folders which allows you to create instances of ExternalFile. I could do this by monkeypatching Folders, or by creating an ExternalFileFolder class. There are advantages and disadvantages either way. I don't like ExternalFileFolder b/c ExternalFiles are not supposed to be anything special. The whole point is to be able to use them in ANY context in which you would use a standard Zope object. Thoughts? --Craeg
Hello Craeg I particularly prefer the factory aproach. Zope users are already used to that approach because of the Z Search Interface. I think you shouldn't need a dummy class just to be able to create such a factory, but right now I don't know how you'd go about creating a factory without a class. As for an ExternalFileFolder, it would be useful if it automatically created objects when they are added to the respective directory (automatically as in, it checks for new objects when you look at the object list (manage_main), or when you try to access a previously inexistant (sp.) object. Although, because of Data.fs write-on-read concerns, you might want this automation to be configurable on a folder by folder basis). An ExternalFolder might also provide a view or tab to configure default attributes of newly discovered objects. The objects created this way would obviously be regular ExternalFile objects, and you could copy/cut and paste them outside of the ExternalFileFolder object. Cheers, Leo On Mon, 2002-05-27 at 17:32, Craeg K Strong wrote:
Hello:
I am about to release a new version of the ExternalFile and CVSFile products
http://www.zope.org/Members/arielpartners/ExternalFile [...]
-- Ideas don't stay in some minds very long because they don't like solitary confinement.
My current project is a product called ZFS and I just got an initial beta working last night and since this project came up. Essentially im hoping this can be a replacement for LocalFS and all External* products. But this sounds very similar to your work... ZFS is folderish object that points to a file system and hacks the storage level of Zope so that when an object is saved, part of it is "diverted" to the file system. Meaning the "textarea" part of a DTML Document is saved to the file system. Because it hacks the storage level, this object appears to be a normal object (so you can do all the usual things to, for example pasting it from ZFS to a normal folder means it becomes a normal object. This approach has many advantages and I hope to be able to allow all standard objects (DTML *, Python Scripts, Images, Files) to work in this manner. If running in debug mode, it syncs automatically to the file system, meaning you can create and edit objects on the FS and they sync straight into Zope. If in production mode, you call it manually to update, thus getting much better performance. You obviously lose some features (Undo) and there are still many issues to be fixed, but I need to get it done so expect a release soon. On 27/05/02 18:38 -0300, Leonardo Rochael Almeida wrote: > Hello Craeg > > I particularly prefer the factory aproach. Zope users are already used > to that approach because of the Z Search Interface. I think you > shouldn't need a dummy class just to be able to create such a factory, > but right now I don't know how you'd go about creating a factory without > a class. > > As for an ExternalFileFolder, it would be useful if it automatically > created objects when they are added to the respective directory > (automatically as in, it checks for new objects when you look at the > object list (manage_main), or when you try to access a previously > inexistant (sp.) object. Although, because of Data.fs write-on-read > concerns, you might want this automation to be configurable on a folder > by folder basis). An ExternalFolder might also provide a view or tab to > configure default attributes of newly discovered objects. The objects > created this way would obviously be regular ExternalFile objects, and > you could copy/cut and paste them outside of the ExternalFileFolder > object. > > Cheers, Leo > > On Mon, 2002-05-27 at 17:32, Craeg K Strong wrote: > > Hello: > > > > I am about to release a new version of the ExternalFile and CVSFile products > > > > http://www.zope.org/Members/arielpartners/ExternalFile > > [...] > > -- > Ideas don't stay in some minds very long because they don't like > solitary confinement. > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > 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 ) -- Andy McKay
Would it not be possible to have undo for the Zope portion of the object meaning what is stored in in the ZODB can be undone, what is stored in the fs is as it is. Like that we would have most of what undo offers for a normal element. Robert ----- Original Message ----- From: "Andy McKay" <amckay@merlintechnologies.com> To: "Leonardo Rochael Almeida" <leo@hiper.com.br> Cc: <zope-dev@zope.org> Sent: Tuesday, May 28, 2002 6:45 PM Subject: [Zope-dev] Re: Adding Batch Factory to ZMI "Add" menu OK?
My current project is a product called ZFS and I just got an initial beta working last night and since this project came up. Essentially im hoping this can be a replacement for LocalFS and all External* products. But this sounds very similar to your work...
ZFS is folderish object that points to a file system and hacks the storage level of Zope so that when an object is saved, part of it is "diverted" to the file system. Meaning the "textarea" part of a DTML Document is saved to the file system. Because it hacks the storage level, this object appears to be a normal object (so you can do all the usual things to, for example pasting it from ZFS to a normal folder means it becomes a normal object. This approach has many advantages and I hope to be able to allow all standard objects (DTML *, Python Scripts, Images, Files) to work in this manner.
If running in debug mode, it syncs automatically to the file system, meaning you can create and edit objects on the FS and they sync straight into Zope. If in production mode, you call it manually to update, thus getting much better performance.
You obviously lose some features (Undo) and there are still many issues to be fixed, but I need to get it done so expect a release soon.
On 27/05/02 18:38 -0300, Leonardo Rochael Almeida wrote: > Hello Craeg > > I particularly prefer the factory aproach. Zope users are already used > to that approach because of the Z Search Interface. I think you > shouldn't need a dummy class just to be able to create such a factory, > but right now I don't know how you'd go about creating a factory without > a class. > > As for an ExternalFileFolder, it would be useful if it automatically > created objects when they are added to the respective directory > (automatically as in, it checks for new objects when you look at the > object list (manage_main), or when you try to access a previously > inexistant (sp.) object. Although, because of Data.fs write-on-read > concerns, you might want this automation to be configurable on a folder > by folder basis). An ExternalFolder might also provide a view or tab to > configure default attributes of newly discovered objects. The objects > created this way would obviously be regular ExternalFile objects, and > you could copy/cut and paste them outside of the ExternalFileFolder > object. > > Cheers, Leo > > On Mon, 2002-05-27 at 17:32, Craeg K Strong wrote: > > Hello: > > > > I am about to release a new version of the ExternalFile and CVSFile products > > > > http://www.zope.org/Members/arielpartners/ExternalFile > > [...] > > -- > Ideas don't stay in some minds very long because they don't like > solitary confinement. > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > 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 )
-- Andy McKay
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
participants (4)
-
Andy McKay -
Craeg K Strong -
Leonardo Rochael Almeida -
Robert Rottermann