Thoughts on WebKit/WebCore refactoring
I'm doing work now to refactor WebKit and move more of the code down to WebCore to live in the portable layer. Here's some thoughts I had on the direction for this: * KHTMLPart gets renamed to DocumentController. It no longer makes any attempt to match the original KHTMLPart API. This will be platform-independent controller logic. If WebCore ever runs on KDE again, then a new KHTMLPart would have to be written to provide KDE- specific API glue on top of DocumentController. * Eventually every document may have a DocumentController, even viewless documents created through such means as XMLHttpRequest or the DOM createDocument call. * For a top-level document attached to a view, there will be a PageController class. This is for things that make sense only at the top level in a context where you have a view. * DocumentController will bridge to WebFrame. Either using a two-way bridge as currently, or possibly two classes, WebFrameBridge and DocumentControllerBridge. Or bridging may be so minimal that WebFrameBridge is not needed and instead WebFrame connects to generic callbacks on the DocumentControllerBridge. Alternately, WebFrame might connect directly to the C++ interface on DocumentController. * PageController will bridge to WebView. Otherwise much as above. Anyway, this is the general idea. I think things will gradually moving in this direction, and the loading and frame traversal logic will increasingly live in WebCore. Any comments on the names or other aspects of this design? Regards, Maciej
On Dec 23, 2005, at 12:15 AM, Maciej Stachowiak wrote:
I'm doing work now to refactor WebKit and move more of the code down to WebCore to live in the portable layer. Here's some thoughts I had on the direction for this:
* KHTMLPart gets renamed to DocumentController. It no longer makes any attempt to match the original KHTMLPart API. This will be platform-independent controller logic. If WebCore ever runs on KDE again, then a new KHTMLPart would have to be written to provide KDE- specific API glue on top of DocumentController.
* Eventually every document may have a DocumentController, even viewless documents created through such means as XMLHttpRequest or the DOM createDocument call.
* For a top-level document attached to a view, there will be a PageController class. This is for things that make sense only at the top level in a context where you have a view.
* DocumentController will bridge to WebFrame. Either using a two- way bridge as currently, or possibly two classes, WebFrameBridge and DocumentControllerBridge. Or bridging may be so minimal that WebFrameBridge is not needed and instead WebFrame connects to generic callbacks on the DocumentControllerBridge. Alternately, WebFrame might connect directly to the C++ interface on DocumentController.
* PageController will bridge to WebView. Otherwise much as above.
Anyway, this is the general idea. I think things will gradually moving in this direction, and the loading and frame traversal logic will increasingly live in WebCore.
Any comments on the names or other aspects of this design?
"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. John
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. Regards, Maciej
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. The plan sounds good -- a key part of this is how bridging will work for the policy-delegate type things. I'd like to see any new bridging done with C if possible as opposed to C++ or Objective-C. -- Darin
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
On Friday 23 December 2005 03:15, Maciej Stachowiak wrote:
I'm doing work now to refactor WebKit and move more of the code down to WebCore to live in the portable layer. Here's some thoughts I had on the direction for this:
* KHTMLPart gets renamed to DocumentController. It no longer makes any attempt to match the original KHTMLPart API. This will be platform-independent controller logic. If WebCore ever runs on KDE again, then a new KHTMLPart would have to be written to provide KDE- specific API glue on top of DocumentController.
I think we decided this would be a good route. What kind of interface were you thinking of? -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/
participants (4)
-
Darin Adler
-
George Staikos
-
John Sullivan
-
Maciej Stachowiak