Normal-Template

[George Moschovitis]

Dear devs

For some time now I am working on a new template system (to be used by
default with Nitro).
I just pushed the first version to github:

http://github.com/gmosx/normal-template

It's called Normal Template and you can read more details in the
README file (and the test cases).

I would *love* to hear some feedback and ideas before I finalize the
design of this template and make this the default template for Nitro.

regards,
George.

PS: I tried to use JSON-template until now, but I kept finding cases
where the 'cursor' paradigm created problems. The new template uses an
xpath like value selector and provides a useful meta-templating
mechanism.

[Roberto Saccon]

George,

this looks great to me, easy to use and well documented. I'll test it
asap. Only little detail I found mentioned, but not further explained
are filters, but I assume this are just simple functions (I used them
before in now-old templates). Maybe it would even make sense to
provide a default set of filters as in django.

--
Robertp

On Jan 22, 6:31 am, George Moschovitis <george.moschovi...@gmail.com>
wrote:

[George Moschovitis]

asap. Only little detail I found mentioned, but not further explained
are filters, but I assume this are just simple functions (I used them
before in now-old templates). Maybe it would even make sense to
provide a default set of filters as in django.

filters are like json-template formatters (maybe I will rename them to formatters, what do you think?)

a default set is provided. I will have to document this (and how to add custom filters/formatters)

basically a filter accepts a data dictionary value (or the output of another filter) and formats it...

filters can also be used for dynamic inclusion at run time (another thing to document)

-g.

 

--
Robertp

On Jan 22, 6:31 am, George  Moschovitis <george.moschovi...@gmail.com>
wrote:

> Dear devs
>
> For some time now I am working on a new template system (to be used by
> default with Nitro).
> I just pushed the first version to github:
>
> http://github.com/gmosx/normal-template
>
> It's called Normal Template and you can read more details in the
> README file (and the test cases).
>
> I would *love* to hear some feedback and ideas before I finalize the
> design of this template and make this the default template for Nitro.
>
> regards,
> George.
>
> PS: I tried to use JSON-template until now, but I kept finding cases
> where the 'cursor' paradigm created problems. The new template uses an
> xpath like value selector and provides a useful meta-templating
> mechanism.

--
You received this message because you are subscribed to the Google Groups "nitro-devel" group.
To post to this group, send email to nitro...@googlegroups.com.
To unsubscribe from this group, send email to nitro-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nitro-devel?hl=en.

--
http://www.gmosx.com/blog

[Roberto Saccon]

On Jan 22, 11:17 am, George Moschovitis <george-moschovi...@gmosx.com>
wrote:

> > asap. Only little detail I found mentioned, but not further explained
> > are filters, but I assume this are just simple functions (I used them
> > before in now-old templates). Maybe it would even make sense to
> > provide a default set of filters as in django.
>
> filters are like json-template formatters (maybe I will rename them to
> formatters, what do you think?)

django people might be used to "filters", anybody else will found
"formatters" more self-explanatory, no idea what is better ....

> > nitro-devel...@googlegroups.com<nitro-devel%2Bunsubscribe@googlegr oups.com>

[Tim Schaub]

George Moschovitis wrote:
> Dear devs
>
> For some time now I am working on a new template system (to be used by
> default with Nitro).
> I just pushed the first version to github:
>
> http://github.com/gmosx/normal-template
>
> It's called Normal Template and you can read more details in the
> README file (and the test cases).

Looks cool.

Looks like you've got a typo in the reduction data example (in README.md):

"articles": [
{ "Hello world", 34 },
{ "Another article", 23 },
{ "The final", 7 }
]

As with the usage example above, I think you mean:

articles: [
{ title: "Hello world", count: 34 },
{ title: "Another article", count: 23 },
{ title: "The final", count: 7 }
]

I'm curious about a couple things that I find useful in other template
languages. When iterating, it is often useful to get an index for the
entry and a count for the collection. Since you start each statement
with a reserved symbol, it looks like there would be room for something
like the following:

Data

var data = {collection: ["one", "two", "three"]}

Template

<table><tbody>
{:reduce collection}
<tr><td> {@index} </td><td> {=.} </td></tr>
{/:reduce}
</tbody></table>

Since reduce blocks can be nested, you could disambiguate the index and
count by allowing an argument like so:

{@index 0} - default, index for current block
{@index 1} - index of first parent block

Anyway, something like that would be useful to get index and count in a
reduce.

Also, perhaps it is just me, but I like iterating over members in an
object (`for (var key in obj)` style).

Data

var data = {obj: {chicken: "soup", dog: "food"}}

Template

{:reduce obj}
{@key} {=.} {#} first one should be "chicken soup" {/#}
{/:reduce}

And yeah, comments are nice.

Tim

[George Moschovitis]

Looks like you've got a typo in the reduction data example (in README.md):

...   articles: [

       { title: "Hello world", count: 34 },
       { title: "Another article", count: 23 },
       { title: "The final", count: 7 }
   ]

thanks, will fix it, there are some other things missing from the docs, for example how to setup custom filters...
will update the docs.

   <table><tbody>
   {:reduce collection}
       <tr><td> {@index} </td><td> {=.} </td></tr>
   {/:reduce}
   </tbody></table>

hmm, this is an interesting suggestion, on the other hand I would like to keep the template simple, you could just put the index in the data dictionary.
on the other hand this seems easy to implement

Also, perhaps it is just me, but I like iterating over members in an object (`for (var key in obj)` style).

Data

   var data = {obj: {chicken: "soup", dog: "food"}}

Template

   {:reduce obj}
       {@key} {=.}  {#} first one should be "chicken soup" {/#}
   {/:reduce}

this looks too javascriptish to me, I would like to keep the template language agnostic.
(I plan versions for other languages)

And yeah, comments are nice.

Comments are supported:

{:! this is a comment }


thanks for the great ideas, I 'll consider them!

-g.


 

Tim

I would *love* to hear some feedback and ideas before I finalize the
design of this template and make this the default template for Nitro.

regards,
George.

PS: I tried to use JSON-template until now, but I kept finding cases
where the 'cursor' paradigm created problems. The new template uses an
xpath like value selector and provides a useful meta-templating
mechanism.

--
You received this message because you are subscribed to the Google Groups "nitro-devel" group.
To post to this group, send email to nitro...@googlegroups.com.

To unsubscribe from this group, send email to nitro-devel...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/nitro-devel?hl=en.

--
http://www.gmosx.com/blog

[George Moschovitis]

BTW, the README is updated with your fixes and some info about custom filters.

-g.

--
http://www.gmosx.com/blog

[Tim Schaub]

George Moschovitis wrote:

... snip ...

>
> hmm, this is an interesting suggestion, on the other hand I would like to
> keep the template simple, you could just put the index in the data
> dictionary.
> on the other hand this seems easy to implement

Understood (about adding to dictionary).

My feeling on that is that a nice template language should be able to
work with data that you don't control. There are some useful JSON
"standard" data structures popping up. I like the idea of being able to
interoperate with other applications without doing a lot of data
massaging on the template language's behalf.

Iterating over members in an object and elements in a array have analogs
in most languages.

Tim

>> nitro-devel...@googlegroups.com<nitro-devel%2Bunsu...@googlegroups.com>

>> .
>> For more options, visit this group at
>> http://groups.google.com/group/nitro-devel?hl=en.
>>
>>
>
>

--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[George Moschovitis]

Understood (about adding to dictionary).

My feeling on that is that a nice template language should be able to work with data that you don't control.  There are some useful JSON "standard" data structures popping up.  I like the idea of being able to interoperate with other applications without doing a lot of data massaging on the template language's behalf.

Iterating over members in an object and elements in a array have analogs in most languages.

Sounds reasonable. I am wondering what other people think about this.

-g.

 

--
http://www.gmosx.com/blog

[George Moschovitis]

I am thinking about allowing for custom 'commands'/'tags' like the custom filters. If I add custom tags the you can add a new tag (for example a localization tag, {:l}string to localize{/:l} or update an existing tag (i.e. update :reduce to emit @index like you suggested).

opinions?

-g.

--
http://www.gmosx.com/blog