On 12/19/06, Stephan Richter <[EMAIL PROTECTED]> wrote:
On Tuesday 19 December 2006 06:16, Roger Ineichen wrote: > > Here is a list of candidates for removal (please verify!):
I'm only commenting on the ones that I use, think have some use, or just have questions about.
> > zope.fssync +1
0 It's too bad that this seems to have gone unfinished. The biggest pain (well, one of the big pains) we experience with Zope 3 is the lack of anything like Zope 2's export/import. Or, going further back, 'manage_exportHack'. :). This is a side topic and I'm not going to elaborate further except to beg for some low to medium level export/import capability. It seems that fssync was one of the alternatives, or could be, if I recall correctly.
> > zope.modulealias +1, though I might think some people still use it. So we have to be careful.
0 Another side topic: even after cleaning out all deprecation warnings in our code to make it run under Zope 3.3, I still get deprecation messages bubbling up from the ZODB, claiming to come from ZODB's "broken.py". It dawned on me just yesterday that there are probably references to the deprecated/moved modules in our ZODB databases. I don't want Zope 3.5 to roll around and have our databases blow up because of permanent removal of the old 'zope.app' packages that have been moved to 'zope.*'. Is this a legitimate fear? Is there something we can do to repair these references? I don't know if zope.modulealias supports that or not.
> > zope.app.file -1, I use it all the time in combination with zope.app.image to have quick file support. This is acceptable, if you do not plan to store thousands of large documents. BTW, I would welcome a conversion to use blobs.
Also -1. We use zope.app.file quite a bit ourselves, for better or worse. I haven't seen any plausible alternatives. BTW: In my 3.3 release, I don't see 'zope.app.image', but I do see 'zope.app.file.image'. Is that what you meant? Or is there a 'zope.app.image' package that hasn't been included in the distribution? I believe that storing binary data in the ZODB - especially in content management situations - is of high interest to many. Doing it well, however, is the hard part. I think that the main Zope distribution should definitely provide helpful base classes and/or tools for storing and reading the data efficiently and easily. The current 'zope.app.file' code feels a bit scattered. Also important is good HTTP support for binary data. Additional Request / Response support for cache headers, 'If-Modified-Since', etc.
- zope.app.sqlscript This package has for me the same importance as zope.app.dtmlpage and zope.app.zptpage. It contains some nice code that shows how to use RDB connections correctly, but I doubt that anyone is seriously using them. SQLObject and ZAlchemy are just better options. I would leave it in the repository, but remove it from the core tree.
0 We use this, but in a strange way. We don't use sqlscript's like these in the ZODB, but use them on some classes, ala:: from zope.app.sqlscript.sqlscript import SQLScript class ECards(...): sql_search = SQLScript( CONNECTION_NAME, """ SELECT * FROM ecard WHERE <dtml-sqltest ecard_id column="ecard_id" op=eq type=string> """, 'ecard_id' ) But I want to move this code to our SQLAlchemy based system anyways. So, sqlscript could go and I wouldn't shed many tears.
- zope.app.undo Is anyone using this? I am certainly not. I think it can be removed. Phllip, you put a lot of work into it, what do you think? However, I think the code has a place in the repository, though there it runs in danger of quickly being outdated.
-1 We depend on it. We don't use any of the UI pieces that are in it, but we do use the IUndoManager utility. I think that having fairly easy access to 'undo' is important: it's one of the distinguishing features of the ZODB. We use it to provide an "undo last" feature. "Deleted 'foo' (undo)" (with 'undo' being a link), like you get with GMail. Heck, this could be a good pitch point or article for Zope development. "Ever wanted to do an easy-undo feature like you see in GMail? With the ZODB, FileStorage, and the Undo Manager utility, it's easy!" Without a suitable replacement utility or set of tools for finding / undoing historical transactions, I'm against losing this.
- zope.app.renderer You can safely remove it from the base tree. It was not such a big success as I was hoping for. Other approaches are easier. Note that wiki and bugtracker still use this code, so it should be still available for those packages.
-1 We use this *quite* heavily, with Textile and Markdown renderers in place as well. Many of our CMS customers are using this (although I hope to move them to HTML w/ TinyMCE or Kupu if I can ever get Kupu to actually do something useful). Our Knowledge Base application also uses zope.app.renderer. It's been invaluable to be able to move documents from Writeboard (Textile format) to our KBase for long term storage, as well as being able to post our own reStructuredText based documents. 'zope.app.renderer' is a bit confusing, but its disappearance could be critical. Again, I don't mind too much of it disappears from the core distribution, as long as it's made obvious (ie - not buried in a wiki page on some far flung remote site) and can be easily downloaded/installed.
I'll note that the removal of several of the zope.app.* packages means a further distancing from TTW, offering the casual newscomer even less to look at. I am okay with this direction, but others might object strongly. This should really be brought up on zope3-users or other high-level mailing lists.
I'm also for this. Besides, the casual newcomer can't really do much with the stock TTW objects anyways. For casual TTW style development with all of its features (and drawbacks), Zope 2 is a far better choice. Side Topic: When you install Pylons, you don't have anything to "look at". But making a quick and simple application with it was rather straightforward. On the other end of the spectrum is Django, whose admin screens are actually usable by other humans and very very easy to customize. How easy is it in Zope 3 to customize a folder contents view so that it shows different columns, allows sorting only on certain ones, and allows quick searching, grouping, and filtering? I know (or assume) that 'zc.table' can provide for this functionality, but it's nowhere near the core. As a developer, doing custom 'listing' or index pages is something I need to do all of the time. 'title', 'size', and 'modified' aren't interesting to me in a folder full of invoices. I would be interested to know if anyone has succesfully used the TTW ZPT Page and SQL Scripts or SQL Exprs to make a usable application. Those never seemed to be the focus of Zope 3, and with the lack of auto-acquisition and Python scripts, they felt extremely crippled compared to their Zope 2 cousins. I certainly could never get them to do anything useful, because I had no answers about what objects/namespaces/modules/etc I could even access. All of the things that were easy in Zope 2's TTW environment didn't seem doable in Zope 3's. But that's OK, as custom Python / product / etc development is much easier. I'd rather see the elevation and inclusion of tools like 'zc.table' and 'zc.resourcelibrary' which can be useful across so many application domains and could solve some very common problems. And if we want to give casual newcomers something to look at, lets focus on how Instance Homes and Products/Applications are used and can be built. Perhaps give templated starting points like paster does:: $ paster create --template=zope3product easytodo The Zope 3 experience does nothing to start the casual newcomer towards building a simple starter application. Both Pylons and TurboGears have a 'quick wiki' tutorial which includes a line similar to the one above. Unlike 'mkzopeinstance', the generated directories and files reflect a working product with some starter modules, classes, and templates: the equivalent of 'BoringProduct', in a sense, but with some skeleton parts (class names, etc) filled in instead of having to be manually replaced. -- Jeff Shell _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com