Summer Coding 2010 proposal - Docbook Based Wiki using Beacon

About Me

1. My name is Udit Sharma
2. My email address is maxudit007@gmail.com
3. My wiki username is maxudit007
4. My IRC nickname is maxudit007
5. My wiki page is user:maxudit007
6. My primary language is English, Hindi
7. Location, and what hours tend to work: Jaipur, India. 9:00 to 23:00 IST
8. I am Drupal Developer for past one year and developing Drupal based websites. I am fedora ambassador for past 2 years now and spreading fedora and its words with help of local lug. I have strong PHP background with creating custom modules in drupal, joomla. My portfolio is on http://uditsharma.in

About my project

1. My Project name is Docbook Based Wiki using Beacon.
2. My project is came from Ideas page, https://fedoraproject.org/wiki/Summer_Coding_2010_Ideas_-_Beacon
3. Beacon is WYSIWYG editor for XML based documents. It is web based and extensively makes use of Javascript and XSL. From last year's GSoC, Beacon supports Docbook editing, so its very easier for non-programmers to contribute to documentation on fedora's website etc. The aim of project is to make a online WYSIWYG DocBook editor as an extension of MediaWiki, creating a wiki editor in which I would be make use of Beacon as a library. I would be using Javascript, CSS, XML, HTML, DOM, PHP, Ajax technologies to make this project.
4. This is my schedule as discussed with my mentor Nandeep Mali for the project:
   • 1 June-8 June : Understanding the MediaWiki and its extension architecture, how extension works on MediaWiki.
   • 9 June-16 June : Coding starts to make a extension for MediaWiki using Beacon as a Library.
   • 17 June-24 June : Coding Continues..
   • 25 June-2 July : Extension code almost done.
   • 3 July-10 July : Mid-term evaluation by Mentor
   • 11 July-18 July : Test of the Extension on MediaWiki and fixing bugs/errors.
   • 19 July-26 July : Mentor evaluation of the MediaWiki Extension. Mentor final commments and report guidelines.
   • 27 July-3 August : Making Documnetation for the extension developed so that future development on it would be easier for another developer or so.

I have strong PHP, JavaScript, Ajax Background and coded modules for drupal too. My work is on http://uditsharma.in for reference. I can complete the above project in given timelines because I am pretty much familiar to these technologies which project wants.

1. How implementation will be done on this project:

There are several ways to make WYSIWYG editor that works in browser.

1. • 1. Pure Javascript. Capture mouse input, buttons, keystrokes, etc., and actually edit the HTML of the current document.
   • 2. By Creating a custom browser plug-in, Java applet, ActiveX control. This would probably be workable, but would take quite a bit of hacking stuff but its interesting, and may or may not work. At the moment there is limited approach. Only Java applet is (possibly) cross-browser compatible. But not all users have Java on their machines and JavaScript is supported by all popular browsers.
   • 3. Browsers like Mozilla, Internet Explorer and Chrome have included ways to make sections of a page editable. Mozilla has its rich text editing API, and they use that.

1. HTML to Wiki markup:

The aim is that, I have to make a PHP script that converts simplified tidy output (xhtml) to wiki-code. This would be easy to do with epoz. Epoz 0.74 feeds the html through tidy on the server via xml-rpc when switching to source view and on save in MediaWiki. This process includes two things:

1. WYSIWYG view on normal browsers which we see: uses the default css and html editing
2. SOURCE view on mediawiki: WIKI source

Now, for this an XSLT stylesheet for converting HTML to wiki markup is now available: html2wiki.xsl(http://mozile.mozdev.org/0.8/demos/html2wiki.xsl). It is still a work in progress but it can handle a wide range of formatting.

1. Advantages for this implmentation:

1. • XSLT can be used client-side by most modern browsers.
   • The resulting wiki markup can be submitted as if it came from an HTML textarea.
2. Disadvantages are there for this implementation:

1. • Much of the white space information is lost during parsing and the XSL transformation.
   • The current MediaWiki parser does not provide enough information about templates and other generated content in an article's HTML.

I have to modify and submit changes to mediawiki parser. mediaWiki parser currently includes in the HTML which it generates. Tags have to changed and templates need to be marked as see in html.

Me and the community

1. If my project is successfully completed than:
   • Non-Pragrammers would be able to edit the wiki pages as WYSIWYG way.
   • Documentation of the extension makes future development possible on this project.
2. If I got stuck in my project and my mentor is not there than I would discuss with other community members, which have knowledge in this technologies and than would make a wordaround and continue on my project.
3. I will make sure that my mentor would get weekly updates and for testing the code or evaluation.

Miscellaneous

1. Extra Things
   • I setup the enviroment for the project on my local machine.
   • I met personally with my mentor i.e. Nandeep Mali.
2. My T-shirt size is Large.
3. Learning experience you had as a child:

I am inspired with my father's brother. He got his computer machine in his college days and I was in class 7th at that time, I used to play games on that earlier, I saw him with some coding stuffs which he do and told him to teach me all that and that's how I started in the computer as coder. I remember that day when I created my first and unique project on automobiles with Visual Basic in class 11th. After my 12th class, I got to know about linux, I installed Fedora on my local machine and started to learn it and how to write code on linux and all. How to make open source applications and all.

plus talk Category:Summer Coding 2010 applications