On Thu, Nov 18, 2010 at 3:51 PM, Darin Adler <da...@apple.com> wrote > On Nov 17, 2010, at 10:49 PM, Hajime Morita wrote: > >> In other word, we should make sure that TextChecker interface can have >> subclasses both inside and outside WebCore. > > Yes, in this model the abstract base class inside WebCore will need a derived > class inside Windows WebKit that then in turn calls outside of WebKit. But it > is not appropriate to expose an class from WebCore directly as part of WebKit > API. > > A WebCore class is an appropriate way for WebKit to connect to WebCore. It is > not an appropriate way for WebKit to provide API.
Hmm, I'm a bit confused - My last explanation looks not enough, so please let me clarify: - TextChecker is a similar to EditorClient. It will be placed in WebCore/platform/text, like EditorClient is in WebCore/page/. - And (imaginative) WebTextChecker (or TextCheckerWindows) will be in WebKit/win/WebCoreSupport, as WebEditorClient is in WebKit/win/WebCoreSupport. - WebTextChecker should use EditingDelegate, as WebEditorClient is using it now. In other word, This change will just extract TextChecker interface from EditrClient interface, and provide some default implementations of it in WebCore, as we have WebCore/page/EmptyEditorClient for EditorClient. I guess we don't have this "Interface in WebCore + Implementation in WebCore and WebCoreSupport" pattern yet, But I don't think it is such a huge jump from existing patterns, like "Interface in WebCore + Implementation in WebCoreSupport". Does this make sense? -- morrita > > -- Darin > > -- morrita _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
