• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

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

ItemTemplate
Summary TML not evaluated inside-out strictly
ReportedBy TWiki:Main.MichaelDaum
Codebase

SVN Range Wed, 18 Jan 2006 build 8363
AppliesTo Engine
Component

Priority Urgent
CurrentState Closed
WaitingFor

Checkins 8380 8381
Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r11 - 2006-01-19 - MichaelDaum
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback