Off-list you talked about possibly introducing a lifecycle to theCompilationProblemHandler. IMO their purpose is to different to get a common lifecycle. Many purposes do not even need a lifecycle at all (e.g. logging the compilation problems, or (as in my adapter to XSP) delegating the problem to Cocoon. The so-called CompilationProblemCounter (in the patch) is a special case for the CompilingListener, so the CL should also care about its lifecycle, not the compilers. There are even other lifecycles conceivable - shall the compilersmanage all of them? I have the Avalon interfaces in mind ... ;-)
One of the problems I see here is that the compilers *does* need information like an error count. Removing it from the interface does sound clean in the first place ...but it clearly violates the KISS principle. Any suggestion how to handle that otherwise? My current cocoon integration work also triggered some other thoughts but I haven't had much time to think this through. And I've only a few busy days left until I leave for 3 weeks of vacation :-D (anyone been to costa rica before?) I'll see what I can do beforehand ...but for sure I'll have made up my mind afterwards ;) cheers -- Torsten
PGP.sig
Description: This is a digitally signed message part
