[webkit-dev] Hunspell based spellchecker

[Hajime Morita]

On Fri, Nov 19, 2010 at 4:02 AM, Maciej Stachowiak <mjs at 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 <darin at 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