[ic] AddAttr only UserTags sometimes work, sometimes fail
Stefan Hornburg (Racke)
racke at linuxia.de
Wed Apr 21 09:07:23 UTC 2010
Chris Keane wrote:
>>
>> Quoting Chris Keane (chris.keane at zzgi.com
>> <http://www.icdevgroup.org/mailman/listinfo/interchange-users>):
>> /
>> />/ I'm having a weird issue with some UserTags that have all attributes
>> />/ passed to them via AddAttr, for example:
>> />/
>> ...//
>> />/
>> />/ Any thoughts or guidance?
>> /
>> Are these calls from $Tag objects or via ITL parse? I am guessing
>> ITL parse. If we don't pass any argument at all to the routine, I am
>> guessing that @_ could have some residual value causing the problem.
>>
>
> Mike, I only recall seeing the problem when called from ITL parse. The
> thought that there is some residual guff in @_ is possible, the thing
> that has me scratching my head is that the parameters are being passed
> but misdelivered by ITL parse. For example, if I pass
> thing=thing_content then it seems that $opt ends up as a literal with
> content of "thing_content" rather than a hashref with a member ->{thing}
> = "thing_content".
>
> So when I call for $opt->{thing}, perl freaks out because I'm treating a
> literal ($opt, mistakenly containing the string "thing_content"), as the
> hashref it's supposed to be.
This is probably not related, but I also noted a bug in the parser with
AddAttr when you call it from tags.
UserTag acl Order function permission
UserTag acl AddAttr
UserTag acl HasEndTag
So if I now pass an array reference in the second argument like:
$Tag->acl('check', [qw/edit_content create_own_content/]);
it bails out because it probably uses the array reference for $opt.
Regards
Racke
--
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team
More information about the interchange-users
mailing list