New template feature: filters (e.g. lower case, strip, etc)

[RhetTbull]

I'm in the middle of a complete re-write of the template system (see #363 ) that will make the template system much more capable. You'll be able to use any template field as a boolean and also nest templates.

e.g. export photos to directory based on album name, unless photos aren't in an album, then export by date:

--directory "{inalbum?{album},{created.year/created.mm}}"

This also opens the possibility to do other things such as add filters to transform results of a field, for example, output all keywords as lower case. I'm experimenting with different syntax for this and would be glad to have any feedback on what is easier to read.

1. The easiest implementation (which I currently have prototyped) makes the filters just another field:
   {lower,{keyword}} takes results of {keyword} and makes it lowercase
   These can be stacked, for example:
   {parens,{lower,{keyword}}} takes the result of keywords, makes it lower case and then adds parentheses around each keyword. e.g. transforms 'Keyword1', 'Keyword2' to '(keyword1)', '(keyword2)'

2. Add a new optional modifier to each field using <>. () is currently used for path separator and [] for find/replace:
   {keyword<lower>}
   and to stack these:
   {keyword<lower,parens>}

Current filters are lower case, upper case, strip whitespace, add parentheses, add brackets, add curly braces

[RhetTbull]

A third option I toyed with is to use "dot notation", e.g.
{keyword.lower}
{keyword.lower.parens}

But it seems to me this causes some confusion with keywords which already use dot in the name, e.g.
{place.address.city}
vs
{place.address.city.lower}

and means that filter names would always have to be disambiguated from field names.

[neilpa]

One familiar pattern is to use pipeline style syntax, e.g. { keyword | lower }.

However, if you're going to start adding functions you may be better off using an out of the box templating engine rather than crafting a new syntax from scratch. I'm not familiar with the python ecosystem here but a couple things I've used before that you could at least draw inspiration from are mustache and the go template package.

[RhetTbull]

Thanks! I’ll take a look at those two. osxphotos already uses mako internally for XMP file generation. I don’t want to get to crazy and I initially rolled my own for the following reasons:

1. Wanted the simple cases to be really simple and user to not have to know python or another language
2. Needed to handle template values that return lists and ones that return scalars. Eg. —directory and —filename can resolve to more than one value if used with a template like {album} and photo is in more than one album. When I first looked at other options, this was the hardest requirement to satisfy.

I would prefer to keep backwards compatibility with the existing templates. Pipe might be a good option as it’s clear to anyone familiar with unix-style filters what’s happening and what order it’s happening.