> Please let me know what you think of the new API so far...
> http://www.lokitech.com/~sergek/mailetdocs/ I'll continue to Javadoc
> more stuff as I go and might need to add a few methods as I finish
> porting all the mailets... not all the classes/interfaces have a top
> level descriptive comment, but I think just about every method in every
> class/implementation has one.
1. Mailet.service() method should throws MailetException, maybe even
IOException, rather than the generic Exception.
2. Mailet.init() metod should throws MailetException to handle configuration
errors.
3. Introduction of an Address class which ensures a mail address is well
formed encapsulating such functionality and overloading every method which
uses a String as for mail address to be used with an Address type: overloaded
methods wich uses String should call the correspondent method with a new
Address instance created with the String contents.
4. Rename the MailetContext.getMXRecords() method into something which doesn't
contain a DNS specific acronym: getMailServers() or getMailPath() or
getMailDispatcher() will be better.
5. Suppress the MailetUtils class which actual functionalities could be
obtained using the Address class which will have static methods to parse a
String returning the host part or the user part.
6. Add to the GenericMailet class the getMailetName(), getInitParameter() and
getInitParameterNames() methods only for convenience.
On Matcher I haven't understood why you defines a totally new interface: I was
thinking matching rules was something strictly binded with Mailet exactly as
request and response are binded to Servlet. IMO rarely I'll have a Mailet
without a matcher so I think matching rules should be considered more Mailet
paramethers than classes.
An approach I wish to suggest is to define matching rules inside the Mailet
interface (still able to extend matching rules) and binding their matching
values as configuration parameters: when the GenericMailet init() is called
(still able to override matchers behaviour) it reads such parameters and
initializes corresponding inner classes (I prefer inner because they have no
more reason to be usable outside the GenericMailet class) which match method
will be then available at service() time.
Am I going in the wrong design pattern? If not and you need help I can
personally make the canges if you send me the source of the new mailet API.
Roberto
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
