Item9458: header and footer in RENDERZONE violate "standards"

As we try to standardise the way all macros work, it's important not to wander away. Specifically, the header and footer parameters to the RENDERZONE macro do not support the standard formatting tokens. This is a release blocker, otherwise we will end up releasing something that's a PITA to support. See http://trunk.foswiki.org/System/VarRENDERZONE

TBH I'm not entirely sure what these parameters are for; they seem to me to be of zero use, given that they are always inserted so you might as well put the same content outside the call. If this is indeed the case, I'd favour removing them entirely,

Marked for Michael's feedback, since he's the one who wrote this code.

-- CrawfordCurrie - 11 Aug 2010

Which standards do you mean? Is it percnt, dollar and friends? If they are not expanded in header or footer then this is a plain bug.

The RENDERZONE macro has recently been changed to always produce output. This wasn't the case before as far as I know. There should be some

return '' unless @results;

in the code.

As a general rule, any macro that loops over a list of result items and use a format param should also have header and footer and separator as well. All of these four should support standard escapes. That's standard.

-- MichaelDaum - 11 Aug 2010

I reverse engineered the code to extract the doc. That's when I discovered this.

Agreed about the escape for empty contents. As it's written, the header/footer in RENDERZONE are not that useful.

So, two bugs here.

-- CrawfordCurrie - 11 Aug 2010

I changed so that VarADDTOZONE would always add even if adding empty content. This aids in dependency resolution (otherwise we get bogus "required id(s) that were missing).

I do not recall changing the behaviour of RENDERZONE in this way. If header/format/footer aren't meant to be expanded if there is no content, then that should be a bug

-- PaulHarvey - 12 Aug 2010

I'd prefer RENDERZONE to behave standard wrt header,footer,format and separator. The "required ids missing" message is not very help as far as I can see. The dependencies among items in a zone are not meant to be hard requirements. Instead they are only used for ordering them among each other.

-- MichaelDaum - 12 Aug 2010

I have to disagree there; the required id's has saved my sanity several times already, when trying to understand why something doesn't work. You may not have intended them to be hard requirements, but that's the way they are used.

-- CrawfordCurrie - 12 Aug 2010

requires is a conditional hard constraint on the sorting order within the zone. It is not a requirment for the presense of the mentioned ID

In other words: a requires="foo" parameter to an ADDTOZONE means:

If there's an ID "foo" then the provided content must be sorted after the content of the content associated with ID "foo".

This also means: if there is no ID foo, the constraint is not pertinent. That means that the diagnostigcs "missing ID" is a correct diagnostics, but not an indicator for a fault by any means.

Again: the requires constaint does not guarantee the required object to be present. It only constraints the sorting order.

There would only be a fault if there was an ID "foo" and the content wasn't sorted correctly.

-- MichaelDaum - 12 Aug 2010

When I use the requires parameter it's because I'm adding something that depends on it and if it's not there, then an "id missing" message would be straight to the point and time saving.

-- DavidPatterson - 12 Aug 2010

... which indicates that the parameter name "requires" is missleading. Something in the sense of after would have been more appropriate.

-- MichaelDaum - 13 Aug 2010

If we want to change requires to after, I can do that work the same way we renamed tag to id, if we think it's a good idea. (requires would be an undocumented alias to after)

-- PaulHarvey - 13 Aug 2010

... because I hope we can have a before parameter in Foswiki 1.2. Presently there is no way to set up JQueryObject with desired parameters because this particular (admittedly, not-so-well-written) plugin (there is a github fork that is much cleaner) can only be adjusted by inserting some <script> before that JS file is loaded.

So, without a before, we have to set up JQueryObject with a bogus dependency on some sort of JQueryObject/settings id, and then we can ADDTOZONE{"body" id="JQueryObject/settings" text=".... (the settings)"}.

This isn't the only situation where a before would be handy, just the most recent in my mind.

-- PaulHarvey - 13 Aug 2010

Sounds good.

-- MichaelDaum - 13 Aug 2010

I don't think it's necessary to rename requires, all it needs is better documentation. But the point that is being made here is clearly expressed by David when he says if it's not there, then an "id missing" message would be straight to the point and time saving. At no point has anyone suggested that's an error; we are just arguing for a message in the output indicating that the constraint was present but could not be resolved, as we have now.

-- CrawfordCurrie - 13 Aug 2010

If there had been unit tests in the first place, we wouldn't have had to fix it.

-- CrawfordCurrie - 13 Aug 2010

When constraints aren't pertinent they can't be violated. In our case there are no constraint voilations. Not a single. All constraints are always resolved as there's always at least one solution for sorting the zone. If there was a constraint being violated, sorting would have been incorrect.

This wasn't invented by me. It basically is still the core algorithm that was invented as part of ADDTOHEAD. Not my work. There haven't been unit tests covering ADDTOHEAD in that respect either.

-- MichaelDaum - 13 Aug 2010

Commenting is disabled while not logged in