That sounds pretty much exactly in line with how I'd like to see this
code evolve. It seems like FrameLoader should hold the following
state:
1) The various DocumentLoaders (provisional, policy, and committed).
2) A state machine concerning the lifecycle of navigating a frame
(displaying initial document, navigation pending, committed, client
redirects, etc).
3) Various subcontrollers related to navigation (e.g.,
HistoryController, NavigationScheduler). We can move these elsewhere
if you think they'd be better somewhere else (e.g., on Frame).
In terms of what's in FrameLoader now that I think should move out,
we're getting pretty close. These are what's left on my list:
1) Functions relating to mixed content. These should move off to some
smaller object responsible for understanding mixed content.
2) Functions related to submitting forms. These should move off to be
another subcontroller, like the NavigationScheduler. They're really
about getting form submissions ready and finding the right Frame to
navigate, not about actually doing the navigation.
3) Various functions and state related to firing Document lifecycle
DOM events (e.g., the load event, the unload event). These seem more
like they should be DoucmentLoader's job because they relate to a
specific document, not to the transition between documents.
Aside from the normal navigation case, there's also all the special
cases for the PageCache. It's sightly unclear to me what of that
knowledge should be in FrameLoader and what should be in
PageCache-specific objects.
Finally, there's a lot of redundancy in terms of kicking off and
stopping navigations. I'd like to clean that up as well because today
it's very unclear when various functions are safe to call and why you
might choose to call one instead of another. I think we were somewhat
successful in doing that for NavigationScheduler (although it's
slightly unclear what the difference is between scheduleRedirect and
scheduleLocationChange).
Adam
On Fri, Jun 24, 2011 at 4:57 PM, Darin Adler da...@apple.com wrote:
I have an idea for a rule of thumb for what code should be in FrameLoader and
what should go in DocumentLoader.
I’d suggest that we leave code in frame loader that relates to switching from
one document to the next. Starting a navigation to a new location, creating a
document loader for the new location, that sort of thing.
And we move code from frame loader to document loader that relates to loading
once a document loader exists. Pretty much anything you do in the context of
a document that’s already loaded would be in document loader. My brief
perusal of the current code in frame loader gives me the impression that this
would be more than 50% of the code still in there.
My hope is that we’d move both functions and data based on this rule of
thumb. It may be tricky to do this without breaking anything, some things may
currently work for strange or unintentional reasons and rely on state that
outlasts the document loader.
Thoughts on this?
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
