Jinja2 Template Implementation

Currently

Thoughts and decisions about the project can be found here: DiogenesAugusto/GSoC2010/Diary

Today: DiogenesAugusto/GSoC2010/Diary/2010-05-24

Problems

None yet.

Goals

Implement Themeing with Jinja2
-> Read documentation

Implementationg ideas / notes

General

Theme needs to work cross-browser and should be tested with the usual browsers:
- Firefox
- Chrome
- Opera
- Safari (if possible)
- Internet Explorer 7/8
- IE6 basic support?
  - I suggest dropping all support for IE6 (actually, I would drop IE7 support as well and I am a Windows user). The current CSS is a mess partly because IE6 support is built in. Encouraging IE6 users to upgrade to anything newer is doing them a favor. -- RogerHaase 2010-05-02 13:09:51
  - http://www.ie6nomore.com http://www.ie7nomore.com/
  - Currently, 16% of users are still using IE6. But, time works for us, it will be less in future and moin2 will take a while still until it will be used in production.
  - There is a plugin http://plugins.jquery.com/node/11869 to add IE6 support. Currently slow and needs better docs.
Accessibility! Please follow accessibility guidelines (moin users with special knowledge about this, please watch how theme develops).

Theme user interface

be more pretty than moin 1.x default themes
avoid user confusion about "item name in navigation area" vs. "document title", see FeatureRequests/AvoidPageNameDocumentTitleConfusion
be less magic than 1.x, e.g.:
- rather have a "what links here" action than having to know that this is done by clicking on the page name

Templating infrastructure

how to feed the templates with the infos they need?
do it like "flask" or is that too simple for us?
- why I would use flask?

Forms

need XSS protection (see recent problems in moin 1.x) - should be done at one place and re-used everywhere (not copy&paste!).
use some library for filling in forms / evaluating/validating POST data?
- Maybe WTForms? I know that Glashammer team are not happy with it, but I don't know another project that do this. (AliAfshar, Glashammer: I find wtforms restrictive. The best validation/verification/serialization form framework I have found is flatland.)

Icons/Images

need to be separated into:
- content icons (smileys, used with wiki markup) and
- icons used by theme
maybe (file) names need cleanup, too: FeatureRequests/SanitizeIconFilenames
SVG? +1 RB (this solves any scalibility problems of other icon mimetypes. see e.g. svg-edit)

CSS

needs restructuring / redoing from scratch? 1.9 stuff has grown over the years.
stuff like changing colors (but keeping rest of theme same) should be easy
css class/id names need to have some prefix to avoid stuff like MoinMoinBugs/HeadingPreviewRendered and also conflicts with extensions
- maybe mmpreview instead of just preview?
- Maybe headings should have special prefix (which will not be used in ids/classes of theme) to avoid overlapping?
- Prefixes don't exactly solve the duplications, they just move the problem up to a second level (i.e. you can still have duplication under the same prefix). I'm not a big fan of complicated ids, but we could use the module name as prefix, and have a per-file id management, which would be easier than checking the whole source code (current behavior). For example, if my module is MoinMoin.theme.jinja, we could have:
```
   1 import MoinMoin.support.id
   2 
   3 # This would give us "theme-jinja-preview".
   4 id_for_my_element = id.get(__name__, 'preview')
```
  Where get is defined as below:
```
   1 def get(module_name, single_id):
   2     return '%s-%s' % (module_name.replace('MoinMoin.', '').replace('.', '-'), single_id)
```
  - No, we have way to generate (output document)-wide unique header ID's (at least, it should generate them so). So, the only problem is dividing ID name space into parts. Because (standard) theme-related ID's are controlled by theme author and not generated, they can have no prefix. On the other hand, plugin-generated and content-generated (i mean, ID generation based on content) IDs are likely random, so should be prefixed (for example, like the way you have proposed). System of prefixes (this would be mostly like guidelines for code authors) should guarantee that ID's will never have collision (it already is in your proposition). Possible system (guideline) may also contain something like this:
    - Specific theme IDs — theme-<theme_name>- (or use something you have proposed)
    - Specific plugin IDs — <plugin_type>-<plugin_name>- (or use something you have proposed)
    - Header IDs — header-
    - Anchor IDs — anchor-
    - Line IDs (btw, they already are) — line-
    - Generic (top, bottom, begin of content, menu, preview, what else?) IDs — no prefix (and avoid ID names starting with all prefixes mentioned above — it should be set, constant and non-growing between minor revisions)
    I hope this should solve any similar problems in future. Also, we shouldn't forget about classes (both in naming guidelines and ability to use them). — EugeneSyromyatnikov
- see also MoinMoinBugs/HeadingIdConfusion

Template Loading

   1 def load_theme_fallback(request, theme_name=None):
   2     """ Try loading a theme, falling back to defaults on error.
   3 
   4     @param request: moin request
   5     @param theme_name: the name of the theme
   6     @type theme_name: str
   7     @rtype: int
   8     @return: A statuscode for how successful the loading was
   9              0 - theme was loaded
  10              1 - fallback to default theme
  11              2 - serious fallback to builtin theme
  12     """
  13     fallback = 0
  14     try:
  15         request.theme = load_theme(request, theme_name)
  16     except ThemeNotFound:
  17         fallback = 1
  18         try:
  19             request.theme = load_theme(request, request.cfg.theme_default)
  20         except ThemeNotFound:
  21             fallback = 2
  22             from MoinMoin.theme.modernized import Theme
  23             request.theme = Theme(request)

But I think the right is use the Jinja loaders to do this. Can I replace and add some tests? Jinja Loaders - http://jinja.pocoo.org/2/documentation/api#loaders

CategoryGsocProject

MoinMoin: Jinja 2010