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.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
