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.
> 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.
> Why is not a javascript context present by default in the lib?
No idea :) We should investigate however what exactly this should do.
regards,
Derick
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
