Feature announcement for Snippetory 0.9.5

Conditional Regions

For a long time I have been thinking about conditional sections. I always thought to need a special syntax for this. This would have added complexity to the system and the directions I thought about it’d be hard to integrate into the XML_ALIKE syntax. But now that I made the name for locations optional I analyzed this for regions, too. And I figured out that t: is a valid tag name in XML. Thus I’ll simply make them nameless sections. I think this is pretty intuitive and doesn’t require a new syntactical construct. Like nameless locations need at least one attribute to make sense, nameless regions need at least one named(!) location (or region) to make sense. It will only be rendered if a none-null value is written to at least one of the enclosed named locations. It doesn’t matter if the set, append, or render method is used. Conditional regions are fully transparent on java site. Names defined in conditional regions appear exactly as they were defined outside.

Unfortunately, C comments syntax is not able to support conditional regions this way as it uses the name (that’s repeated at the end) to distinguish regions from ordinary locations. However, I consider removing C comments syntax anyway as it follows an approach contrary to the one of Fluyt.

</pre>
<table>
<tbody>
<tr>
<th>{v: msg='product.name'}</th>
<th>{v: msg='cart.count'}</th>
<th>{v: msg='cart.price'}</th>
</tr>
<tr>
<td>{v:name}

<hr />

{v:hint}</td>
<td>{v:count}</td>
<td>{v:price} {v:currency)</td>
</tr>
</tbody>
</table>
<pre>

Of course conditional regions can be nested. In fact I expect this to be a typical use case. However, conditional regions serve another purpose: They can provide meta data that spans over several other locations, but not a complete named region. Adding another named region would affect binding logic, even though the issue is bound to technical or presentational purposes.


{v: msg='product.name' strech='30'} {v: msg='cart.count' strech='9r'} {v: msg='cart.price' strech='16r`}
===========================================================

{v:name strech='30'               } {v:count strech='9r`            } {v:price} {v:currency)

{v:hint}

{v: default='' strech=`40r`                                         } ----------------
{v: msg='cart.sum' strech=`40r`                                     } {v:price} {v:currency)

Formatting interface

Another big topic is the re-design of the formatting. There is quite a number of features I want to add:

  • Multiple attributes per Formatter.
  • Formatter should consume data, that is provided via set method calls
  • Better handling of status for formatters.
  • Control over encoding. Thus they need to know about the target encoding, and have to be able to define the encoding they return.
  • Distinction between the convention of a provided null value and no value at all
  • Multi-step conversion

This will be done by providing an additional interface for most of the features and change the return
type of the format method to Object.

New syntax: Fluyt

Looking around on other engines I recognized a tendency to provide razor-like syntax. Razor is a template
syntax for .net. It’s very brief and sparse with letters. Though, I thought it would be nice to have a
syntax, that’s not that wordy and more consistent within itself (first) and to others (maybe I’ll build
a complete syntax family upon Fluyt). Even though razor gave the idea, Fluyt is not really based on
razor.

Fluyt will be reduced to a single syntactical element consisting on 3 segments. Each segment is optional,
but there has to be at least one. The segments are:

  • Name
  • Meta data (surrounded by round brackets)
  • A template region (I’m not yet really sure how to do it, but most likely curly brackets will be involved. At the moment I prefer single curly brackets with an additional dollar sign for closing. Between the bracket and the dollar the name can be repeated for optional sanity.
$[<name>][([<atribute>='value'...])][{<content area>}[<name>]$]

In addition we have the 3-slash-comment from C_COMMENT syntax and the normal syntax selector.

$cart{
$(msg='product.name' strech='30') $(msg='cart.count' strech='9r') $(msg='cart.price' strech='16r`)
===========================================================
$cart-entry{
/// we can define the length of the complete expression "$price $currency" with a continual region
$name(strech='30' ) $count(strech='9r` ) $(strech='16r'){$price $currency}$
${
$hint
}$
/// This name is optional. But it makes it simpler to follow the source.
}cart-entry$
$(default='' strech=`40r` ) ----------------
$(msg='cart.sum' strech=`40r` ) $(strech='16r){$price $currency}$
/// this regions closes without giving its name 'cart'
}$

More information on jproggy.org

About these ads