12 Replies Latest reply on Feb 23, 2007 8:12 PM by Patrick Angeles

    Feature request - @InOut

    Andrew Apprentice

      Before making this an official JIRA request, I wanted to make sure that there wasn't already something out there that I missing.

      IMO, it would be great to have an InOut annotation that can combine In and Out to avoid excessive typing. Examples:


      @In(required=false, value="someString", scope=ScopeType.EVENT)
      @Out(required=false, value="someString", scope=ScopeType.EVENT)
      private String localVariableName;

      Easier as:
      @InOut(required=false, value="someString", scope=ScopeType.EVENT)
      private String localVariableName;

      What do you think?

        • 1. Re: Feature request - @InOut
          Mariusz Smykula Newbie


          is better ;)

          • 2. Re: Feature request - @InOut
            Patrick Angeles Novice

            LOL. Seems useful but, @InOut just sounds vulgar.

            "A Clockwork Orange" popped into my mind...

            • 4. Re: Feature request - @InOut
              Tino Nitze Newbie


              "mariuszs" wrote:
              is better ;)

              +1 :)

              • 5. Re: Feature request - @InOut
                Patrick Angeles Novice

                How about one of the following:


                Or replace *Variable with *Value or *Object or *Bean

                • 6. Re: Feature request - @InOut
                  Monkey Den Master

                  Where do I sign up for the hot @Bi action?

                  (@Bidirectional or @Bijected if you prefer)


                  • 7. Re: Feature request - @InOut
                    Andrew Apprentice


                    I put in @Bidirectional. @Bi doesn't sound any less perverted than @InOut :-).

                    • 8. Re: Feature request - @InOut
                      Norman Richards Master

                      In the general case, wouldn't be better to simply create a component definition in components.xml? You shouldn't normally need such verbose in/out declarations.

                      • 9. Re: Feature request - @InOut
                        Andrew Apprentice

                        "shouldn't normally need such verbose in/out declarations"


                        It is often very helpful with rendering specific member variables with conversation or session scoped beans. For example, a SELECT box may use a selectItems that takes a List return value from a backing bean. If this were to be created in the get method, the list would be created multiple times per-request since the EL is evaluated more than once during the JSF phases. So, the technique can be used:

                        @In(scope=ScopeType.EVENT, value="some-unique-string", required=false)
                        @Out(scope=ScopeType.EVENT, value="some-unique-string", required=false)
                        private List<SelectItem> myOptions;
                        public List<SelectItem> getMyOptions()
                         if (myOptions == null) { /* build the list */ }
                         return myOptions;

                        In this example, myOptions is created only once per request and the developer doesn't have to code the: 1) get faces context 2) get the external context 3) get the request map 4) get the value from the map 5) if null create it and 6) store it in the map and finally 7) return it.

                        This is also very useful for binding where you want the UIComponent to be created once per-request and not tied to the conversation.

                        Perhaps in these instances the "@Scope" being applied to fields would be more useful. In that case the seam framework could null out any variable with a shorter lifespan than the bean. Examples could be:
                        @Scope(ScopeType.CONVERSATION) public class MyBean {
                        // Null this value after request
                        @Scope(ScopeType.EVENT) private String myVar;

                        @Scope(ScopeType.SESSION) public class MyBean {
                        // Null this value after a conversation is ended instead of waiting for the session to end
                        @Scope(ScopeType.CONVERSATION) private String myVar;

                        • 10. Re: Feature request - @InOut
                          Norman Richards Master

                          I think that looks like a mess. Is there a reason to not use @Factory or one of the other techniques seam provides for managing state?

                          • 11. Re: Feature request - @InOut
                            Andrew Apprentice

                            I find things defined in XML files to be very hard to maintain and try to stay away from them and use annotations instead. Also putting variables not tied to beans into the request scope also makes it hard to maintain -- as it is hard to determine what bean put them there. I like to "bean qualify" all my EL expressions so it is simple to find the bean and the property that is being used. Also in a large application, it would be a bit of a challenge to ensure unique EL names if many bean properties suddenly became available in the root EL context.

                            For small applications like those examples seam provides, it is fine, but when you may have hundreds of backing beans and views, it gets a lot harder.

                            So the reason is so that I can keep the properties of a bean inside that bean and manage the life-cycle of those properties from within that bean (basically encapsulation).

                            • 12. Re: Feature request - @InOut
                              Patrick Angeles Novice

                              Maybe I'm being dense, but... if I read your post right, it sounds like you want your entity POJOs to be referenced through a JSF managed bean... so why not just make a stateful managed bean that has getters/setters for the entities?

                              Something like:

                              @Scope ( ... )
                              @Name ("myManagedBean")
                              class MyManagedBean {
                               private String text ;
                               private User user ;
                               public String getText () { return this.text ; }
                               public void setText (String text) { this.text = text ; }
                               public User getUser () { ... }
                               public void setUser (User user) { ... }

                              Then the EL would look something like this:

                              User name: #{myManagedBean.user.name}
                              Text: #{myManagedBean.string}