I'm wearing a nice little hat belonging to an average non-technical template designer. This is what I need:

email formatting

  • access to fields
    • date, mailto, mailfrom, subject, body, signature, ...
    • I18N and date formatting of the fields
  • labels wth I18N support
    • e.g. Date: <kt:date/>  vs. Datum: <kt:date/>
  • txt or html
  • keep whitespace in e.g. body
  • in case of html: skinning, background images (I guess we can't forbid it), ...
  • maybe some logic
    • if ($xml/signature) ...
    • foreach name do ...
      • where name can be a xpath expression or a delimiter separated textfield

xml data resources representation

  • access to fields
    • name, value, ...
    • I18N and date formatting of the fields
  • repeater/ foreach logic

generic page layout templating HTML

This will be the main case for templating related business.

  • access to fields
    • whatever the template is applied to ...
    • I18N and date formatting of the fields
  • labels wth I18N support
  • repeater/ foreach logic
    • iterate over a collection of entries of some kind
    • looping over list of lists
      • for x,y in points do ...
    • variable available with status information
      • index (starts from 0)
      • number (starts from 1)
      • letter (starts from A)
      • size of collection
      • revindex (reverse index)
      • revnumber (reverse number)
      • parentloop (for nested loop)
    • conditions in loop
      • ifchanged : e.g. only show date when it's different from the date in the previous record
      • odd - even
      • first - last
      • mod n
      • level n
      • these can be used to trigger css classes
  • expressions
    • date -> with formatting options , now()
    • concat
    • uppercase, lowercase
    • substring, left, right
    • trim
    • length
    • chain expressions in a non verbose way ?
      •  e.g. /data/x | trim | uppercase
  • conditional operators
    • test: if <condition> ... else ...
    • switch <condition> case con1 ... case conX ... otherwise ...
    • NVL(arg1,arg2)  or expr ? val1 : val2
  • conditions
    • startswith
    • endswith
    • contains
    • ==, !=, <, >, <=, >=
    • TRUE, FALSE
    • AND (&&), OR (||), NOT (!)
    • xpath expression: true if it exists and is not false and not null
  • javascript
    • insert js code => protect against formatting and escaping
  • java properties => indien nodig beter via context beschikbaar maken
  • URL, URI
    • url with arguments
    • input of base uri's from context
  • include
    • full document inclusion
    • inclusion of excerpt/blurb
  • advanced
    • declare variables (avoid doing same lookup of expression several times)
    • dynamic adding of attributes (cfr. xsl:attribute) and elements (xsl:element
  • ability to generate comments in output

  • I don't think we should add math functions such as floor(), ceiling() or (advanced) date functions such as addDays.
    If one wants to print e.g. tomorrow, this date should be available in the underlying dataset.

skinning and overriding

  • template inheritance mechanism
  • a possible system could be:
    • base-template.xml which defines one or more blocks/sections to override
      • this template could offer the home style for all documents, with e.g. company header and footer
    • section-template.xml which defines a more appropriate implementation of a block/section from the base template
      • there must be an indication of the base template, e.g. extends keyword
      • this could be used to enforce a section specific design
    • resource-template.xml which extends one or more of the appropriate section-templates.
    • The blocks/sections from "extended" parents that are marked as "overridable" but are not overridden, will literally be inherited.
  • easy applying of css-classes

complex interaction layouts

  • e.g. planning table
  • I guess this comes down to having some logic constructs available. See the part on html above.
    • TODO: can someone check this assumption ?

wireframing

  • no logic controller, no data ?
  • nothing new in case there is some data available, the user should be able to address resources locally
  • when there's no data, one can only write some stubs or static mockups

i18n ; template translation

  • this is relevant for all the previous cases
  • on one hand there is the issue of i18n: use the right decimal separator, date formatting, ...
    • this is handled by the framework, but it should be possible to
      • customize
      • add support for new languages
  • then there is the issue of labels (or globally template) translation
    • resourcebundle with properties-files
    • also allow to have different versions of templates for each supported language

JSON resource representation

  • most likely to be built up in java code
  • in case we build it in template: I guess a repeater and access to java-context should cover most needs

DHTML expansion at browser

  • subset of template language
  • TODO: any thoughts ?

Syntax suggestions - to be discussed

  • use attributes for optimal wysiwyg compatibility
  • variables should look something like $var, using a dot to access attributes e.g. $var.name

Some thoughts/questions - to be discussed

  • should or expression language be easy extendable ?
  • should we offer call-template-like macro functionality ?
  • can the framework guide the users in selecting css classes ? Even when the css files are indeed really cascaded ?
  • need for template-directed caching ? (inspiration from jxtemplate)
  • beware of issues regarding "stress" caused by multiple template includes - each needing declarations in the <head/> e.g. css, javascript

KTL Vision

What is our vision concerning the Kauri Template Language, or simply put: Why do we invent our own template language ?

  • we want to produce real XML, not plain text claiming to be well formed XML (this rules out 90% of the existing templating languages)
  • as we stated before in our expectations: "<developers want to> Be able to integrate and extend on wire-frame documents (during analysis) rather then to replace and rehash them. (=> allow collaboration and easier transition)"
  • people (even non technical) working on the wireframes and the templates should not be scared off by complexity
  • "everyone does it" : almost every framework has it's own template language. This may seem a bit childish, but it actually covers two reasons.
    • (for now) there don't seems to be an outstanding template language that's widely accepted
    • we (as do other frameworks) want some control in this important aspect of web development, so that if we want to change or add a certain feature we're not contrained by others. Of course it will be possible for users of Kauri to replace the KTL with another template language if they prefer.