Priority: Urgent
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Component:
Branches:
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