Hi, I try to connect ZPT to my local Filesytem. Previouesly I used localFS and DTML which worked nicely. But according to an earlier post by Dieter I learned that I should use DirectoryView from the CMFCore now. But thats not so easy as I found. Does the registration have to be done on every serverstart again? (How to automate it if so?) How to add new extensions and metatypes? Up to now I succeeded to register an arbitrary Directory on my local FS and different MetaTypes with the external Method given below. But a corresponding klass has to be given for the registration. How to do that using classes like the 'FSObject' return bad file error when I try to view the object in ZMI. Does anybody know about that? (Or how to use local FS under ZPT?) -- many thanks for your replies, Elena the code: from Products.CMFCore import FSObject from Products.CMFCore import DirectoryView DV=DirectoryView def registerLocalDir (my_dir='my_absolute_FS_path', prefix="", extList=['css', 'js'], metaList=['Style Sheet'], subdirs=0): DV.registerDirectory(my_dir, prefix, subdirs) klass=FSObject for ext in extList: DV.registerFileExtension(ext, klass) for mt in metaList: DV.registerMetaType(mt, klass) return
Elena Schulz wrote at 2002-12-30 15:00 +0100:
I try to connect ZPT to my local Filesytem. Previouesly I used localFS and DTML which worked nicely. But according to an earlier post by Dieter I learned that I should use DirectoryView from the CMFCore now. I did not say, you *should* but you might...
An alternative would be to extend LocalFS such that it recognizes PageTemplates.
But thats not so easy as I found. Does the registration have to be done on every serverstart again? (How to automate it if so?) Yes, it does.
It is automated by defining a product (or using one that already exists) that does the registration (e.g.) in its "__init__.py"
How to add new extensions and metatypes? You use either "registerFileExtension" or "registerMetaType". Look at "CMFCore/FSSTXMethod.py" for examples.
Up to now I succeeded to register an arbitrary Directory on my local FS and different MetaTypes with the external Method given below. But a corresponding klass has to be given for the registration. How to do that using classes like the 'FSObject' return bad file error when I try to view the object in ZMI. Maybe, because it is the abstract base class. Try "FSFile" or "FSImage" (or whatever other type you need).
Dieter
Hi Dieter, thanks a lot for your reply. I found how they did the registration for fixed directories in the __init__.py's, but how to do it for directories that will be arbitrary? How would one remember them and read them in the _init__.py of a product. But for the extensions is it either "registerFileExtension" or "registerMetaType", not both? I thought you would have to register a list of extensions for every new metatype? And to make them persistent they have to be registered the same way on every serverstart I guess? By the way wouldn't it have been much better and not so much more work to have implemented a general purpous persistent DirectoryView than just a limited one for CMF? I think to keep the data.fs slim and for other applications it is a very useful enhancement of Zope (and improvement over localFS). As a newbie in generating products I don't want to start with such a project. -- many thanks for your replies again, Elena
Elena Schulz wrote at 2003-1-3 09:47 +0100:
I found how they did the registration for fixed directories in the __init__.py's, but how to do it for directories that will be arbitrary? They can be arbitrary but they can not be modified/defined "through the Web". You must change something in the file system.
You can have a general "__init__.py" that registers all directories it finds by some means (e.g. via a configuration file). Also, note, that with one directory all subdirectories can also be accessed.
How would one remember them and read them in the _init__.py of a product. This, too, would be possible. But I do not know whether you should go this way.
When you really want, you can search for a product that provides for configurable startup scripts. It allows you to put scripts in a special Zope folder that are called automatically when Zope starts. I forgot the name of this product...
But for the extensions is it either "registerFileExtension" or "registerMetaType", not both? It is usually "registerFileExtension" and not "registerMetaType".
I thought you would have to register a list of extensions for every new metatype? And to make them persistent they have to be registered the same way on every serverstart I guess? Yes.
The same said for directories above applies for file extension.
By the way wouldn't it have been much better and not so much more work to have implemented a general purpous persistent DirectoryView than just a limited one for CMF? Maybe.
"DirectoryView" has just been implemented for the CMF. That we use it outside was probably not forseen...
I think to keep the data.fs slim and for other applications it is a very useful enhancement of Zope (and improvement over localFS). As a newbie in generating products I don't want to start with such a project. Then you will need to wait until someone else modifies "DirectoryView" to work somehow like "LocalFS".
It would probably be difficult but most people can probably live with "DirectoryView" as it is now... Dieter
Hi Dieter and Sean, I checked the version of Kapil which also needs the registration of a directory in advance. But if I need it too eargently I'll have to develop my skills to get it done .). Maybe on top of Kapils product.
You can have a general "__init__.py" that registers all directories it finds by some means (e.g. via a configuration file).
So the roadmap would be to get the directory and extensions from a zmi-form, register them, write all generated dirViews and extensions to a configfile and read them by the __init__.py, I guess.
Also, note, that with one directory all subdirectories can also be accessed.
From the source I found that there is a flag to controll this.
I would like to extent the product in another direction too. How could properties be added like to normal Zope-objects. Would it be a big deal to achieve that? -- many thanks for your replies, Elena you wrote:
Elena Schulz wrote at 2003-1-3 09:47 +0100:
I found how they did the registration for fixed directories in the __init__.py's, but how to do it for directories that will be arbitrary? They can be arbitrary but they can not be modified/defined "through the Web". You must change something in the file system.
You can have a general "__init__.py" that registers all directories it finds by some means (e.g. via a configuration file).
Also, note, that with one directory all subdirectories can also be accessed.
How would one remember them and read them in the _init__.py of a product. This, too, would be possible. But I do not know whether you should go this way.
When you really want, you can search for a product that provides for configurable startup scripts. It allows you to put scripts in a special Zope folder that are called automatically when Zope starts. I forgot the name of this product...
But for the extensions is it either "registerFileExtension" or "registerMetaType", not both? It is usually "registerFileExtension" and not "registerMetaType".
I thought you would have to register a list of extensions for every new metatype? And to make them persistent they have to be registered the same way on every serverstart I guess? Yes.
The same said for directories above applies for file extension.
By the way wouldn't it have been much better and not so much more work to have implemented a general purpous persistent DirectoryView than just a limited one for CMF? Maybe.
"DirectoryView" has just been implemented for the CMF. That we use it outside was probably not forseen...
I think to keep the data.fs slim and for other applications it is a very useful enhancement of Zope (and improvement over localFS). As a newbie in generating products I don't want to start with such a project. Then you will need to wait until someone else modifies "DirectoryView" to work somehow like "LocalFS".
It would probably be difficult but most people can probably live with "DirectoryView" as it is now...
Dieter
On Sat, 4 Jan 2003 14:12:50 +0100 "Elena Schulz" <elena.schulz@gmx.net> wrote:
Hi Dieter and Sean,
...
I would like to extent the product in another direction too. How could properties be added like to normal Zope-objects. Would it be a big deal to achieve that? ...
newsitem_view.pt.properties newsitem_view.pt.properties Works for the CMF, haven't tested for FileSystemSite. __Janko
Elena Schulz wrote at 2003-1-4 14:12 +0100:
I checked the version of Kapil which also needs the registration of a directory in advance. But if I need it too eargently I'll have to develop my skills to get it done .). Maybe on top of Kapils product.
You can have a general "__init__.py" that registers all directories it finds by some means (e.g. via a configuration file).
So the roadmap would be to get the directory and extensions from a zmi-form, register them, write all generated dirViews and extensions to a configfile and read them by the __init__.py, I guess. No.
When you really want to make "DirectoryView" work similar to "LocalFS", this variant will no longer require registration of directories (and maybe neither extensions). The registration only provides for a drop down box when you add a new DirectoryView (and as a cache). For your own variant, you would take the directory pathname directly from a property and store the directories content in a volatile attribute of the instance (or a module cache; do not forget syncrhonization, in this case).
Also, note, that with one directory all subdirectories can also be accessed.
From the source I found that there is a flag to controll this.
I would like to extent the product in another direction too. How could properties be added like to normal Zope-objects. Would it be a big deal to achieve that? It would when you want to do that through the ZMI. It would probably not be difficult when the properties were defined in the file system (you would simply combine the object and an "FSPropertySheet" object).
Dieter
participants (3)
-
Dieter Maurer -
Elena Schulz -
Janko Hauser