[webkit-dev] Thoughts on WebKit/WebCore refactoring
mjs at apple.com
Fri Dec 23 13:43:33 PST 2005
On Dec 23, 2005, at 2:03 PM, Darin Adler wrote:
> On Dec 23, 2005, at 11:07 AM, Maciej Stachowiak wrote:
>> On Dec 23, 2005, at 8:24 AM, John Sullivan wrote:
>>> "DocumentController" seems like a problematic name because it's
>>> too close to NSDocumentController, yet it's very much not
>>> parallel. Safari has one NSDocumentController per window, but
>>> there's one DocumentController per web frame.
>> True, but Document (in the DOM) and NSDocument are non-parallel in
>> exactly the same way. The root of the problem is overloading of
>> the AppKit and DOM senses of the term "document". I could call the
>> WebCore one FrameController (or even just Frame) but I think that
>> would be less clear about it's actual relationship to the document.
> I think that Page and Frame might be great names for these
> controller object classes; perhaps even better than PageController
> and DocumentController.
That actually sounds pretty good. Usually the MVC convention is to
use an unadorned name for the model class and to decorate Controller
and View as such. But it would be nice to keep these names brief.
> The plan sounds good -- a key part of this is how bridging will
> work for the policy-delegate type things.
Yep, I hope to tackle this next once I finish up redoing management
of the frame hierarchy.
> I'd like to see any new bridging done with C if possible as opposed
> to C++ or Objective-C.
Right now I'm leaning towards WebCore exposing a C++ interface, with
possible C, ObjC or other C++ APIs to build on top of this. But I
could be swayed.
More information about the webkit-dev