[Zope] Planning advice

[Charlie Reiman]

I've been working with Zope for a few months now and I'm not really thrilled
with what I've got. I have a functioning website and it works and does what
I want but I can already see that moving forward is going to be unpleasant.
As an engineer this bugs me and I need to evaluate the situation and
determine: is it me or is it Zope?

The project has two major goals.

First, to create a data reporting site. It's a straightforward display of
SQL data as tables. Nothing super-fancy but there are style issues and
there's quite a number of reports, all different, and date ranges, etc...
Lots of minor issues. The only tricky part is the reporting system needs to
support multiple customers, ideally off of the same URL, each seeing
different data.

The second part is trickier. Each client may have custom or hidden reports
and I need to be able to maintain this stuff. Ideally, I won't be
maintaining and customizing this, as I'm expensive. A cheaper webmonkey (who
is a fully actualized human to whom I intend no disrespect by calling a
"webmonkey") will be doing the customization and maintenance. In object
parlance, I customer's reports would be subclasses of a generic reporting
class, adding and removing functionality as needed.

What exactly would be the right approach to this? My original attack was a
Python product. This rapidly became a huge pain, as the folderish product
contained several ZSQL methods that require constant tweaking. With each
tweak, I had to delete existing instances of my product (as they contained
instances of old ZSQL methods) and reinstall and reconfigure a new instance.
Iterations usually involved bouncing the server as well since it eventually
failed to work correctly with refresh (I never figured out why). On top of
that, subclassing my product to create custom reports is beyond what we
expect of our future simian.

The current approach consists of a "reports" folder that I mirror via
PortableHole to different client folders. This lets clients have custom
attributes that the mirrored reports can acquire. This is also unpleasant
since it makes it impossible for custom pages in the clients folder to
acquire reporting infrastructure data from the reports directory. It also
fully exposes my reporting system to the future webmonkey. I will only be
able to distract them with bananas for so long before they stick their paws
into my juicy code resulting in a sticky mess and an angry monkey.

So what would you do? Products look like the right thing, but I'm not sure
how to handle the mess of SQL methods and potentially complicated
customization I need to do.

Just so it's clear, here's what I have now:

/clients/one/reports (PortableHole to /reports)
/clients/two/reports (PortableHole to /reports)
/reports (contains LOTS of stuff, including more folders with ZSQL methods,
DTML, Python snippets, images...)

I also had a previous solution:

/reports/client-one/index.html
/reports/client-two/index.html
/reports/...  All the above mentioned DTML & ZSQL stuff but not organized
into subfolders.

This solution was unmaintainable since the reports folder was rapidly
swelling to huge proportions, making it difficult to work in that folder.

What it feels like to me is that Zope's acquisition is clever but
insufficient for moderately complicated design. What I want is more like an
import or inheritance system, where I explicitly state what I'm trying to
use.

Obviously, I'm missing something (besides a monkey).

Comments?