Forum Discussion

peterlu's avatar
peterlu
Champion
12 years ago

This widget could not be displayed

<#assign test = "" />

<#attempt>

<#assign test2 = test?number />

<#recover>

<#assign test2 = 1 />

</#attempt>

test2 = ${test2}

 

My thought is simple. If the variable cannot be converted to a number, then set it to 1.

I have installed this test component on my custom testing page.

Here is the story:

When I log in as admin, I do not see any errors. and gets the correct "test2 = 1".

But when I log in as a normal user or when i am a anonymous user, I see errors "This widget could not be displayed".

So why?

 

attempt / recover is like java try catch, right?

7 Replies

  • Inactive User's avatar
    Inactive User
    12 years ago

    That whole thing worked when I tried it. Printed out 1.

     

    [Edit] then I read the admin clause. My bad, doesn't make sense.

  • AdamN's avatar
    AdamN
    Khoros Oracle
    12 years ago

    Hi peterlu,

     

    Freemarker actually has a directive for testing whether a variable is a number, so you may want to explore that as an alternate to using attempt/recover. For example:

     

    <#if test?is_number>
    ...
    </#if>

    Reference materials available here:

    http://freemarker.sourceforge.net/docs/ref_builtins_expert.html#ref_builtin_isType

     

    The behavior you describe definitely sounds odd, but there'd probably need to be some additional investigation to determine what is the expected behavior. If you believe this is a bug, I'd suggest filing a case so that it can get on the Support team's radar and be tracked through resolution.

  • peterlu's avatar
    peterlu
    Champion
    12 years ago

    Hi AdminN,

    I know that there is a is_number function. But I wont use it. Thank you for the suggestion anyway.

    Use case: I want to get a custom query string value from url for pagination purpose. eg. http://...../?my-page-number=3

    When I get this my-page-number from url, it will always be a string. I need to convert it into number.

    But it is possible that url may be hacked by ?my-page-number=bar

     

    My only intertest is why the "This widget cannot be displayed" only show up for non-admin users. I have been written so many custom components for lithium. And this question is alway bugging me. According to freemarker docs, attempt/recover looks like java try catch. So why Lithium show up this error message for users, not admins?

     

    BTW, I am not talking about a string to number conversion here only. It is about the general attempt/recover.

  • nickyates's avatar
    nickyates
    Mentor
    12 years ago

    I had the same issue here and never did get to the bottom of it.  Frustratingly im getting the same problem again while using an if/else block on another section of code.  Any update on this would be very helpful

  • Henrik's avatar
    Henrik
    Advisor
    12 years ago

    Hi,

     

    I got the same issue. It seems to me that Lithium catch the error before Freemarker does.

     

    I want to test if one node of the REST result exists:

    <#assign user_ranking = rest("/users/id/${user.id}/ranking").ranking />
    <#attempt>
    	<#assign user_ranking_image_left = author_ranking.display.left_image.url?replace("http://www.cvous.com", "")?js_string />
    <#recover>
    	<#assign user_ranking_image_left = "" />
    </#attempt>
    <#attempt>
    	<#assign user_ranking_image_right = author_ranking.display.right_image.url?replace("http://www.cvous.com", "")?js_string />
    <#recover>
    	<#assign user_ranking_image_right = "" />
    </#attempt>

    But the "attempt" test will generate a "This widget could not be displayed" for anonymous or non admin members.

    I don't even know why it works for admin member.

     

    Have a nice day!

     

    Henrik

     

  • nathan's avatar
    nathan
    Executive
    12 years ago

    You might want to check that normal and anonymous users have permission to access the REST API call (as this is outside of the attempt/recover block).

  • We just checked with Lithium Support, this is an issue and will be fixed. For now, you can use the endpoints instead. We verified and they are working fine. We hope the Custom Components get this fix soon.