At present, YUI Datatables allows a user to modify some value on the page, click 'Save' and have that element be modified directly on the screen. This would be of immense convenience for people needing to make a number of small incremental changes frequently.
Currently there are no known methods to expose this information for display on the main article page; as a result, one has to look at the edit servlet output to determine what values are needed to be able to submit to the edit servlet from the article page directly.
The proposed modification, provided by Ryan Holliday, is to add a few MagicWords into JamWiki to allow for YUI Datatable integration to happen smoothly and without needlessly screen-scraping the Special:Edit page for the current article to obtain the following hidden variables for the submission:
Ryan suggested that I first check into /jamwiki-core/src/main/java/org/jamwiki/parser/jflex/MagicWordUtil.java.
I will post additional details as I get started with this project.
I have implemented RevisionID. It was already practically complete. All I needed to do was access the topicRevisionID in the MagicWordUtil class itself. That was trivial, and ready to be committed into svn.
The problem I am currently at is implementing the sectionId. The sectionId is much harder to implement in light of current architecture. The big plan I had to implement this was to be able to use a MagicWord in any topic section and have it resolve the sectionId for the section it happened to be in. The problem is that sectionId is not an intentionally managed value. The sectionId is determined at parse time as the application parses the content, it happens to count the number of ==Section== blocks there are, and increments the value as it finds them while it builds the Edit link.
In order to obtain this sectionId and make it available to the MagicWordUtil class at it processes the MagicWords, I would have to add a field to the Topic class to store the sectionID as the parsing of the page takes place. That seemed the most straightforward way to handle this. The problem is that I'm not entirely sure if that would even work since I don't know if Magic Words get parsed before or after the sectionId's are determined.
While this is not an ideal situation, but I am at present not interested in implementing the sectionId feature completely because I would have to do something fairly radical to accomplish this, I fear.
I also do not technically need this feature to implement the YUI datatable either. I can simply submit the entire page and that will suffice for my purposes at the moment.
Any thoughts or reviews of this analysis is greatly welcome.
Ryan would prefer that any modifications to the parser be consistent with MediaWiki, and this should be ensured before merging to the trunk. Additionally, any new MagicWords should follow the syntax provided by MediaWiki.
In progress. Please review and feedback is always welcome! -- Shaka 1-Apr-09 6:10 DST