[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.



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