Extension:Proofread Page/GSoC

Summer of Code 2013 project of Aarti Kumari Dwivedi.

Page
in the includes/page folder:

ProofreadPagePage
Same level as ProofreadIndexPage:

ProofreadPageContent
Page's content

EditProofreadPagePage
Edition system. Same as EditProofreadIndexPage. Should handler both edition from the edit form + edition from API (the EditPage::textbox1 field already set with the wall page content).

ViewProofreadPagePage
Answer to the ArticleViewCustom hook: output the page content with the scan view (currently done in JavaScript).

Reports
1. Tested local install with a DjVu file. Works fine. (Aarti)

2. Read up on Wikimedi Labs. (Aarti)

3. Reading up on ContentHandler.(Aarti)

4. Refactoring ProofreadPage.body.php .(Aarti)

5. Began refactoring of Page pages. (Aarti)

6. Added unit tests for Page pages. (Aarti)

7. Began the separation of rendering and parsing part from ProofreadPage.body.php. (Aarti)

2013-05-29

 * Skype meeting every week.
 * Mail to Wikisource-I before any import changes.
 * Use labs
 * Discuss with the Visual Editor team about compatibility with Page: pages (Aarti).
 * Open an RFC about Page: pages storage 46724 (Thomas)

2013-06-07

 * read about ContentHandler that might be used during of after the refactoring
 * make sure to test local install with a DjVu file:
 * read about Wikimedia Labs and how to deploy commits there for "real-life" testing
 * put a message on the main wikisource community portals to point them to Aarti's email to the mailing list (in case the communities are not following it)

2013-06-14

 * Function of ProofreadPage class should be to just process the input it receives. It should not be bothered about how the input is received and how the output is displayed.
 * Write unit tests.
 * Break down large functions into smaller parts so that code redundancy is reduced.

2013-06-22

 * Write a separate class for parsing.
 * Write a separate class for conversion between page number in the file and page number in the Wiki.
 * Implement the ProofreadPagePage and ProofreadPageContent classes.
 * In EditProofreadPagePage class, use more of EditPage functions.
 * Refactor the JavaScript part to move suitable things to server-side for page pages.

Working method
Here is a possible method to do quickly and (pretty) easily good code changes. It's not the ultimate method but I hope it's a good one.
 * 1) Write your code structure (class and method declaration) and then the code itself.
 * 2) When it's done read the diff in your git manager to see issues (personally I use git GUI but everything that output colored diff is good)
 * 3) Test changed part of the software. After this step you should have fixed 75% of the bugs
 * 4) Submit the change on gerrit
 * 5) Do something else during an hour or more
 * 6) Go to gerrit and review your code at if it is the code of someone else with a critical eye. Fix the problems (coding style, crazy things...)
 * 7) Retest parts where code logic have been changed
 * 8) Submit the change
 * 9) Ask for review!

June
I have been working on Refactoring the ProofreadPage Extension as a participant in Google Summer of Code 2013. Changes in gerrit:
 * The first few days were dedicated to settling down upon the methods of working and, getting familiar with the codebase.
 * I also installed the extension on my local version of MediaWiki and tested it with a DjVu file.
 * The first task was to refactor the file ProofreadPage.body.php so that it can be cleansed of code that should have been in some other place. DbConnector classes were used to separate data fetching from other processes.
 * Thomas moved the code related to index pages to ProofreadIndexPage.
 * Some parts of the editing system were moved to a different class for better modularity.
 * Currently I am working on the refactoring of Page pages. I am also reading up on PHPUnit so as to add more unit tests.
 * https://gerrit.wikimedia.org/r/#/c/70610/
 * https://gerrit.wikimedia.org/r/#/c/69973/
 * https://gerrit.wikimedia.org/r/#/c/69802/
 * https://gerrit.wikimedia.org/r/67632