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

Factories vs. outjections

abirkmanis May 24, 2006 10:59 AM

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 May 24, 2006 11:07 AM (in response to abirkmanis)
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.
Actions
2. Re: Factories vs. outjections

gavin.king May 24, 2006 11:08 AM (in response to abirkmanis)

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.
Actions
3. Re: Factories vs. outjections

abirkmanis May 26, 2006 5:06 AM (in response to abirkmanis)

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?
Actions
4. Re: Factories vs. outjections

gavin.king May 26, 2006 10:41 AM (in response to abirkmanis)

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.
Actions
5. Re: Factories vs. outjections

abirkmanis May 29, 2006 6:43 AM (in response to abirkmanis)

Could you provide an estimate of the availability of these examples demonstrating how to build reusable components in Seam?
Actions
6. Re: Factories vs. outjections

gavin.king May 29, 2006 12:33 PM (in response to abirkmanis)

Are you volunteering?
Actions
7. Re: Factories vs. outjections

abirkmanis Jun 2, 2006 7:12 AM (in response to abirkmanis)

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?
Actions

Go to original post