[Zope] RE: [Zope-dev] complex zope applications

[Rob Page]

>  hi folks,

Hi Scott!

>  i originally planned to use ASP, but couldn't find any tools i was 
>  happy with. already a little behind, i gambled and decided to use 
>  zope. not knowing any python, i went the DTML/SQL method 
>  route. this part of the application is working well.

I'm a little biased but if the application is complicated for Zope it
would have been, um, MUCH more complicated with ASP.</$0.02>
  
>  here's the problem. the full (larger) scope of the project is now 
>  becoming clear. to model all the data will probably require 18-20 
>  tables. working with the data will require 3 or 4 separate 
>  applications.

Aaahh, isn't that fun.  Of course, before anyone told you the full scope
of the project you'd committed (and they'd written down) cost and
timeline objectives, right?!  Incremental software requirements
discovery is about as certain as the speed of light, no?  :^)
  
>  any ideas on how to develop this in zope in a manageble way? the 
>  first application is composed of a LOT objects: DTML input forms, 
>  DTML form handlers, SQL methods, etc. i'm afraid if i keep going 
>  this route things will spiral out of control.
>  
>  what seems like a better structure is 3 tier: python business 
>  objects talk to (encapsulate) the database. zope controls the 
>  business objects. the main reason i switched to zope is that it 
>  seems like zope is set up for this.
>  
>  before i jump into this, is there anyone who has done something 
>  similar? can you offer any advice or moral support? sorry for the 
>  broad questions, but i guess i'm looking for feedback at a higher 
>  level. over the next few months i'll have 1000s of more specific 
>  questions :)

Yes.. we've done some pretty complicated apps.  We've also taken a fancy
to modelling the apps with UML.  The whole notion of Actors in a system
provides a very nice functional decomposition and DRASTICALLY simplifies
security.

I'd suggest a main application folder with at least one subfolder for
Actors.  In the Actors folder create a subfolder for each Actor.

\TrainingRegistry
  \UserFolder (for security on the app)
  \Actors
    \Trainer
    \TrainingManager
    \TrainingEventManager
    \TrainingLocationManager
    \AppAdministrator

Odds are you'll have some SQLMethods like:

o  sqlSelectTrainers
o  sqlSelectTrainingEvents
o  sqlSelectTrainingLocations

which will probably be used ALL over the app.  Put those on the Actors
folder -- that way you can use them (often overloaded with Acquired
variables) in all of the Actor folders without duplicating them (ooh,
baad).  Another pattern that's been useful is (as shown above) to put
the lookup table care-and-feeding functions in a separate folder
(AppAdministrator).  This person adds, edits, and deletes new Locations,
Counties, etc..  Of course your analysis may show that a Trainer might
also need to add a Location -- in that case put the forms in Actors and
acquire them.  IMNHO, the BEST way to model this is with a UML Use Case
diagram (it connects Actors with Use Cases).  The need to
use/reuse/acquire methods jumps right out at you.

Note that ZClasses will likely cause us to evolve this approach.

HTH,
Rob