do you really want to show compiler errors to the user? If so, you can pass a problem handler that consumes the problems up to a refresh of a page. For this refresh the problem handler is asked for the problems and they are passed to the view. After getting the problems from the handler it can be resetted or cleared. (BTW, this use case shows a different lifecycle for the handler and is another signal for removing lifecycle specific stuff from the handler interface.)
Well, to me it's a clear example why a lifecycle would make sense!
For the integration into web frameworks: Do you need the CompilingClassLoader? Isn't the Compiler sufficient? At least for XSP in Cocoon the reload is handledby Cocoon.
Which is actually bad bad bad! We had major problems with that. The lastmodified check is a big performance bottleneck. If you go for a synchronous check you would have to check it on every request. We worked around that by caching it for a certain amount of time. Beforehand XSP pages did just not scale. An asynchronous approach will help with the SoC and scaleability. ...implementation that with XSP turned out to be no piece of cake and noone ended up doing it. IIRC there was a discussion with Berin long long(!) time ago.
I'm going to provide a JCI implementation for the LanguageCompiler interface (used in XSP), but probably not in the next two weeks.
Which would be great :-) cheers -- Torsten
PGP.sig
Description: This is a digitally signed message part
