|
Size: 2195
Comment: Redid page to reflect actual project
|
Size: 4542
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma page-filename DEV/versions/162 [[http://mindlace.net|Ethan Fremen]] has been [[http://code.google.com/soc/psf/appinfo.html?csaid=7124F8A458101E5A|accepted by Google]] to work on the Web UI for mailman in 2006. The project will port mailman's web interface to one implemented in Kid in order to improve the I and enable better handling of i18n. |
#pragma page-filename DEV/versions/185 [[http://mindlace.net|Ethan Fremen]] is working on mailman for his [[http://code.google.com/soc/psf/appinfo.html?csaid=7124F8A458101E5A|Summer of Code Project]]. The project will use web standards, kid and mod_python to deliver a superior HTTP user experience with enhanced internationalization. |
| Line 4: | Line 4: |
| == Status == June 15, 2006: |
== Status June 21, 2006 == After realizing how utterly horked the current templating situation is, I've started redoing the templates as xhtml/kid. Once I'm done with that, I'll write the glue code that connects it into mailman, leveraging the existing work in Gui/ . |
| Line 7: | Line 7: |
| * Initial conversion of syntax to kid started. * Began unwinding MM- pseudo-syntax. * Got ball rolling on how to help the i18n crew. * I'm behind - I had two conferences to attend that ate more of my life than expected. I expect to catch up before June 23. |
I've added an "options" page that will show the set of forms a user has available to them at the moment. As this is my first i18n project, I wasn't quite aware of what it entailed. Right now I'm focusing on making it so a simple iteration over all elements in the pre-rendered DOM constitutes the entirety of the text that needs to be internationalized for the web UI. == Technical Plan == * Build a fully [[http://www.w3.org/WAI/|accessible]] web interface using xhtml without CSS or JavaScript. * Enhance that interface with CSS to make it visually intuitive. * Add JavaScript that provides additional ease of use. * Modules/Supporting logic modules, to be implemented or borrowed: * Converters * RFC-8222 into an ElementTree * .mbox files into an ElementTree * Elemental RFC-8222, mbox into xhtml * Elemental mbox into xhtml * Handlers (mod_python) * feed handler * authentication handler * fragment handler - provides fragments of the UI and accepts 'fragmented' form submissions for XMLHttp / REST access. * Modules * glue code to patch the 1-user-per-list situation * Filters (mod_python) * uniquer - take outgoing xml and render the ids within unique to mailman/the page. Would need helper JS to know how to decouple, but as only the JS really cares about the ids anyway, we can avoid problems. Primary need for this is auto-labeling for attributes on label and providing an ID namespace that doesn't collide with whatever page it's embedded in. * bugfr --( "bug friend" )-- performs last minute dom/css/js munging to kludge for broken clients. this way all the inevitable client-specific workarounds don't make their way into the templates. == Notes == I've had to move away from the incremental approach and towards a reimplementation. I'm still working strictly from the existing implementation for feature-set, but because of the templating situation, I'll get there faster if I re-write the templates. The decision to move to mod_python is based on the need for feed handlers that can maintain a semi-persistent cache and because I get access to Apache's internals. The existing CGI interface will be untouched, with the idea that eventually a wrapper will be found/written that provides backwards compatibility. [[http://www.campaignmonitor.com/|Campaign monitor]] is an interesting example of what people who run list-like things want from their webui === Existing templating situation === * There's a mismash of MM- pseudo tags and python str/dict replacement for variable substitutions. * Many pages are generated by a sort of proto-dom. * All the pages are mid-90's tag soup, with upper case and lower case tags and invalid html attributes. * Many pieces of code generate strings with html markup. This is bad form and makes i18n/multiple interfaces harder. |
| Line 12: | Line 43: |
| * May 23 - 28: Convert Mailman interface to use Kid, retaining all functionality as-is. * May 29 - June 9: Change i18n approach to one that leverages gettext. * June 12 - 16: Write templates to provide a navigation interface for archive browsing. Write templates to provide an RSS/Atom feed for mailing lists. * June 19 - 23: Polish documentation for interface changes and deliver mid-term release. * June 26 - 30: Provide consistent navigation throughout the Mailman interface, working from the navigation templates built for the archives. Enhance the Administrator's user listing to allow for bulk modification and to highlight users that have been set nomail. * July 3 - 14: Change the mailman 'options' from being a set of Text:Action pairs presented in a two-column table to one that uses the available space more effectively to present the most important options to the user. Don't display options not available to the user. * July 17 - 21: Collapse pages, e.g the default admin/listinfo pages, that should be the same page. * July 24 - 31: Separate pages into pieces that can comfortably be embedded into non-Mailman pages. Add kupu/tinyMCE page-editing, easy support for stylesheet changes, site and list specific themes. |
* May 23 - June 21: Rewrite mailman interface using xhtml templates with the following attributes: * Provide consistent navigation throughout the Mailman interface * Enhance the Administrator's user listing to allow for bulk modification and to highlight users that have been set nomail. * Collapse duplicate pages * Write pages in seperable, embeddable pieces. * June 23- June 30: Establish the scope of the glue modules, and write interfaces/stub classes. * July 3 --( 14: Write handlers and RFC8222/ mbox \)--> ElementTree converter * July 17 - 21: Fill in glue modules, with knowledge of how the (user)db-in-SQLAlchemy project is going. * July 24 - 31: Add page-editing, easy support for stylesheet changes, site and list specific themes. |
| Line 21: | Line 53: |
| * August 7 - 11: Integrate any revision suggestions and make a second release. * August 14 - 21: Accommodate schedule slippage and add additional documentation / release / integration / upgrade code as necessary. |
* August 7 - 11: Add ease-of-use JavaScript/CSS. * August 14 - 21: Merge branch to trunk, and make a release of some sort. ''"a plan is just a list of things that never happen" - Benecio del Torro in The Way of the Gun'' |
Ethan Fremen is working on mailman for his Summer of Code Project. The project will use web standards, kid and mod_python to deliver a superior HTTP user experience with enhanced internationalization.
Status June 21, 2006
After realizing how utterly horked the current templating situation is, I've started redoing the templates as xhtml/kid. Once I'm done with that, I'll write the glue code that connects it into mailman, leveraging the existing work in Gui/ .
I've added an "options" page that will show the set of forms a user has available to them at the moment.
As this is my first i18n project, I wasn't quite aware of what it entailed. Right now I'm focusing on making it so a simple iteration over all elements in the pre-rendered DOM constitutes the entirety of the text that needs to be internationalized for the web UI.
Technical Plan
Build a fully accessible web interface using xhtml without CSS or JavaScript.
- Enhance that interface with CSS to make it visually intuitive.
Add JavaScript that provides additional ease of use.
- Modules/Supporting logic modules, to be implemented or borrowed:
- Converters
RFC-8222 into an ElementTree
.mbox files into an ElementTree
- Elemental RFC-8222, mbox into xhtml
- Elemental mbox into xhtml
- Handlers (mod_python)
- feed handler
- authentication handler
- fragment handler - provides fragments of the UI and accepts 'fragmented' form submissions for XMLHttp / REST access.
- Modules
- glue code to patch the 1-user-per-list situation
- Filters (mod_python)
- uniquer - take outgoing xml and render the ids within unique to mailman/the page. Would need helper JS to know how to decouple, but as only the JS really cares about the ids anyway, we can avoid problems. Primary need for this is auto-labeling for attributes on label and providing an ID namespace that doesn't collide with whatever page it's embedded in.
bugfr "bug friend" performs last minute dom/css/js munging to kludge for broken clients. this way all the inevitable client-specific workarounds don't make their way into the templates.
- Converters
Notes
I've had to move away from the incremental approach and towards a reimplementation. I'm still working strictly from the existing implementation for feature-set, but because of the templating situation, I'll get there faster if I re-write the templates.
The decision to move to mod_python is based on the need for feed handlers that can maintain a semi-persistent cache and because I get access to Apache's internals. The existing CGI interface will be untouched, with the idea that eventually a wrapper will be found/written that provides backwards compatibility.
Campaign monitor is an interesting example of what people who run list-like things want from their webui
Existing templating situation
- There's a mismash of MM- pseudo tags and python str/dict replacement for variable substitutions.
- Many pages are generated by a sort of proto-dom.
- All the pages are mid-90's tag soup, with upper case and lower case tags and invalid html attributes.
- Many pieces of code generate strings with html markup. This is bad form and makes i18n/multiple interfaces harder.
Timeline
- May 23 - June 21: Rewrite mailman interface using xhtml templates with the following attributes:
- Provide consistent navigation throughout the Mailman interface
- Enhance the Administrator's user listing to allow for bulk modification and to highlight users that have been set nomail.
- Collapse duplicate pages
- Write pages in seperable, embeddable pieces.
- June 23- June 30: Establish the scope of the glue modules, and write interfaces/stub classes.
July 3 14: Write handlers and RFC8222/ mbox \> ElementTree converter
- July 17 - 21: Fill in glue modules, with knowledge of how the (user)db-in-SQLAlchemy project is going.
- July 24 - 31: Add page-editing, easy support for stylesheet changes, site and list specific themes.
- August 1 - 4: Update documentation to reflect changes.
- August 7 - 11: Add ease-of-use JavaScript/CSS.
- August 14 - 21: Merge branch to trunk, and make a release of some sort.
"a plan is just a list of things that never happen" - Benecio del Torro in The Way of the Gun