Bug 30037

Summary: Factor PageController out of FrameLoader and Page
Product: WebKit Reporter: Adam Barth <abarth>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, darin, jparent
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 29947    
Attachments:
Description Flags
Patch v1
none
PageController
none
Patch v1 none

Adam Barth
Reported 2009-10-02 21:48:18 PDT
Removes a few methods that have nothing to do with loading frames.
Attachments
Patch v1 (10.29 KB, patch)
2009-10-02 21:49 PDT, Adam Barth
no flags
PageController (47.29 KB, patch)
2009-10-02 23:48 PDT, Adam Barth
no flags
Patch v1 (11.31 KB, patch)
2009-10-03 08:46 PDT, Adam Barth
no flags
Adam Barth
Comment 1 2009-10-02 21:49:54 PDT
Created attachment 40563 [details] Patch v1
Adam Barth
Comment 2 2009-10-02 22:21:42 PDT
Comment on attachment 40563 [details] Patch v1 This patch isn't right. updateHistoryForAnchorScroll shouldn't go in this object.
Adam Barth
Comment 3 2009-10-02 23:48:24 PDT
Created attachment 40567 [details] PageController
Adam Barth
Comment 4 2009-10-02 23:51:57 PDT
CCing Julie because this is undoubtably going to break the Chromium WebKit canary when it lands. We'll need to add some "->controller()" action to the Chromium port too.
Darin Adler
Comment 5 2009-10-03 07:17:43 PDT
Comment on attachment 40567 [details] PageController The object named Page is already a page controller, so I don't think this is the right name for a new object. On the other hand it has frequently been a problem that there is a loader for each frame, but no corresponding loader for the page. Could you describe the distinction between what would go on the page and what on the page controller? Maybe that can give us a better idea what its name should be.
Adam Barth
Comment 6 2009-10-03 08:21:49 PDT
My main goal for this patch is to remove these methods from FrameLoader because they have nothing to do with FrameLoader: - bool canGoBackOrForward(int distance) const; - void goBackOrForward(int distance); - int getHistoryLength(); They ought to be methods of some page-scoped object. Looking around, they seem related to these methods of Page: - bool goBack(); - bool goForward(); - void goToItem(HistoryItem*, FrameLoadType); I was going to add them to the Page object, but I saw this comment: - // FIXME: The following three methods don't fall under the responsibilities of the Page object - // They seem to fit a hypothetical Page-controller object that would be akin to the - // Frame-FrameLoader relationship. They have to live here now, but should move somewhere that - // makes more sense when that class exists. I didn't want to add to the problem described by this comment, so I created the hypothetical Page-controller object. If you'd prefer we just moved the methods from FrameLoader to Page, I'd be happy to do that (and it would make the patch MUCH smaller). We can sort out whether to create the hypothetical Page-controller object later.
Adam Barth
Comment 7 2009-10-03 08:46:23 PDT
Created attachment 40576 [details] Patch v1
Adam Barth
Comment 8 2009-10-03 08:48:22 PDT
Here's what that patch would look like. Even if we do decide we want something like a page controller, we should probably do that in a separate patch.
Adam Barth
Comment 9 2009-10-03 17:17:18 PDT
Comment on attachment 40576 [details] Patch v1 Clearing flags on attachment: 40576 Committed r49067: <http://trac.webkit.org/changeset/49067>
Adam Barth
Comment 10 2009-10-03 17:17:22 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.