[ic] Update: Re: AddAttr only UserTags sometimes work, sometimes fail
Chris Keane
chris.keane at zzgi.com
Sat Jun 26 00:17:42 UTC 2010
On 4/20/2010 9:08 AM, Chris Keane wrote:
>
> UserTag demotag AddAttr
> userTag demotag Routine <<EOR
> sub
> {
> my ($opt) = @_;
> ...
>
>
>
> The problem comes when accessing any of the members of the $opt
> hashref. For the sake of example, let's say that we have an argument
> to the UserTag called "thing", so the call would be
> [demotag thing=thing_content]
>
> Not all time, but SOMETIMES when I try to access some of the data,
> even very simply, for example
>
> ::logError("opt thing is ". $opt->{thing});
>
> the tag fails and an error is written to the global error.log:
> demo.html Died in server spawn: Can't use string ("thing_content") as
> a HASH ref while "strict refs" in use at (tag 'cgi') line 17.
>
> This worked as expected in previous version of IC, and I suspect in
> later versions (for example, I haven't seen this problem come up on a
> 5.7.4 server, not that it won't, just haven't seen it).
>
> The weird part is that sometimes it works as I would expect. Then it
> will fail and consistently fail for some random period of time. Then
> it will work again.
>
> I can work around the problem by providing an Order to the usertag:
> UserTag demotag Order x
> UserTag demotag AddAttr
> userTag demotag Routine <<EOR
> sub
> {
> my ($x,$opt) = @_;
>
> Any thoughts or guidance?
>
I've a related specific symptom but haven't poked through the server
code yet.
Here's how I call one specific UserTag:
[tmp go][gridding-order max="[scratch max]"
exclude="[scratch exclude]"
evenstart="[scratch evenstart]"
rowsize="[scratch rowsize]"
event="[cgi event]"
class="[wave-param gc_classid]" ][/tmp]
where, for example, the values end up being max = 999, exclude = 0,
evenstart = "0", rowsize = 4, event = 20100626 and class = flcc
This is calling a UserTag that starts like this:
UserTag gridding_order Order class event
UserTag gridding_order AddAttr
UserTag gridding_order Routine <<EOR
sub
{
my ($class, $event, $opt) = @_;
::logError("gridding order args = " . ::uneval_it(\@_));
About half the time this is called, the arguments deposited in the log
file look like this:
race args = ["flcc","20100626","20100626",{'rowsize' => "4",'evenstart'
=> "0",'reparse' => "1",'max' => "999",'class' => "flcc",'event' =>
"20100626",'exclude' => "0",},]
So, we end up with class = flcc (good), event = 20100626 (good) and opt
= 20100626 (bad). Where on earth did that extra 20100626 come from!?!?!
There's only one arg with that value, event! This produces an error:
Died in server spawn: Can't use string ("20100626") as a HASH ref
while "strict refs" in use at (tag 'cgi') line 42
Which is precisely right... when I try to access, say $opt->{anything}
it fails, because $opt is erroneously a scalar with the value of the
event in it.
Now, if I reorder the arguments to the tag so that event and class are
the first two arguments, i.e.
[tmp go][gridding-order event="[cgi event]"
class="[wave-param gc_classid]" ]
max="[scratch max]"
exclude="[scratch exclude]"
evenstart="[scratch evenstart]"
rowsize="[scratch rowsize]"][/tmp]
Then everything seems to work fine. Confusing? Well, it is to me ;)
Note that UserTags that are completely AddAttr, i.e. everything is
delivered via $opt have the same problem except that the mysterious
extra argument can end up being pretty much anything.
Any thoughts?
Chris.
More information about the interchange-users
mailing list