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}.
Regards,
Andi
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
