In CVS at least (and maybe in stable revs?), Jim F. provided the capability to store external methods within a Product directory's 'Extensions' directory, referenced by an external method in a module with the name "ProductName.ModuleName". So if you've got an extension directory that has lots and lots of external methods from lots and lots of Products, you can break them up and store them in their respective product Extension dirs.
-----Original Message----- From: jpenny@universal-fasteners.com [mailto:jpenny@universal-fasteners.com] Sent: Friday, April 14, 2000 3:06 PM To: zope-dev@zope.org Subject: [Zope-dev] Extensions directory
Background: I find that I am writing quite a bit of External python code that is quite task specific; probably far too task specific to try to package. For example, I have an (internal only) page that shows part consumption on a per machine basis. There are hundreds of machines, and thousands of parts, so the graphs must be produced dynamically.
This is pretty easy to do. (I use ploticus, a great open source tool, http://www.sgpr.org/.) But I can see, down the road, being requested to produce many different sorts of graphs. And since the data stream will have differing types and number of arguments, it is not clear that it would be easy to write a Product, even if I had the inclination.
But, I hate to have many scripts in a single flat directory. This can be both a mess to maintain and can slow things down on some file-systems.
So, is there any strong reasons that the Extensions directory needs to be flat (i.e. not have subdirectories)?
Jim
_______________________________________________ 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 )