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