while_f: Is this a bug or intentional?
Added by Plug Gulp almost 5 years ago
Hi,
I am looking at the while_f
function implementation in Wt. The code that handles while_f
processing looks like this in the Wt code:
bool WTemplate::_while(const std::vector<WString>& args,
std::ostream& result)
{
if (args.size() < 2)
return false;
WString tblock = WString::tr(args[1].toUTF8());
while (conditionValue(args[0].toUTF8()))
this->renderTemplateText(result, tblock);
return true;
}
Comparing this to the block
function implementation:
bool WTemplate::_block(const std::vector<WString>& args,
std::ostream& result)
{
if (args.size() < 1)
return false;
WString tblock = WString::tr(args[0].toUTF8());
for (unsigned i = 1; i < args.size(); ++i)
tblock.arg(args[i]);
this->renderTemplateText(result, tblock);
return true;
}
It looks like the argument processing for the while_f
function is missing. Should the while_f
code be:
bool WTemplate::_while(const std::vector<WString>& args,
std::ostream& result)
{
if (args.size() < 2)
return false;
WString tblock = WString::tr(args[1].toUTF8());
// This for loop is missing in the code base.
for (unsigned i = 2; i < args.size(); ++i) {
tblock.arg(args[i]);
}
while (conditionValue(args[0].toUTF8())) {
this->renderTemplateText(result, tblock);
}
return true;
}
I stumbled upon this because I am trying to use following template:
<message id="list_item">
<div>
${{1}_item_number}
</div>
</message>
<message id="list_template">
<div>
<div>
${block:list_item S}
</div>
<div>
${while:next_item list_item L}
</div>
</div>
</message>
In the above template the 'S'
value is substituted correctly in the list_item
argument, but the 'L'
value is not substituted when the while
function is used with list_item
.
Is this a bug or is there a reason for not passing on the arguments to the block
associated with while_f
function?
Thanks and kind regards,
~Plug
Replies (6)
RE: while_f: Is this a bug or intentional? - Added by Roel Standaert almost 5 years ago
I think while_f
is an abomination to start with, but it could maybe indeed support more args just like block.
RE: while_f: Is this a bug or intentional? - Added by Plug Gulp almost 5 years ago
I think while_f is an abomination
But it is a very basic construct and useful when rows of data needs to be displayed. What are the alternatives to while_f if that is not the preferred method?
RE: while_f: Is this a bug or intentional? - Added by Roel Standaert almost 5 years ago
Sorry, it's a feature I implemented years ago and I'm just not happy with it :-). I don't necessarily know what would be the better way. I can see the need for some sort of for
or while
construct, but how while_f
is implemented is just a bit awkward (e.g. when going over a vector of things, you need to return the current element in resolveString
or resolveWidget
and then advance the pointer, and at the end reset it).
Most of the time we just use a WContainerWidget
for that purpose. Of course, this does add another HTML element (it can't function as an HTML "fragment"). It is not ideal, but I think it's a nicer interface.
I guess that adding those extra block arguments wouldn't hurt, though. I just thought it was a bit pointless, because usually block arguments are for a particular instantiation of a block, whereas in this case the arguments would affect every instantiation of the block in the while loop. If you see a purpose though, I guess that can be changed.
RE: while_f: Is this a bug or intentional? - Added by Plug Gulp almost 5 years ago
Most of the time we just use a WContainerWidget for that purpose.
I am not using Wt widgets. I am using Wt as a REST server serving Wt template fragments to update client-side built using jQuery and Bootstrap.
RE: while_f: Is this a bug or intentional? - Added by Roel Standaert almost 5 years ago
I pushed a commit recently that makes it so that while
also looks at block args.
RE: while_f: Is this a bug or intentional? - Added by Plug Gulp almost 5 years ago
Thank you very much!
Kind regards,
~Plug