Helma Logo
main list history
previous version  overview  next version

Version 27 by tobi on 26. June 2006, 14:57

From our experience with Helma's skin templating features we came to the following general conclusions for further developments in version 2.0:

# Helma core has to remain as simple as we know it.
# Separation of presentation and logic has priority.
# Backwards-compatibility is required in any way.
# Other concepts (templating engines) should only be considered as pluggable extensions to helma.

That's why we come up with a

== Rather rigid specification ==

# Skin files can contain more than one skin meaning we can have similar structures with skins as we already have with JavaScript functions. (Yes, the skin file's name is irrelevant, then.)
# A skin is identified via a label using a new syntax (open for discussion, I am using three hash marks in the example).
# There is only one single level of label hierarchy, ie. a flat collection of labels.
# Skin labels are to be used as reference in functions and macros. This provides both, familiar access to as well as advanced rendering (loops, switch/case-like conditions?) of skins.
# Skins can contain local symbols (or call it variables) containing a string value that can be re-used throughout one single skin. (Syntax open for discussion.)
# Macros in skins are delimited by <% %>.
# There are no nested macros in macros. (I know, this will hardly stand the desire.)
# Object mappings extend the macro handler for easier access to properties of the contained object.

...and some

== Rather vague wishes ==

# Each HopObject contains certain macros from scratch (e.g. loop w/ sorting, skin embedding etc.) -> scaffolding!
# HopObject properties and the corresponding form input in a skin (display, check, error messaging) are firmly and closely connected, generally and finally.
# Certain macros already come implemented with useful parameter options. E.g. if the macro renders a number it should provide a way for reflecting the amount in the measure unit like "no comment", "one comment", "5 comments".

== Example file ==

    <% define greeting="Hello" %>
    <% greeting %>, <% session.user.name %>!
    <% this.render skin="time" %>.
    There are currently <% this.users.size %> other users
    logged in:
    <% this.users.loop skin="user" %>
    <% now format="EEE, dd.MM.yyyy, HH:mm'h'" %>
    Today is <% this.render skin="now" %>.
    <% greeting %>, <% user.name %>!

The imagined output of rendering the above skin:

    Hello, Brian!
    Today is Wed, 15.02.2006, 15:31h.
    There are currently 3 other users logged in:
    Hello, Adele!
    Hello, Carver!
    Hello, Diane!

<a name="cpt"></a>
== "Common Proposal Task" scenario  ==
# Helma is automagically mapping all 1:1 child objects and 1:n collections of the current path handler to global handlers.
# There is a HopObject-wide <code>count</code> macro that takes three additional parameters called "none", "one" and "many" of which only many is rendered with the calculated number of items.
# topic.counter is a macro that gets its function body newly assigned each iteration.
# Inline skins work similar to HTML anchor elements. Helma should stop rendering the skin itself as soon as it detects an <code><% anchor %></code> macro. With each following occurence of an <code><% anchor %></code> the previous anchor skin is ended and a new one begins.

  <small>(sorry, I currently have no idea what this headerlist thing is about...)</small>
  <% topics.count
      prefix="Number of topics: "
      none="no topics"
      one="1 topic"
      many=" topics" %>
  <% topics.list
      skin="#topicItem" %>
  <% anchor name="#topicItem" %>
  <td <% topic.counter odd='style="background-color: yellow;"' %>>
  <% topic.name %>
  <% topic.count prefix="(" suffix=")" %>