Change Details

An instance of MobileFormatter is created in ApiMobileView.php, ApiParseExtender.php and includes/MobileFrontend.body.php Both invoke identical code paths and run the getText method yet are run separately. I see two possible improvements here: 1. If you view a page Foo in the mobile site and then request it via the API, the same code is run again - no caching whatsoever. 2. The API does additional processing to split the page into sections and provide a nice JSON of all the information needed to render a page. This would be extremely useful for the skin which duplicates a lot of this logic (for example it checks whether a page has languages and it should render a language button, it relies on the HTML output to construct its sections. The API actually makes use of memcached, so there is an opportunity here for What I'd like to see is the skin being passed the JSON output of the api request and use this to render the page.

An instance of MobileFormatter is created in ApiMobileView.php, ApiParseExtender.php and includes/MobileFrontend.body.php There is lots of overlap in the work they do. The code in `includes/MobileFrontend.body.php` does work inside MobileFormatter that is repeated by `ApiMobileView.php` I see several possible improvements here that could be made by distangling these two things. [] There is memcached caching inside `ApiMobileView.php` - let's move this to `MobileFormatter`. If you view a page Foo in the mobile site and then request it via the API, the same code should not be run again - they should share a cache. [] The code for creating the structured data entity should be moved to `MobileFormatter` to allow the SkinMinerva to use it. [] Skins should be generated via the structured data entity rather than stitching and calculating data themselves. The API does additional processing to split the page into sections and provide a nice JSON of all the information needed to render a page. This would be extremely useful for the skin which duplicates a lot of this logic (for example it checks whether a page has languages and it should render a language button, it relies on the HTML output to construct its sections. [] Edit icon rendering should be moved out of the MobileFormatter and into the Skin. This would bring us more in line with how apps do this. [] For development purposes and to encourage us to be consistent with the mobile content service, the MobileFormatted API should be consistent in output and interchangeable. As demonstrated by the POC patch we should be able to use real world content on our local development wikis by doing this. [] In future we may want to experiment with using the mobile content service for all requests

An instance of MobileFormatter is created in ApiMobileView.php, ApiParseExtender.php and includes/MobileFrontend.body.php Both invoke identical code paths and run the getText method yet are run separately.There is lots of overlap in the work they do. The code in `includes/MobileFrontend.body.php` does work inside MobileFormatter that is repeated by `ApiMobileView.php` I see twoseveral possible improvements here:e that could be made by distangling these two things. 1.[] There is memcached caching inside `ApiMobileView.php` - let's move this to `MobileFormatter`. If you view a page Foo in the mobile site and then request it via the API, the same code should not be run again - they should share a cache. [] The code for creating the structured data entity should be moved to `MobileFormatter` to allow the SkinMinerva to use it. [] Skins should be generated via the structured data entity rather than stitching and calculating data themselves. The API does additional processing to split the page into sections and provide a nice JSON of all the information needed to render a page. This would be extremely useful for the skin which duplicates a lot of this logic (for example it checks whether a page has languages and it should render a language button, it relies on the HTML output to construct its sections. [] Edit icon rendering should be moved out of the MobileFormatter and into the Skin. This would bring us more in line with how apps do this. [] For development purposes and to encourage us to be consistent with the mobile content service, If you view a page Foo in the mobile site and then request it via the API,the MobileFormatted API should be consistent in output and interchangeable. the same code is run again - no caching whatsoever.As demonstrated by the POC patch we should be able to use real world content on our local development wikis by doing this. [] In future we may want to experiment with using the mobile content service for all requests 2. The API does additional processing to split the page into sections and provide a nice JSON of all the information needed to render a page. This would be extremely useful for the skin which duplicates a lot of this logic (for example it checks whether a page has languages and it should render a language button, it relies on the HTML output to construct its sections. The API actually makes use of memcached, so there is an opportunity here for What I'd like to see is the skin being passed the JSON output of the api request and use this to render the page.