3 Replies Latest reply on Feb 29, 2008 11:56 AM by Pete Muir

    lots of outjection = trouble?

    Brian Cole Newbie

      Hi Seam guys. We just wrote a significant application in facelets-JSF-Seam-JPA, went live in december, and everything is working brilliantly. Thanks for all your work! But one hassle I have now is keeping track of the outjected objects. As the application grows, the number of outjected variables that my code could inject grows linearly. I can't see any way around this; I wish I could scope my outjects with something analogous to the Java access modifiers, so they wouldn't be globally accessible, and parts of my app would be a bit more isolated from each other.


      So I have some suggestions/questions:


      1. Is this really the problem I think it is? Maybe I'm missing something simple.


      2. Regardless of the answer to (1), is there a tool/strategy for finding where a particular object is being outjected or injected? This is exactly the kind of thing I need to know when I'm changing code. Of course, I do have my excellent and up-to-date documentation - I mean in addition to that ...


      3. Maybe WebBeans has something to help here - I hear it won't have outjection at all.


      4. From my understanding of the basic intent behind the law of demeter, this sort of free-for-all potential interaction between objects is a bad thing (http://www.dcmanges.com/blog/37).


      Of course there are pros and cons to any approach ... I guess my point is just that I'd like to know how to manage and minimize the problems I'm having.



        • 1. Re: lots of outjection = trouble?
          Clint Popetz Apprentice

          In the code my group has been writing in seam we've adopted the approach of minimizing outjection by having EL expressions in views refer to fields of conversational components, i.e. instead of:


          @Name("myAction")
          public class MyAction { 
          
           @Out Object foo;
          
          }
          
          ...
          
          <h:outputText value="#{foo.property}"/>
          



          we do



          @Name("myAction")
          public class MyAction { 
          
           Object foo;
           public Object getFoo() { ... }
           public void setFoo(Object foo) { ... }
          }
          
          ...
          
          <h:outputText value="#{myAction.foo.property}"/>
          



          This is a little more laborious in views, but it keeps the contexts cleaner, and keeps my from going insane trying to track down who has outjected what.


          We do still use outjection in factory scenarios, e.g. one component creates another component and outjects it.  But for propogation of objects to the view for iteration and rendering, I think outjection is a unmaintainable approach for all but the simplest cases.  (But for those simplest cases, we use use it, and I'm glad it's there!)

          • 2. Re: lots of outjection = trouble?
            James Kelly Newbie

            1. What scope are you outjecting your components to? Bijection can certainly get unwieldy if the Session and Application scopes get polluted with components that are only relevant to the Event or Conversation.


            I find it helpful to concern myself with the lifecycle of components rather than their visibility.


            2. Tools. Yah. The JBoss Tools has a Seam Components view which lists all of the @Name'd classes and their defined scope; I agree it would be awesome if the plug-in also scanned the @Out/@In annotations.


            3. That's not the impression I got - regardless, Web Beans might be a little ways off.


            4. The Law of Demeter looks perfectly applicable. If you take the Paperboy example from the posting - it would make just as little sense for the Customer to @Out-ject its Wallet just to @In-ject it to the Paperboy.


            Delegation still seems like a practical solution . Add a Customer.pay() method, and inject the Customer into Paperboy - Seam even affords way to inject a named role for a component based on scope, e.g.

            @Role(name = "currentCustomer", scope = CONVERSATION)



            • 3. Re: lots of outjection = trouble?
              Pete Muir Master

              Brian Cole wrote on Feb 27, 2008 10:40 PM:


              Hi Seam guys. We just wrote a significant application in facelets-JSF-Seam-JPA, went live in december, and everything is working brilliantly. Thanks for all your work! But one hassle I have now is keeping track of the outjected objects. As the application grows, the number of outjected variables that my code could inject grows linearly. I can't see any way around this; I wish I could scope my outjects with something analogous to the Java access modifiers, so they wouldn't be globally accessible, and parts of my app would be a bit more isolated from each other.



              Seam has these - e.g. a conversation is per user.




              2. Regardless of the answer to (1), is there a tool/strategy for finding where a particular object is being outjected or injected? This is exactly the kind of thing I need to know when I'm changing code. Of course, I do have my excellent and up-to-date documentation - I mean in addition to that ...

              Not yet - we are looking at more things like this for JBossTools.


              Web Beans will help as it has strongly typed binding of objects which are much more powerful than the string based ones Seam provides. Also, outjection isn't in the spec as you say.


              I personally would write the app without outjection initially (and use seam manager components with factories) as I find it a more logical structure. Outjection comes into it's own as a performance improvement though,