**hello** world
* Decorator for generating HTML based on client-agent.
* Ruby's code-block style syntax to write event-handlers for tag-elements.
* Automatically detect the user-agent compatibility level with html and
generate elements in confirmance to it. This must play safe with the
following knobs,
- doctype specification in ttl file
- encoding specification in ttl file
- language specification in ttl file
- config params passed to compile the ttl file
- HTTP headers (or any other real-time info available from user agent)
denoting the user agent capabilities.
* Just saw Adobe Egdge ... Can tayra be the keyboard version for addressing
the same market place as Adobe's ?
* Micro-templating similar to mako. This will demonstrate the true power of
StackMachine based design.
This requires a change in the filter-block syntax and symantics. It would be
better if it is possible to parse the filter-block as signature + siblings.
* Implement them using parser grammar. Once mature the core implementation
can be ported to C and bolted with many other general pupose languages like
Java, Ruby, PHP etc ...
* Pure sandboxing in python is not entirely possible. Nevertheless pypy
is providing the sandboxing feature, which can be used if required. Some ideas
for sandboxing,
* try __builtins__ = {}
* Avoid passing any objects via which a module object is accessible.
* Parse the python code found in control blocks, function params,
and exression substitution and kick out the compromising parts.
* Template authors are responsible for the code that they are writing, along
with the plugins that they are going to use. The way in which the security
can be breached beyond the control of the application developer is when
anonymous code gets evaluated in the templates context.
* Tayra does not use eval anywhere during the compilation process and the
expression text in expression substitution ${ ... } is directly placed as
python code.
* So as long as the developers do not use eval() anywhere in their template
text, I guess things should be fairly safe.
* May be I am wrong and I would love to stand corrected.
* From stackoverflow,
http://stackoverflow.com/questions/3558119/are-self-closing-tags-valid-in-html5
a self-closing div will not validate. This is because a div is a normal
element, not a void element. According to the spec, tags that cannot have
any contents (known as void elements) can be self-closing*. This includes
the following tags:
area, base, br, col, command, embed, hr, img, input,
keygen, link, meta, param, source, track, wbr
The "/" is completely optional on the above tags, however, so
is not
different from
, but
is invalid.
So tayra automatically removes any self-closing tags from TAGBEGIN token and
subsequently tag-handlers under tayra.tags package will generate
format
for void-elements.
Release check-list
------------------
- Sphinx doc quick-start, one time activity.
sphinx-quickstart # And follow the prompts.
sphinx-apidoc -f -d 2 -T -o docs/ tayra $(APIDOC_EXCLUDE_PATH)
- Change the release version in ./CHANGELOG.rst, ./tayra/__init__.py
- Update TODO.rst if any, because both CHANGELOG.rst and TODO.rst are referred
by README.rst.
- Check whether release changelogs in CHANGELOG.rst have their release-timeline
logged, atleast uptill the previous release.
- Update setup.py and MANIFEST.in for release
- Make sure that sphinxdoc/modules/ has all the modules that need to be
documented.
- Enter virtual environment and upload the source into pypi.
make upload
- Upload documentation zip.
- If ttl vim-plugin was updated, package and upload to vim script repository
- After making the release, taging the branch, increment the version number.
- Create a tag and push the tagged branch to
code.google.com
bitbucket.com
github.com