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
> 


_______________________________________________
Zope maillist  -  Zope@[...].org
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )