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

[Phillip J. Eby]

At 10:24 AM 3/11/01 +1100, Itai Tavor wrote:
>
>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.

Or you may want to just create one factory method that creates an entire
family of related Specialists.  Specialists do support TTW overriding of
their methods, if you set up the methods properly in your Python code.  (I
forget how this works, though, you'll probably need to check the source code.)


>-  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?

Yes.  Use "class_default_for_X" methods.  (e.g. "def
class_default_for_index_html").  This will make them capable of being
overridden with a Class Extender in the Rack or Specialist.



>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).

Your factory code can set this up, although I admit it's ugly.


>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?

Placing them in a folder would be fine.  Actually, it would suffice simply
to install a meta type which creates all the Specialists in the selected
folder.  Note that Zope does not require that a meta type correspond to
some physical class, or that an add operation result in a single object
being added to a container; you can add as many objects as you want in the
same operation.


>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?

If I understand you correctly, then you'd just instantiate another instance
of the application metatype, and then customize whatever needed to be
customized.


>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...

If your factory methods set this stuff up, then you're okay.


>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.

IMHO, ZPatterns is actually pretty mature - in terms of its code.  By that
I mean, it has gone about as far in capabilities as its internal
architecture will allow.  There are many minor improvements that could be
made, but they would be costly compared to their benefit.  I would rather
invest the effort in something that will produce a greater gain for me and
the rest of the community.  TransWarp will be much better for
filesystem-based, Python products than ZPatterns, which is almost 100%
through-the-web focused.

The key phrase, though, is "will be".  Right now, ZPatterns is the premier
system for doing "virtual objects" in Zope, and will continue to be for
some time.  If Ty or I had to start on a new app today that needed the
things ZPatterns does, we would definitely use it.  But we would also
probably take the time to prepare a good UML model for the app, so that we
could more easily port to TransWarp when it gets closer to being finished.