= 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 <> * [[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: {{{#!highlight python import MoinMoin.support.id # This would give us "theme-jinja-preview". id_for_my_element = id.get(__name__, 'preview') }}} Where `get` is defined as below: {{{#!highlight python def get(module_name, single_id): 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--` (or use something you have proposed) * Specific plugin IDs — `--` (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 === {{{#!highlight python def load_theme_fallback(request, theme_name=None): """ Try loading a theme, falling back to defaults on error. @param request: moin request @param theme_name: the name of the theme @type theme_name: str @rtype: int @return: A statuscode for how successful the loading was 0 - theme was loaded 1 - fallback to default theme 2 - serious fallback to builtin theme """ fallback = 0 try: request.theme = load_theme(request, theme_name) except ThemeNotFound: fallback = 1 try: request.theme = load_theme(request, request.cfg.theme_default) except ThemeNotFound: fallback = 2 from MoinMoin.theme.modernized import Theme 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