Given
%DBCALL{"BlogSideBar" section="%IFDEFINED{"%SIDEBAR%" then="%SIDEBAR%" else="Default"}%"}%
%DBCALL gets a
section=%IFDEFINED{
since the most recent svn checkins.
although
%DBCALL{"BlogSideBar" section="%IF{"defined SIDEBAR" then="%SIDEBAR%" else="Default"}%"}%
works fine. But there are other TML expressions in the
BlogPlugin TWikiApplication
that fail on beta6.
(yes, I will change all IFDEFINED into If{defined in the
BlogPlugin)
In dakar all TML are equal, some are more equal: internal tags are handled
before plugin tags (internal are those that are builtin as well as those registered
using the
registerTagHandler()
api; plugin tags are those that
get expanded by the
commonTagsHandler()
). This breaks the old TML
rule where the engine renders left-to-right-inside-out (approximately) as
first builtin tags get expanded left-to-right-inside-out and
afterwards plugin
tags left-to-right-inside-out in a second pass.
This hurts if you try to parse a (once) valid TML expression
that has a plugin tag in the argument position of a builtin tag. As a consequence
of that the arguments to the builtin tag fail to be parsed correctly as the
quotes to the plugin tag get into the way.
MD
That's correct. If tags are registered using
registerTagHandler
they will observe the inside-out-left-right order. But if a plugin does an arbitrary substitution over the text, there is no way to enforce the order. There was never an "old rule", as tags were expanded in an order that owed more to faith than science.
The recent changes you refer to are the changes to enforce strict containment of tags within tags. Specifically, the case of %NOP{ %TAG{} }% in NewUserTemplate, that on Cairo and earlier versions of Dakar would fail, because the }% after the TAG expression (which is an undefined tag) would end up closing the NOP. I changed this so that aribtrary levels could be nested even if the tags at some levels are not defined.
So how does this help you? Well, it doesn't. Dakar is now "more correct", but some tag expansions that previously appeared to work will now be broken. In your example above, because %IFDEFINED is not expanded during builtin tag expansion, it gets embedded verbatim in the resulting argument string to the DBCALL. So the arguments to DBCALL are
"BlogSideBar" section="%IFDEFINED{"%SIDEBAR%" then="%SIDEBAR%" else="Default"}%"
(You can confirm this by looking at
$params->{_RAW}
).
Unfortunately the arguments parser is very stupid, and parses that as this:
"BlogSideBar" section="%IFDEFINED{"
The ways to overcome this problem are (1) to register a tag handler for IFDEFINED or (2) to preprocess it in a
beforeCommonTagsHandler
.
Given that there are workarounds to this problem, but no workarounds to the problems with the new user template, I'm discarding this.
CC
There's a more fundamental problem here, and I'm reopening this.
This, along with Item1260, and others, worked in earleir versions of Dakar, inclduing Beta4.
Now it doens't. It doens't because
CC says that its more correct to have the behaviour changed.
The changes were made, it seems, because we don't have a formal definition or a set of test cases.
As if the prviously deployed applications themselves are not ,
ipso facto, test cases.
This isn't about a stick-in-the-mud compatability with Bejing or Cairo and being repressive and squelshing innovation. It has been stated in the past that the Dakar parser does work "correctly" by working "from the inside out". Now
CC is telling us that isn't so. many of us has designed based on his earlier statement and our applications now fail.
I'm upset, disapointed and annoyed.
--
AJA
Anton, please, please calm down. I discussed the issue all day long
with CC on IRC and we are very well aware of the situation. The above
is just the abstract essentials of that. We agreed that some special tags are
handled better by the
beforeCommonTagsHandler()
, i.e. the
IFDEFINED*/IFSKINSTATE*
family in the
NatSkinPlugin.
Let's see what we can do from the point where we are now. The
SpreadSheetPlugin
and its
CALC
is a different issue though. Maybe that one should register its tags
properly. I will file a bug report on that (
Item1436).
MD.
I have no problem reverting the fix, as the old behavior was what Cairo did. The fix was a result of
Item1422. Now, I can change the behavior back, but it will break
Item1422. Which is it to be?
CC
I think that
NOP{}
as exemplified in
Item1422 is more of a
<tmpl-verbatim>...</tmpl-verbatim>
section to be handled by
takeOutBlocks()
. We should stick to inside-out without any exception.
The
concept of the
NOP{}
tag is broken, that's my answer to
Item1422.
MD
I'm afraid you are right. To fix it risks breaking too much else.
Reverted in 8380
CC