Persistence is the title of this post for two reasons: I spent this week developing the data persistence layer for Pathway Presenter, and also began releasing the new version of Pvjs to be used by the WikiPathways community - a lengthy and rather tedious task.
Pvjs is now free to be tested on the dev server of WikiPathways! Please feel free to try it out and report any bugs to me via email. With your help, hopefully, we'll find bugs, squash them, and release it to the production version of WikiPathways quickly.
I stated that this task was tedious - this was because of my unfamiliarity with PHP and MediaWiki (the platform WikiPathways is built upon). It took quite some time to understand WikiPathways' file structure and where I should make changes to introduce the new version of Pvjs.
There has also been quite some debate about the method to integrate Pvjs into third-party applications. In the previous version, third-parties could use an iframe to integrate a Pvjs widget into their application. However, in my opinion, this has reduced maintainability since any updates must be applied to both Pvjs and the iframe (in case of major changes to Pvjs anyhow). Internally, the iframe simply wraps around the custom element of Pvjs anyway so is in some way redundant. However, it is required at the moment because of CORS privileges and does mean that third-parties do not have to include extra scripts into their page (which the custom element requires). After some more debate, I hope to discuss this issue in more detail in the coming weeks.
Data Persistence Layer
After some discussion, it was decided that the data persistence layer could be restricted to LocalStorage for the MVP. So I developed that over the past couple of days and have unit tested it rather extensively (gotta love those green dots). Eventually, data will be persisted on the WikiPathways mySQL server but that probably won't happen during this project's time-span.
There's also now two methods to edit pathway presentations. The first method is what was used before - just specifying the presentation ID as a prop:
<Editor presId="my-pres-id" />
Now, if you don't provide a
presId prop, the user is presented with a nice dialogue to fill in to create a new presentation:
Eventually, this dialogue will include a field for searching for existing pathway presentations. There's also the issue of authentication & authorization - which is ignored for now but will need to be addressed when integrating pathway presentations with the WikiPathways database.