I agree with you, but it seems that the Shindig developers think the value returned by getString should be escaped. They interpret the spec as requiring this behavior (though I don't understand how they read it that way... as far as I can tell, the spec doesn't say anything about it). The reason is to prevent potential XSS holes, though that ignores the fact that user prefs are used in a lot of ways other than concatenation with literal HTML strings. In any case, if you're targeting a Shindig-based container, you'll need to unescape anything returned from getString (and maybe getArray?) if you want to use it in a URL parameter or direct DOM manipulation.
See https://issues.apache.org/jira/browse/SHINDIG-89 for details. Unfortunately, because Shindig deviates from the spec here, this means that other, non-Shindig-based containers might not have this behavior, which means it's impossible to write a gadget that will work correctly cross-container. In practice, however, I'm pretty sure that everyone is using the Shindig JavaScript code, even if they're not using the Shindig back-end, so all containers are pretty likely to have this same behavior. -- Tim On Jun 29, 8:31 am, rhill <rh...@raymondhill.net> wrote: > gadgets.Prefs.set() automatically escape strings, which certainly make > sense. Problem is that gadgets.Prefs.getString() doesn't unescape the > returned string. Is is by design? Personally I think the string should > be unescaped before being returned. > > rhill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenSocial Application Development" group. To post to this group, send email to opensocial-api@googlegroups.com To unsubscribe from this group, send email to opensocial-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/opensocial-api?hl=en -~----------~----~----~----~------~----~------~--~---
