Re: [Evolution-hackers] filter refactor, rule parts

[Not Zed <notzed ximian com>]

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.