[Zope3-dev] RE: [SpringCleaning07]

[Jeff Shell]

On 12/19/06, Stephan Richter <srichter at cosmos.phy.tufts.edu> 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