Re: [FreeMarker-user] FW: crud screens and null.

[Daniel D. <dd...@fr...>]

Tuesday, May 9, 2006, 5:11:44 PM, Vladimir Olenin wrote:

> Ok. Since this has become such a hot topic... Personally I think
>
> ${xxx!''}
>
> or, even better,
>
> ${xxx?''}
>
> , since the latter minimizes the number of unique special characters, is
> OK! I think it'd be much better to implement ANY of the above and get it
> over with as soon as possible, since the ?default construct is really
> quite verbose.

Well, "!" is used for logical not... this was why I preferred it over
"?" in the template language, that doesn't have the "built-ins"
feature. But FTL has "built-ins" and they use ? already. So things
like ${foo?aVariable} would syntactically look as a built-in
invocation, hence we can't use "?" for specifying default values. I
hope we have no ambiguity with "!" too... yes, it's used for logical
not already, but the logical not operator can't occur at the end of
expressions, so it's maybe not a ambiguity.

> I want to bring up another topic though. What is considered to be an
> 'non existent' hash? Right now there is a distinction between
> 'non-existent' and 'empty string' (?has_content or ?is_empty vs
> ?default).

Yes. And there is not such thing as non-existent hash (or non-existent
string, or non-existent number, etc). If something is non-existent,
then it has no type.

> The problem is that right now it is quite hard to implement _cleanly_
> replacement of an empty OR non-existent string variable with some
> default value, eg:
>
> ${xxx?default(' ')}
>
> 'xxx' would be replaced ONLY if it doesn't exist. If it is just an empty
> string (which is often the case when you are pulling data from some 3rd
> partly data source), the 'xxx' value (ie, '') would be displayed. And
> this creates a problem, especially when you are creating HTML tables,
> since browsers (quite a few of them, even the most recent ones), would
> 'merge' table cells if it is empty, so, placing a ' ' there is
> standard trick to prevent it.
>
> Appending ' ' by default to all values:
>
> ${xxx?default('')} 
>
> Is not very good as well, since if 'xxx' does have a value, the above
> script will generate 'xxx?length'+1 characters. In most cases it's not a
> problem, but there are some cases (eg, output of statistical data) where
> 'xxx' is either one character or none, in which case column width should
> always be 1 character.
>
> In other words, it would have been very useful to have some special
> notation to replace empty strings with default values.
>
> One possibility can be this:
>
> ${xxx?'def'} --- shortcut for '?default' built-in. Uses default value
> ONLY if 'xxx' does NOT exist
> ${xxx!'def'} --- a special case of ${xxx?'def'} construct, when default
> value is used if 'xxx' does not exist OR is an empty string.

Well, output formatting *is* a complex thing (and thus do promise a
specialized language), whatever KISS-template-engine advocates are
saying. Still, even if we have no ambiguity with ? (we may can find
other character for that anyway), I would not recommend this solution.
I know about the tricky cases that you mention, but I also think that
doing a few more verbose/awkward solutions sometimes is still better
than if the majority of people is confused about the fine differences
between two kind of existence handler built-ins. For the concrete
problem you have shown, I recommending this: xxx!''?empty_to_nbsp,
where the "empty_to_nbsp" built-in was not added yet (nor the !
operator).

So, I propose adding the "empty_to_nbsp" built-in, since I have faced
this problem with tables often too.

> Vlad

-- 
Best regards,
 Daniel Dekany