3

Is there a reason why CGI.pm examples rely on list concatenation rather than on string concatenation? are the two interchangeable? think

print q->hidden(-name =>'rm', -value => $var).
      q->submit(-name =>"rm$var");

vs.

print q->hidden(-name =>'rm', -value => $var),
      q->submit(-name =>"rm$var");

I have a specific reason for asking. it is very convenient to build up a page from strings. after all, perl understands scalar strings as basic types.

however, I am completely perplexed by some odd behavior in the string concat context. Specifically, I have encountered occasional cases in which the $var in the hidden is not the same as the one in the submit button. I could work around this, but I would rather understand CGI.pm .

could someone please explain whether string concat should work?

ivo Welch
  • 2,427
  • 2
  • 23
  • 31

2 Answers2

3

Unless you change the default value of $,,

print EXPR1, EXPR2;

and

print EXPR1 . EXPR2;

produce the same result if the expressions aren't context-specific. The functions in question always return an HTML string, so you're good.

ikegami
  • 367,544
  • 15
  • 269
  • 518
3

You're right that the two examples have the same effect (well, as ikegami says, unless you have changed $,). The only difference is, of course, that in the first example, print is passed one string and in the second example, it gets two.

But have you read the comments about the HTML generation functions in recent versions of the CGI.pm documentation?

All HTML generation functions within CGI.pm are no longer being maintained. Any issues, bugs, or patches will be rejected unless they relate to fundamentally broken page rendering.

The rationale for this is that the HTML generation functions of CGI.pm are an obfuscation at best and a maintenance nightmare at worst. You should be using a template engine for better separation of concerns. See CGI::Alternatives for an example of using CGI.pm with the Template::Toolkit module.

These functions, and perldoc for them, will continue to exist in the v4 releases of CGI.pm but may be deprecated (soft) in v5 and beyond.

I would seriously consider moving way from these functions (and, indeed, CGI.pm itself) for new work.

Community
  • 1
  • 1
Dave Cross
  • 68,119
  • 3
  • 51
  • 97
  • 1
    great advice. this is a new project, and I primarily wanted to move to what the "standard" is. learning and moving to deprecated is not my plan. – ivo Welch Feb 16 '15 at 16:15