Quick question on designing with ZPatterns: Is a developer meant to specialise Specialist by defining a subclass, as is the case in LoginManager? Or, given how many plugpoints Specialist has, is it best to instantiate Specialists as-is, and fill them with DTML methods, External methods and triggers and so forth. Then, when you want a new one, it gets constructed by some sort of wizard. Or, is the answer "whichever seems most appropriate" ? Thanks. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
At 03:39 PM 7/11/00 +0100, Steve Alexander wrote:
Quick question on designing with ZPatterns:
Is a developer meant to specialise Specialist by defining a subclass, as is the case in LoginManager?
Or, given how many plugpoints Specialist has, is it best to instantiate Specialists as-is, and fill them with DTML methods, External methods and triggers and so forth. Then, when you want a new one, it gets constructed by some sort of wizard.
Or, is the answer "whichever seems most appropriate" ?
Yes, with a slight inclination towards instantiation rather than subclassing. As soon as one finds oneself repeating the same pattern of setup, however, it's probably time to start looking at subclassing. At this point, so few ZPatterns-based apps have been developed, that I personally think it's premature to begin subclassing. The work that Shane is doing in the area of making ObjectManagers' built-in methods overrideable by adding new methods in-place, however, should allow for the optimum blend of these approaches. I can foresee a time when people have created several Specialist variants for common usage patterns, such as a "simple database" specialist that includes an add form, search form, etc., based on properties meta-data in the specialist itself. There are many exciting possibilities once ZPatterns itself is stabilized and the missing pieces are finished. I think Shane's work in the area of defining interfaces for customization will be an important part of making ZPatterns a powerful tool for developers of all skill levels.
participants (2)
-
Phillip J. Eby -
Steve Alexander