Well i've come up with a basic idea, for names and class layout of the rule-part part of filter refactoring. The main rule-context and filter-rule objects are for the most part simply being moved to camel object and being renamed. The get_widget() methods obviously aren't, and will require probably some fairly simple mapping/handler code.
I started looking at having a separate class for each possible rule-part, e.g. 'subject contains', 'body contains', etc, but I think that will blow out the number of objects too much ... see the diagram at http://primates.ximian.com/~notzed/camel/camel-rule-part.ps.gz (PS the CamelRulePart is more or less what we have now in FilterPart, and has some spurious methods and attributes) So perhaps, as also in that diagram, it could use a combination of procedural and oo code, and simply use a case statement to implement the internals through a common implementation - or i guess, some combination thereof. The factory which would hang off the RuleContext could handle all the details ... Doing this we might even be able to just use/evaluate/add a method to the 'RulePart' directly, without having to go via the s-expression stage at all ... Searches should probably also be done via a RuleContext so they can properly target their backend - although the requirements for vFolders might make it trickier (?) Currently the filter-action parts use the same super-class as the filter-rule parts, perhaps they should subclass a different one. Hmm, reminds me, nothing else is using the filter-editor stuff is it? I know s-expressions are used in the addressbook, etc. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
