[webkit-dev] document()->frame()->script()->globalObject()

[Adam Barth]

On Fri, Jul 24, 2009 at 11:52 PM, Maciej Stachowiak<mjs at apple.com> wrote:
> I think that long-term we need to have a class to represent all the state of
> a Frame that changes whenever the document changes. Right now the closest we
> have to that is DocumentLoader, but it doesn't really hold all of the
> per-document state, some needs to be swapped out separately.
>
> I could imagine three plausible designs:
>
> 1) Document becomes the master class that owns everything which needs to
> change when the document changes, including the inner window and the
> DocumentLoader.
>
> 2) DocumentLoader becomes the master class that owns everything, and the
> relevant fields are moved from other classes, such as Frame, to
> DocumentLoader. Document gets a backpointer to DocumentLoader but otherwise
> can be mostly limited to its primary role of implementing the DOM document.
>
> 3) A new class becomes the master class and owns all three of
> DocumentLoader, Document and the inner window.

I think this concept exists in Mozilla and is the what they call the
DocShell, although the Mozilla architecture is different and DocShell
is kind of a do-everything class.

> I personally like #2 or #3 better than #1, I think Document itself will be
> easier to understand if it remains primarily an implementation of the DOM
> Document interface. I think #2 is plausible and maybe a good idea, since a
> lot of the trickiness of when to swap documents relates to loading.

I might be useful to separate out the model from the controller.  In a
sense, DocumentLoader should be the controller and the mythical new
class should be the model.

> I think that even though this is the right long-term architectural
> direction, we should be very careful and do changes towards this design in
> steps. The reason is that it ties into document transition and central
> object lifetime, which are both areas that are somewhat fragile to
> compatibility, robustness and security bugs.
>
> So probably I wouldn't make too much of this redesign a prerequisite for
> other changes.

One way to move in this direction incrementally is to build from the
concept of a ScriptExecutionContext, which has been recently separated
from Document.  Currently these are the same object, which might
facilitate moving concerns from Document to the mythical object
without running into the complications of having a second object for a
while.

Adam