-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:

--On 24. März 2006 16:20:07 -0500 jpenny@ykksnap-america.com wrote:

...

I don't particularly care one way or the other about ZClasses.

However, I would like to see FileSystemSite made part of the base distribution.

AFAIK FileSystemSite is something CMF-ish..so it does not belong to the Zope core.

- From the tarball in the Debian package[1]: FileSystemSite This is a repackaging of the CMF's FileSystem Directory Views such that it is independent of the CMF. This is basically like Chris McDonough's StandaloneSkins package[2]. [1] http://packages.debian.org/testing/web/zope-filesystemsite [2] http://www.plope.com/Members/chrism/standalone_skins/newsitem_view Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEJYhu+gerLs4ltQ4RAvOyAKC2oycfK1aJR1tJPWVyUBM6+NnT2wCeOvu9 dl63SEAGswhcOT8m4NI61PU= =NtDw -----END PGP SIGNATURE-----

Andreas Jung wrote:

CMF or not - if one need such a functionality one can download CMF or a related product. If such functionality should belong into the core than it should be implemented in a reusable way and frameworks like CMF should be build on top of it. So -1 for the request.

Indeed, I'm -1 on FileSystemSite, but it'd be _great_ to see the DirectoryView stuff move from the CMF into the core. That way we'd stop having several different implementations that newbies are forced to pick from. CMF could indeed then move onto using this... Where should I raise an issue? CMF or Zope collector? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

Tres Seaver wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Chris Withers wrote:

...

Andreas Jung wrote:

...

CMF or not - if one need such a functionality one can download CMF or a related product. If such functionality should belong into the core than it should be implemented in a reusable way and frameworks like CMF should be build on top of it. So -1 for the request.

Indeed, I'm -1 on FileSystemSite, but it'd be _great_ to see the DirectoryView stuff move from the CMF into the core.

I don't get what you mean: FilesystemSite *is* a separate packaging of the DirectoryView /FS{DTMLMethod/PythonScript/PageTemplate/SQLMethod} stuff, without any CMF dependencies.

It forked from an old version of CMF some time back but has not kept up with the changes in CMF. Thus it is not compatible right now. For eg. [Default] vs.[default] in the .metadata files and many more minor annoyances :) -- Thank you and Cheers, Suresh V. CTO, ParTecs, Bangalore http://www.partecs.com Plone-Zope-Python Consulting

Chris Withers wrote:

Andreas Jung wrote:

...

CMF or not - if one need such a functionality one can download CMF or a related product. If such functionality should belong into the core than it should be implemented in a reusable way and frameworks like CMF should be build on top of it. So -1 for the request.

Indeed, I'm -1 on FileSystemSite, but it'd be _great_ to see the DirectoryView stuff move from the CMF into the core.

That way we'd stop having several different implementations that newbies are forced to pick from.

Maybe its just me but I personally dont like direct filesystem access in the core - if someone wants it, (s)he can pick from the 3rd party products - maybe there can be a list of recommended (active maintained) products? Direct access products should also carry some easily understandable warnings. Regards Tino

OK, sorry about raising an issue that I was not around to comment on. First, there seems to be a good deal of confusion on what FileSystemSite or the DirectoryView portions of CMF are. They are simply a way to have Zope2 programmatic content stored directly on the filesystem, including dtml, page templates, python scripts and zsql methods, among others. FileSystemSite does not allow "filesystem access" in the usual sense, access is read-only; objects cannot be created on the filesystem through ZMI. Arbitrary filetypes cannot be easily stored on the filesystem at all (In fact I have no interest in that, I can always store such files in Apache-space.) This, or the CMF version, or something like it should be included because it is a large step up from pure TTW development in that it makes using conventional OS-level tools easier, including revision control systems and editors. It also gets the job done without all the effort of zope2 python based products. While products are important, and indeed, at this point the zope3 way, they don't scale down very well; and for one-off, will never meet the external world, systems; they represent a lot of wasted motion. FilesSystemSite and DirectoryView represent a "middle way" between pure TTW and pure file-system development. This is an idea that has come up at least three times, Ape was partially inspired by it, the CMF suite has such components, and it was thought to be worthwhile to pull out of CMF. CMF is a lot of overhead to pull in just to get DirectoryView, and exactly what to install to get DirectoryView and as little else as possible installed is not documented. In fact, neither is very well documented. I don't care whether DirectoryView, or FileSystemSite, or yet another implementation is blessed. However, the idea of permitting all programmatic content to be stored directly on the filesystem has merit and has been developed multiple times. It is an option that belongs in zope2 core. Note: if one is chosen, I will write a draft of a chapter for the "Zope Book" for the blessed implementation. jim penny zope-dev-bounces@zope.org wrote on 03/26/2006 09:56:01 AM:

Tino Wildenhain wrote:

...

Maybe its just me but I personally dont like direct filesystem access in the core - if someone wants it, (s)he can pick from the 3rd party products - maybe there can be a list of recommended (active maintained) products? Direct access products should also carry some easily understandable warnings.

I can understand that point of view for products that allow writing to the filesystem, but, conceptually, what's the difference between read-only "filesystem access" and a standard filesystem product?

None, I think, but then I may have misunderstood the purpose of FileSystemSite, and friends.

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