[Zope-dev] Designing ZPatterns/Python-product-based, reusable applications - take 2

[Itai Tavor]

Hi,

I didn't get very far asking this question a little while ago, so I'm 
going to try again.

I started developing ZPatterns applications in the ZODB. Then I 
figured there would be advantages to moving instead to python 
product-based development. My goal is to create applications that can 
be reused easily, but I'm having problems deciding on the best way to 
structure the application, how the requirement of reusability affects 
the structure, and how reuse will actually take place.

The starting point is an object-model based application, so unlike 
applications like zCommerce and EMarket, where you start from an API, 
template, or skeleton and build on that, I'll be trying to reuse 
parts of an actual, complete, live application.


Starting with PD classes: Those would be DataSkin-subclassed python 
classes. Reuse would involve either using these classes as-is, or 
subclassing them where changes are needed. No problem here.


Then I need Specialists to manage collections of PD classes. I think 
that these would also benefit from being product-based, so I subclass 
Specialist to create a manager for each role in the application. Now, 
since an existing application might be expanded, the Specialists all 
need factory methods and will all show up in Zope's Add New Object 
menu.


Now consider UI:

- Both PD and manager classes will have administrator UI. This would 
not have to change unless the class is subclassed, so the UI methods 
can stay in the product and loaded using HTMLFile.

-  Many of the classes will also have web user UI, and since this has 
to be designed to fit the design of the web site in which the 
application is used, the UI methods will have to be located where 
designers can modify them - in the ZODB. For the Specialists, I can 
install a default set of UI methods when an instance of the 
Specialist is installed. But where do I store PD class UI methods? 
EMarket's solution is to store them in the Specialist, but this not 
only breaks O-O rules, it can also be very ugly. Say I have a 
Specialist managing 3 PD classes. Instead of an index_html method for 
each class, I'll need class1index_html, class2index_html, 
class3index_html in the Specialist. And each class would have to 
define:

     def index_html(self, REQUEST, RESPONSE, **kw):
         return self.class1index_html(REQUEST, RESPONSE, kw)

This is unacceptably ugly. But the only other thing I can think of 
doing is creating a ZClass for each PD class and store the UI methods 
there. But that's also pretty unacceptable. Is there a better 
solution?


Next, I need object connections - these are created using 
SkinScripts. And as far as I can tell, I can't manage SkinScript in 
the product - they have to be in the ZODB. Which is ok in O-O land as 
they're not strictly part of the PD classes, but this means that PD 
classes don't actually work at all until someone comes and fills in 
the SkinScripts - so the class actually misses a lot of the code it 
requires to function. Also, it means SkinScript code can't be reused 
with the rest of the application's components (except by cutting and 
pasting code pieces from an existing application).


I also need storage management - which is done with Rack methods and 
SkinScripts in the Racks. The SkinScripts present the same problem as 
the ones used for object connections. Rack methods can be ZODB-based, 
in which case again they can't be easily reused and need to be 
manually created before the objects start doing anything, or they can 
be created in Rack-subclassed classes, but that creates a problem for 
RDBM storage - unless it's possible to store SQL methods in a python 
product.


Finally, I need to wrap the whole thing up as an application. So I 
create a Folderish class which installs instances of all Specialists, 
and add application-wide utility methods. Or do I simply place all 
Specialists in a Folder?


Now, about reuse. O-O reuse, as far as I understand it, takes place 
at the class level. So how do I start a new application? Do I 
subclass its main container class and and my own init method that 
adds any added or subclassed Specialists I use? Or do I create my own 
application class and import PD classes from the old application? Do 
I copy the old classes into my new product, or do I import them from 
the old product, which then would require that the old product is 
kept on the server, even if the application that product defines 
isn't used on this server?

And, as mentioned above, how do I reuse SkinScripts, Rack methods and 
SQL methods? Copy and paste? It seems funny that if I create a new 
instance of the product, I don't get a new copy of a working 
application...


That's it. Sorry it's so long and complex. What would be great is if 
someone posted a description of the structure of a working 
application. I'm sure this is something many people are likely to 
struggle with - it almost could be a HowTo. I hope, now everyone are 
back from the conference , that I'd have more luck getting some help 
:-)

On the other hand, considering that ZPatterns is now being superceded 
before it even had a chance to mature, maybe nobody cares to hear 
about it anymore :-( But more on that in a separate post.

TIA

Itai
-- 
--
Itai Tavor                      -- "Je sautille, donc je suis."    --
itai@optusnet.com.au            --               - Kermit the Frog --
--                                                                 --
-- "If you haven't got your health, you haven't got anything"      --