On Fri, Nov 19, 2010 at 4:02 AM, Maciej Stachowiak <m...@apple.com> wrote: > > On Nov 17, 2010, at 11:44 PM, Hajime Morita wrote: > >> 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? > > "Interface in WebCore + Implementation in WebCore and WebCoreSupport" doesn't > match WebKit's normal approach to layering. Our approach so far (for ports > other than Chromium) has been to make it possible to link WebCore separately, > and therefore only have dependencies from WebCore to WebKit, not vice versa. > If WebCore functionality needs to call up to WebKit, we use an abstract > interface in WebCore which WebKit then implements, i.e. the client pattern.
Agreed. And I realized that my last explanation was not clear enough again ... I'm sorry for confusion. In this proposal, we will have: - WebCore::TextChecker interface (or TextCheckingClient interface, to follow our usual naming) - WebCore::TextCheckerHunspell class, implementing WebCore::TextCheckingClient - (WebKit::)WebTextChecker class, implementing WebCore::TextCheckingClient. There is no explicit dependency from WebCore to WebKit. WebCore::Editor will depend WebCore::TextCheckingClient, whose implementation might be in WebKit. -- morrita > > Regards, > Maciej > > > -- morrita _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
