[GSoC’ 18 Project Updates] Work Done During Phase 2 of Coding Period

As the second evaluation of the GSoC comes to an end, I thought why not write a blog post about the progress made during the second coding phase which ran from June, 16 till July, 13. This post is in continuation with the first post that I wrote about the progress made in the first coding phase.

So, when the first GSoC evaluation took place I had completed with the Tree Editor, and now I had to work on the Split View editor (Part 4 of the project), the GitHub integration (Part 5 of the project) and obviously on fixing the bugs.

[Part 4] Split View Editor

The split view editor was intended to give user both Text Editor and Tree Editor, side by side, at the same time. On one side the text editor is displayed while on the other the tree editor is displayed. This view was included so that the user can quickly add and delete the xml using tree editor and review it using the text editor. Although it can become quite messy when working with bigger xml files due to the small width of the both editors. But it depends on the user preference, its good to have choices :p

Syncing Editors

As all the 3 views contain different instances of the editors, syncing them all together was a tricky part and took me some time to figure it out. Syncing was important so that if user updates the XML in one of the views and switches onto another views then the data in that tab should also be updated.

The first task was to sync both the side by side editors in the split view. If the user is working on text editor then the XML in the tree editor will get updated when the div in which it is placed gets focus (the user clicks on the tree editor). If the user is using the tree editor, all the updates in this editor are done by a button click, so when a button is clicked the text editor gets updated.

The more tricky part was to sync the editors in the 3 views. All the 3 views are stored in the 3 Bootstrap tabs. Since, for switching from one view to another the user has to click on the tabs, a click event is bind on all these tabs. When the user clicks on one of the tabs, first we determine the currently active tabs the user was working on, then we get the XML value from the editor in that tab as it will contain the latest value and then we update the editor in the view on which the user is switching to.

But this method had one exceptional case that needed to be covered, which is, if the XML is invalid then the tree editor can’t be used, since it needs to parse the XML and it cannot parse invalid XML. So in this case instead of displaying the XML tree, it displays a message. So getting the data from the editor won’t work, this was solved by storing the text in a variable and updating it when the user switches the tabs. If we are not able to get the data from the tree editor then the value in that variable can be used.

Additional Features

Generating Diff - While working on the project, I thought it would be nice to have something using which the user can see all the changes that he has made in the XML text. This would help him in reviewing the XML text. This was achieved by using the difflib module of Python. The module was modified to generate inline diff instead of side-by-side diff, because in my opinion inline diff makes it easier to review the changes.

Validate XML - This feature was suggested by one of the mentors. This would take the XML text and validate it against the SPDX XML License Schema. This would help the user to verify his XML file, if it follows the license-xml rules or not. This feature was implemented using the lxml etree module of Python.

[Part 5] GitHub Integration

This is the last and final part of the project on which I am currently working on. The idea is to make a feature using which the user can make a Pull Request in the license-list-XML repository, by just click of a button.

One idea was to use a bot account and use it to make all the PRs, but after discussing it with the mentors we decided to make a PR with the user’s GitHub account. This will not only give them control on that PR (if they want to make further changes), but will also prevent from spam PRs.

Making the Pull Request from the user’s GitHub account can be handeled only by an GitHub app. There are two types of GitHub apps to choose from, one is the normal app and other one is the OAuth app. First I tried the normal app but then realized that the users will first have to manually install the app and then only we’ll be able to make API requests on behalf of the user. The OAuth apps was better suited for my requirements. Passing the repo scope while authenticating the user with GitHub OAuth app, gives us permission to read and write on the users GitHub repos.

Using this method the user will only have to click a button and authenticate to the GitHub app, rest all will be handeled by the app. Using the GitHub api and the user access token, it will first fork the license-list-XML repo, then will create a new branch, then make a commit with the new file, then create a PR from that branch to master.

Now all that left is to integrate this feature in the editor. Hopefully this will be done soon. Thank You for reading.

---