3 Replies Latest reply on Oct 27, 2008 6:44 PM by axiom

    Seam Custom Contexts?

    axiom

      Good evening all; this is axiom from TopCoder.


      I had this idea for evaluating Seam EL based on more than just the state of the application as a whole, but based on where in the application the evaluation was being requested.


      In our specific case we combined this problem with adding location awareness to JSF EL - so that an expression used at some higher level container tag in the UI component tree (rich:dataTable, for example) would be able to use that information to guide the evaluation. Right now, that's done by the JSF component itself, and not the EL. But that's a separate problem.


      Assuming that we have some such information that we've added to the EL expression evaluation context, what I would like to do is make that available to the Seam EL evaluator, and for someone to use that information to identify the specific Seam contexts to use.


      Of course, there are limited reasons to use that information if all we are doing is choosing between an instance of a Page Context or an instance of an Event context, since the hierarchical search Seam does will pick up variables from the Page context if they are not in the Event context.


      So I have been proposing a second order of contexts. Instead of picking a Context based on where we are in the request life-cycle, we also pick one based off of additional information. So you'd pick not an Event context, but an Event context specific to that information.


      This makes things significantly more complicated, but it would allow, for example, naming isolation between some form of portlets within a Seam application.


      This is exactly what we'll be using this for, but implementing it is tricky. Looking at the hierarchical context search code in (2.0.2.SP1) org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(String name), I see that the list of Contexts to use are checked in a specific hard-coded order.


      To hack this up, I was thinking of adding an Interceptor for all Seam requests that would reflect (sorry) onto the ThreadLocal's that maintain the contexts, and replace them with a 'CompositeContext', that checks first the new context, and then the original. That's not perfect, but you see where I am going. The approach is modifying the way the code appears to work by changing the Context objects it is interacting with.


      My question to the Seam guru's are threefold:


      1. Is there a reason, for performance or otherwise, that the context search is hard-coded here?
      2. Is the implementation of custom contexts, and the insertion of those contexts into the search order, something actively discouraged?
      3. Does the above concept make sense as a solution to code isolation in Seam... or am I missing some far easier alternative?


      Any guidance you can provide on this would be much appreciated,


      Thanks in advance,


      Peter

        • 1. Re: Seam Custom Contexts?
          pmuir

          1. Is there a reason, for performance or otherwise, that the context search is hard-coded here?

          We've never supported custom contexts in Seam, so there was never a reason to do this. Web Beans is significantly more flexible in this regard.



          2. Is the implementation of custom contexts, and the insertion of those contexts into the search order, something actively discouraged?

          Have a go, but Seam isn't designed to allow you to do this.



          3. Does the above concept make sense as a solution to code isolation in Seam... or am I missing some far easier alternative?

          Surely an easier option is to just push the relevant object into the FaceletContext at your container level?


          I assume you are basically trying to build plugins. Take a look at what Christian did in the wiki.

          • 2. Re: Seam Custom Contexts?
            axiom

            Will do. Thanks Pete.

            • 3. Re: Seam Custom Contexts?
              axiom

              I think you are referring to this:


                  @In(#{preferences.get('FeedAggregator', currentMacro)})


              So this indirectly looks up the correct component. Very nice alternative.


              Cheers,


              -Peter