> Cool, > > That will be another source of information that will be extremely helpful. > > One of the design ideas I had was to use the "Chain of Responsiblity" > pattern which will allow functionality to be added in stages and make it > easy to configure. Adding new features could them be done quickly > without disturbing existing functionality. > > I'll work up a quick class diagram tonight to show what I have in mind. > > Chad >
I'd be interested to see this. I guess the closest pattern to my code is the command pattern. Identify mail as message or command message-->process list message command-->pick command and run it The reason i used the helper interface was to try and keep all code for getting (and eventually modifying) list settings/membership separate from the mailet, for two reasons: 1) resuse the helper in any management apps, 2) new list stores only need to implement one interface - no code changes. That way, implementing a new repository (eg JDOM xml version) for the list is pretty straight forward - satisfy one interface, and specify the class in the config, together with any options. Similarly i was intending to specify an interface for archiving - so this could be done straight to database, or through an NNTP repository depending on the archiving implementation specified in the mailet config. I have merely copied the current command code from the commandlistserv. I never really played with it much. The problem i can see when adding commands, is that they will probably require certain new functionality in the helper interfaces. E.g. implementing a digest command will require the helper to handle a digest flag for each subscription. I was thinking of perhaps redoing some of my code so that each subscription and mailing list has a map of string attributes - this would be more flexible as for example adding a digest flag would require no code changes in the storage. However i'm not sure how well this would map to say an LDAP repository, so i stuck to hard coded flags. If anyone has a chance, then please comment on the code, and what you would like changed. I feel it's a bit of a sloppy implementation, but hopefully it does keep things open to enhancement. Daniel. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
