+1 for SecurityToken.getContainer(). This seems to be a reasonable and standard extension - you need to know context about the page upon which your gadget had rendered.
---1 on getParameter(). This is using SecurityToken as an arbitrary context to pass data around. Request scoped Guice variables handle this much more cleanly. On Thu, Oct 2, 2008 at 5:26 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Thu, Oct 2, 2008 at 2:50 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 2, 2008 at 2:41 PM, Cassie <[EMAIL PROTECTED]> wrote: > > > Anybody else want to chime in? > > > We can either: > > > > > > 1. add SecurityToken.getContainer > > > 2. add SecurityToken.getParameter(String key) > > > 3. leave it as is and go find a different solution for SecurityToken > > > extensions > > > > My rough order of preference: > > - find a different solution, though I've got no idea what one would look > > like. > > - SecurityToken.getContainer() > > - getParameter(String key) > > > > I don't like getParameter(String key) because it forces us to treat > > all security token extensions as Strings. What if it's a List? What > > if it's something else entirely? > > > Realistically, it's going to be a string or something that easily > serializes > as a string. The security token is only so big. > > > > Hrm. I do have some idea of what a good solution would look like, but > > so far everytime I mention it people give me dirty looks. I'll try it > > out on shindig-dev just to see where things go: > > > > Assuming that all instances of SecurityToken are generated by > > deployment specific code, Shindig deployers can implement a single > > subclass of SecurityToken for all SecurityToken instances they > > generate. Shindig SPI implementations can then cast down to that > > SecurityToken subclass. This type of pattern is remarkably common in > > old school C code: opaque void* pointers are tossed around anywhere > > you have two APIs that can't have compile time dependencies but do > > need to call each other at runtime. > > > Yeah, but down casting is problematic. C libraries generally don't mix and > match with each other -- the pointer is opaque to everything but the code > that produced it. They use opaque pointers so that consumers of the library > don't do dumb things with them. > > In this case, both the code using the object and the code that produced it > need to work with it. >
