[Zope] Planning advice
Fri, 14 Jun 2002 17:52:28 -0700
> -----Original Message-----
> From: Max M [mailto:email@example.com]
> Sent: Friday, June 14, 2002 3:11 PM
> To: Charlie Reiman
> Subject: Re: [Zope] Planning advice
> Charlie Reiman wrote:
> >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.
> Wouldn't it be wise then to have a class, or set of classes which does
> all the reporting for you in straight sql via Python?
> That way you can test and debug you reports as plain Python. It's much
> more lightweight and you dont mix logic and presentation.
> It should just return a list of objects than can be listed in Zope. The
> report class can then be mixed with a presentation class. Or just used
> in a Python product, depending on what you want/need.
Maybe, maybe not. It's really not clear. We need to use the DCOracle2
Product for authentication (the Zope DA/authentication story is a whole
'nother issue), so we really want to use ZSQL methods. Even if I can use the
DCO2 product from Python without ZSQL method objects (which I probably can,
I'd just have to figure it out), there is the issue of customization of
Splitting presentation and content will make it easy to provide new faces
over the same data, but I also need to specialize data.
What would be ideal, in pythony/zopey terms:
def __init__(self, ): pass
def table1a(): # Whizzo specific
def __init__(self, GenericData datasource):
self.datasource = datasource
def index_html(): # generic report navigation screen
def report1(): # display table1
def __init__(WhizzoData datasource):
# modify something to register report1a with index_html
# present Whizzo specific report
Then, in some zope folder:
Wonderful and all python but not exactly easy future customization. It will
all fall back into my lap, since it's all python (and therefore "real" code
requiring a "real" engineer to modify it). Each new customer will require
subclasses of the presenter and data classes.
Even more confusing to me is what kind of python would this be? A product? 4
products? External methods?