Hi All.
A first draft of my app is below, with some unimportant parts snipped out for privacy. I'd appreciate any suggestions for improving either the project or the app.
Personal/Contact Information:
======================
Colin Williams
Computer Sciences Major
Stevens Institute of Technology, NJ, USA
[snip, privacy]
Project Proposal:
============
I propose to create and add a set of improvements to the dijit.Editor widget. The editor currently has a number of shortcomings that narrow the field in which it is applicable. These shortcomings include:
* HTML-only output. The rich text aspect of the editor understands and outputs only HTML tags. There are many other output formats that are used in a variety of applications, including BBCode (forums), Markdown (Wikis and bug tracking systems), and Wikitext (Mediawiki and other wikis).
* Rich Text Only. The current editor supports only rich text editing of its content. There is currently no easy method of viewing the HTML source of the content of the editor, nor viewing the content in any other format (see above). A scaled down version of this functionality can be previewed at [1] as of the time of this writing. I did not write this example, and I do not believe the solution the author discovered is a permanent one, but it provides a nice preview of what I hope to accomplish.
In addition to solving these shortcomings, I would like to add some features to the editor suite:
* Client-Side Parsing. When using a markup syntax other than HTML, client side parsers would eliminate the need to make a round-trip to the server to have the potential markup transformed into HTML for previewing. This would improve responsiveness of the application overall, as well as slightly reduce the bandwidth needed to support the application.
* Side-by-Side Previews. When not in the Rich Text mode of the editor, a side-by-side preview of the resulting HTML output would be extremely helpful and would contribute to the desktop application feel of a web application.
Timeline:
======
There are 7 weeks of suggested coding, with one extra week for non-core work. In addition to the overall coding aspects of the project I would spend at least one full day either every week or every other week devoted largely to documentation, refactoring and cleaning existing code, and writing tests.
* Before Beginning: I will have a week and a half before the summer of code officially begins to familiarize myself with the core of Dojo and the Editor widget. I expect to be able to familiarize myself enough to begin work when the summer starts on May 26th.
* Weeks 1, 2: Refactor to allow for direct access to the underlying source, for both read and write operations.
* Weeks 3, 4:Decouple the rendering of the Rich Text from the HTML source, introduce a "markup" layer between the source and the preview. Markup layers should have both a parser, to transform the source into HTML, and a reverse parser to transform basic HTML formatting (bold, italic, headers, horiz rules, line breaks, etc) into the syntax for that particular markup language.
* Week 5: Refactor to allow for 2 different views (tabs?) in the editor- Source view, and Preview. The source view displays the current source of the document being edited, in any markup language, and the preview displays the HTML formatted output of the markup language selected.
* Weeks 6, 7: Write and integrate several popular markup layers: BBCode, Markdown, and Wikitext are probably the most popular. I estimate about three days for each: one for writing/original debugging of the parser, one for the reverse parser, and one for more thorough testing/debugging.
* Week 8: Wrap up any existing problems and sloppy coding, polish things and complete tests and docs.
Schedule Constraints:
================
[snip, no feedback needed]
Prior Experience:
============
I have been programming in Java for 6 years, 5 of which have involved more than simple "Hello World" and printing applications :). I have been developing using web based languages for 4 years, starting with HTML, and continuing on to CSS, Javascript, PHP, and MySQL, largely in that order. In my web development pursuits, I place an emphasis on standards compliance and content/presentation separation. I have been working with Javascript and Ajax frameworks for 3 years, including a self-built, rough solution (before I discovered the wealth of pre-existing frameworks out there), and have since worked extensively with Prototype/Scriptaculous, jQuery, and now Dojo. I have not used Dojo before investigating it as a potential GSoC project, but I am in the process of delving into the code to learn more about it.
As far as previous contributions to OSS go, I have followed the development of the Symfony PHP framework for the past two years, and have contributed a little bit to it. I wrote a powerful and fully extensible BBCode parser class that can handle improperly nested and formatted codes, as well as any number of new tags. Although it would need to be ported to Javascript, I have the knowledge and ability to port or rewrite a similar parser. My experience with Symfony has also introduced me to version control systems, Subversion in particular. I have a basic knowledge of subversion commands and use.
The primary reason I have not contributed more is a lack of available time. During the school year, I have very little free time, too little to be able to actively follow the development of a major project enough to be able to contribute. I have had full time summer jobs for the past 5 years, leaving me with even less free time than during the school year. The stipend provided by Google will eliminate the need for a full-time job, leaving me free to spend the full work week working on my project throughout the summer.
Additional Questions:
===============
1. My primary interests in programming are front end programming and string manipulation. I've found that the development of modules which are comprised of a combination of these two, such as markup parsers and WYSIWIG editors have engaged my interest for longer periods of time and I've gotten much further along the path towards completion of a project. The best example of this that is available publicly is the BBCode parser plugin I wrote for Symfony (mentioned above)[2].
2. [snip, privacy]
3. This would be my full time job, and I do not anticipate having any other conflicting commitments.
4. Nope, never applied before.
5. Read and understood.
6. I'll be doing this in the next day or so and will include a link in the final version
[1] - http://wellhost.com/dojoedit.html
[2] - http://trac.symfony-project.com/wiki/sfBBCodeParserPlugin
Thanks for any feedback.

feedback
One way to fix the HTML-only output and Client-Side Parsing in the existing Editor is to use the existing pre-filter/post-filter mechanism in Editor. So basically, you can write a post filter to convert html to other format (such as wiki), and write a pre filter to convert other input format to html. (so instead doing what you proposed to do in week 3 and 4, you should probably use the pre/post filter mechanism)
I am not saying the pre/post filter in the current implementation is perfect (I think it should be separated out from the Editor code), but it is definitely something you should consider to use (and/or improve)
about html source viewer of the content, it was implemented in dojo 0.4 editor, you can port it as a plugin to trunk dijit
--
http://www.liucougar.net
生于忧患,死于安乐
"People's characters are strengthened through struggle against difficulties; they are weakened by comfort."
- Old Chinese adage