7 Replies Latest reply on Jun 2, 2006 7:12 AM by Andris Birkmanis

    Factories vs. outjections

    Andris Birkmanis Newbie

      I am trying to understand why @Factory is much less well represented in Seam examples than @Out (7 vs. 21 in CR2).
      On the first glance, factories seem to play the same role as outjections, just lazy (or call it demand-drivden, pull-like, data flow, etc.). This mode of operation looks safer than outjections (supply-driven, push-like, etc.), as it automatically ensures synchronization of provider of a value and a consumer of this value; while using outjections, one must be carefull to synchronize components "manually" (probably using Seam events).

      On the second glance, factories lack one feature supported by outjections - namely scoping. Using @Out it is possible to have multiple bindings for the same name in different scopes, while I don't see how this is possible for factories (in the current implementation).

      So one question is - why are factories not used more often (and recommended to be used more often), and the another - why scoping is supported for eager value producers (@Out) but not for lazy ones (@Factory)?

      Thanks again,

      Andris Birkmanis

        • 1. Re: Factories vs. outjections
          Gavin King Master

          We use @Out more often than @Factory because @Factory is more complex to use than a plain @Out.

          You _can_ scope an @Factory value, since @Factory is used in combination with @Out or @DataModel, not by itself.

          ie. the usage pattern is not:

          @Factory(value="foo", scope=SESSION)
          public Foo getFoo() { return new Foo(); }


          it is

          @Out(value="foo", scope=SESSION) Foo foo;
          @Factory("foo") public void initFoo() { foo = new Foo(); }


          The first way would have been a reasonable alternative, but that is not the way we chose.



          • 2. Re: Factories vs. outjections
            Gavin King Master

            P.S. You should also try to understand @Unwrap, which gives you something more like the first usage pattern, except that the scope is defined by the owning component.

            • 3. Re: Factories vs. outjections
              Andris Birkmanis Newbie

              First of all, thanks for your suggestions.

              As far as I understood, @Unwrap allows substituting some object (not necessarily an instance of Seam component) when a component was expected, but it does not change the timing of the instantiation.
              I also realize that instantiation of components can be lazy (create = true), which in combination with @Unwrap indeed gives some kind of what I want, but limited to one binding per component.

              Regarding ease of use - I suspect the only reason @Factory is more complex to use than @Out in the current implementation is exactly because (currently) @Factory is used in combination with @Out. It could be made more user-friendly. One might ask - why bother? My answer would be that despite the seeming complexity on the surface, on the high level @Factory is in fact easier to use properly (without runtime errors), as it guarantees correct synchronization of source/target components.

              And I believe this is not some weird special case, I am almost going to state that lazy behavior should be the default for inter-component binding (as opposed to intra-component, but I believe Seam should not bother about latter). That brings another question - why the examples do not demonstrate how to build reusable components, and then compose them into different applications?

              • 4. Re: Factories vs. outjections
                Gavin King Master

                You might be right, it is worth some though.

                The examples don't demonstrate full-blown component design because they are supposed to demonstrate how _simple_ Seam can be.

                • 5. Re: Factories vs. outjections
                  Andris Birkmanis Newbie

                  Could you provide an estimate of the availability of these examples demonstrating how to build reusable components in Seam?

                  • 6. Re: Factories vs. outjections
                    Gavin King Master

                    Are you volunteering?

                    • 7. Re: Factories vs. outjections
                      Andris Birkmanis Newbie

                      Not before I know how to do such examples. I am currently a bit busy understanding limitations of JSF in regards to componentization.

                      BTW, regarding the mapping from names to FactoryMethod's, which is application-wide (stored in Init): the situation is quite similar to an application-wide mapping of ObserverMethod's. Again, why not store FactoryMethod's in scopes? Your last point in the events discussion thread was that you can achieve anything by manipulating session - true, but Seam already does scoping for values, why stop half way and not implement it for events and factories? Are the efforts to support this considerable compared to the added value?