Andreas Schamberger a écrit :
> Hi,
>
>>> What I heretofore propose is that
>>> A - newlines always be preserved after the closing brace of a
>>> statement!
>>> B - if this radical change is not welcome, an option is added,
>>> either as part
>>> of the context object or separately, that decides on the fate of
>>> those pesky
>>> newlines
>>> C - no special provision is made for TR
>>> D - a paragraph about this topic is added to the tutorial
>>
>> I agree about C and D.., but not with A and B directly. As for A, we
>> can't simply switch behavior, and for B. adding an option makes it
>> confusing again. We should be trying to limit the amount of options
>> because we'd like to avoid the 1.000s of options that ezp has now.
>>
>> I think instead we should make it a property of the context. Now I
>> think more of this, it starts to make more sense. The current XHTML
>> context, should keep the current behavior (obviously), but there
>> should be a context for email and also one for javascript. In case
>> you want to change the behavior or the new line handling, you can
>> create your own context.
>
> This issue is still on my list of open problems.
> I totally disagree with C. Why would I want to keep the newlines after
> all elements? I think the only exception where the newline should be
> kept is with {tr} as it is embedded within text of e.g. an email.
> If I have to care about all newlines in an email template then
> sticking to the current state seems to be easier. Even adding
> additional newlines after all {tr}s with subsequent newlines keeps the
> templates more readable imo.
> Therefore there shouldn't be just a general trim whitespace option but
> also a special option for {tr}.
Sorry, I might have lost some of the initial context here (darn alzheimer).
However, there is one thing that bothers me in the specialness of tr:
what if I want to put a number inside my email text?
{var $age = 2, $name = "bob"}
your age is: {$age}
{tr "and your name is:"}
{$name}
Of course the number needs not to be translated. But it is content we
are outputting into the text, just as translated text would be. So, if
we want to keep the newline after the tr block, I think we should also
keep it after the {$age} one.
bye
Gaetano
ps: one more thing about the "email" context: how does it take into
account mime types and uuencoding/quoted_printable/base64?
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
