Derick Rethans a écrit :
On Fri, 16 May 2008, Gaetano Giunta wrote:
Derick Rethans a écrit :
On Thu, 15 May 2008, Andreas Schamberger wrote
I found another template translation issue. With ezcTemplateNoContext (and
also in the HTML context) the newline after a translation block is
stripped. Is this the intended behavior? Would be annoying to add
additional newlines within email templates.
It's not a bug, because all blocks do this. However, I do agree that it's
unwanted behavior with the {tr} block - could you file an issue for this
please (as a bug)?
Sorry, I am probably missing something, but I always found this most annoying
in the eZP template language.
Outside of the HTML context, newlines are most likely quite important (eg. for
plaintext, mail bodies, csv, etc...).
I do not think that the newline following a template statement should
necessarily be eaten by the parser, but I think it is much more important to
preserve coherency: either those newlines are always discarded, or they never
are. Any other option makes the output of your templates completely
unpredictable. And the tr function is not different from others. Why should
the following then miss a newline between caption and user comment?
{var $tr = "The user added the following comment:"}
{$tr}
{$action->comment}
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.
The more I read this mail, the more it makes sense to me, too.
As a final note, how do you switch from html context to js one within the same
eZC template?
You can't, but the java script should be a template on its own that you
send to the main template.
Sound a sensible way to do it, if it was not for the fact that html and
js can be mixed freely on a web page (or, god forbid, email!!!), and
forcing a single page in 2 templates just for that is, imho, bad design.
I would rather have a way to force the context from within the template
- as there is little chance that a given tpl can be used in different
contexts anyway, having the template himself decide the context instead
of always putting the context outside of the template is ok. Unless of
course there are deep technical problems with it...
Why is not a javascript context present by default in the lib?
No idea :) We should investigate however what exactly this should do.
Imho: quote stuff as if it was to be part of a js string literal (which
is also valid json, of course):
- newlines turned to \n
- single and double quotes escaped
- anything outside ascii coded to \uXXXX
bye
Gaetano
ps: I also strive for inclusion of javascriptspecialchars in php, btw!
regards,
Derick
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
