11:25 p.m.
Great work on this, Peter, it's really nice.
I think we should let you specify an event type to raise:
java -Devent=my.Event
or, perhaps, an event qualifier to be applied to the ContainerInitialized event:
java -Dqualifier=my.Qualifier
that way, you have a mechanism for choosing between "main methods".
Alternatively, we could use something EL-ish to specify a method to call:
java -Daction=mybean.method
Hrm, perhaps that's the best option. Maybe my idea of using an event
wasn't so great after all.
WDYT?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
11:42 p.m.
Oh and why is it -Dname=Peter to pass a parameter from Maven?
What is the significance of "name"?
On Tue, Nov 17, 2009 at 5:25 PM, Gavin King <gavin.king(a)gmail.com> wrote:
Great work on this, Peter, it's really nice.
I think we should let you specify an event type to raise:
java -Devent=my.Event
or, perhaps, an event qualifier to be applied to the ContainerInitialized event:
java -Dqualifier=my.Qualifier
that way, you have a mechanism for choosing between "main methods".
Alternatively, we could use something EL-ish to specify a method to call:
java -Daction=mybean.method
Hrm, perhaps that's the best option. Maybe my idea of using an event
wasn't so great after all.
WDYT?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
1:52 p.m.
On Tue, 2009-11-17 at 17:42 -0500, Gavin King wrote:
Oh and why is it -Dname=Peter to pass a parameter from Maven?
What is the significance of "name"?
Maven makes available a property (name) containing the name of the
current project (Hello World SE). As part of the configuration of the
'exec-maven-plugin' in the POM we're reusing this property as the
default commandline argument (line 41). That's why mvn -Drun gives the
output "Hello Hello World SE". So mvn -Drun -Dname=Popeye will overwrite
the value of 'name' to give "Hello Popeye". I guess we could define our
own property in the POM to use if that would make things less confusing,
and probably help avoid any nasty conflicts.
On Tue, Nov 17, 2009 at 5:25 PM, Gavin King <gavin.king(a)gmail.com> wrote:
> Great work on this, Peter, it's really nice.
>
> I think we should let you specify an event type to raise:
>
> java -Devent=my.Event
>
> or, perhaps, an event qualifier to be applied to the ContainerInitialized event:
>
> java -Dqualifier=my.Qualifier
>
> that way, you have a mechanism for choosing between "main methods".
>
> Alternatively, we could use something EL-ish to specify a method to call:
>
> java -Daction=mybean.method
>
> Hrm, perhaps that's the best option. Maybe my idea of using an event
> wasn't so great after all.
>
> WDYT?
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
11:48 a.m.
java -Devent=my.Event
java -Daction=mybean.method
Don't you think this is going too far?
"If you have a hammer, every problem seems to be a nail." :)
There is definitely a need for eventing in the SE world, but I'd rather use args4j [1]
for that very kind of problem.
Something (not really SE) which came to my mind recently: Using the JSR-299 eventing
instead of their own internal eventing system in JSF might open some interesting
possibilities...
LieGrue,
strub
[1] https://args4j.dev.java.net/
--- Gavin King <gavin.king(a)gmail.com> schrieb am Di, 17.11.2009:
Von: Gavin King <gavin.king(a)gmail.com>
Betreff: [weld-dev] Java SE extension
An: "Weld-Dev" <weld-dev(a)lists.jboss.org>
Datum: Dienstag, 17. November 2009, 23:25
Great work on this, Peter, it's
really nice.
I think we should let you specify an event type to raise:
java -Devent=my.Event
or, perhaps, an event qualifier to be applied to the
ContainerInitialized event:
java -Dqualifier=my.Qualifier
that way, you have a mechanism for choosing between "main
methods".
Alternatively, we could use something EL-ish to specify a
method to call:
java -Daction=mybean.method
Hrm, perhaps that's the best option. Maybe my idea of using
an event
wasn't so great after all.
WDYT?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
1:40 p.m.
On Wed, Nov 18, 2009 at 5:48 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
> java -Devent=my.Event
> java -Daction=mybean.method
Don't you think this is going too far?
"If you have a hammer, every problem seems to be a nail." :)
OK then, how would you do it?
A template method doesn't work, because main() is static.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
10:43 a.m.
Using the JSR-299 eventing instead of their own internal eventing
system in
JSF might open some interesting possibilities...
The Seam team will be putting some more thought into this as we put together
our extension modules. If we see a natural integration point, of course we
will propose it in the JSF 2 EG.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
10:44 a.m.
On Fri, Nov 20, 2009 at 10:43 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
Using the JSR-299 eventing instead of their own internal eventing system in
> JSF might open some interesting possibilities...
>
The Seam team will be putting some more thought into this as we put
together our extension modules. If we see a natural integration point, of
course we will propose it in the JSF 2 EG.
Oh, and we are interested in whatever ideas you might have. Gavin and I
talked about this at one point, but we saw the two event systems at trying
to accomplish different goals. Time will tell whether or not that is true.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
3:24 p.m.
On 18/11/2009, at 8:25 AM, Gavin King wrote:
Great work on this, Peter, it's really nice.
Thanks for the feedback. I have to say thanks to Pete M as well who helped me out with
some of the lower-level stuff and general polish (and probably more).
As for the below, I certainly haven't managed to come up with any better solution, but
I'm not really leaning towards any one in particular. If we implemented them all do
you think that would be too confusing for users or would it be alright?
Cheers,
Pete R
I think we should let you specify an event type to raise:
java -Devent=my.Event
or, perhaps, an event qualifier to be applied to the ContainerInitialized event:
java -Dqualifier=my.Qualifier
that way, you have a mechanism for choosing between "main methods".
Alternatively, we could use something EL-ish to specify a method to call:
java -Daction=mybean.method
Hrm, perhaps that's the best option. Maybe my idea of using an event
wasn't so great after all.
WDYT?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
4:27 p.m.
IMO for the use case of selecting a "main method" to run, I prefer the qualifier
option, as that seems to fit best with JSR-299 model.
But I'm not sure we've found the best approach yet...
On 17 Nov 2009, at 22:25, Gavin King wrote:
Great work on this, Peter, it's really nice.
I think we should let you specify an event type to raise:
java -Devent=my.Event
or, perhaps, an event qualifier to be applied to the ContainerInitialized event:
java -Dqualifier=my.Qualifier
that way, you have a mechanism for choosing between "main methods".
Alternatively, we could use something EL-ish to specify a method to call:
java -Daction=mybean.method
Hrm, perhaps that's the best option. Maybe my idea of using an event
wasn't so great after all.
WDYT?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
4:47 p.m.
Gavin, all,
A couple of weeks ago Gavin and I were chatting about being able to do
Instance<Foo> foo = new Weld().boot().getInstance(Foo.class);
which I think led Gavin to reinvestigate the Weld SE stuff that Pete R did.
Adding the above syntatic sugar is pretty easy (it's just another way of exposing the
existing stuff), and I can see use cases for both approaches. Before Pete R or I impl the
above syntax, I want to see what others think (will it just confuse people) and get some
ideas about what the API should look like. Decomposing it:
* new Weld() is ideal. Anyone disagree?
* I would prefer to not actually bootstrap Weld core inside the Weld constructor (I
believe this should be an explicit step), hence the boot() method. We could rename this to
initialize() for example. Opinions?
* What API do we want to expose to allow people to get hold of an Instance<?> ? IMO
we need more syntatic sugar than offered by BeanManager. Do we want to just allow access
to Instances (as above)?
On 17 Nov 2009, at 22:25, Gavin King wrote:
Great work on this, Peter, it's really nice.
I think we should let you specify an event type to raise:
java -Devent=my.Event
or, perhaps, an event qualifier to be applied to the ContainerInitialized event:
java -Dqualifier=my.Qualifier
that way, you have a mechanism for choosing between "main methods".
Alternatively, we could use something EL-ish to specify a method to call:
java -Daction=mybean.method
Hrm, perhaps that's the best option. Maybe my idea of using an event
wasn't so great after all.
WDYT?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
7:36 p.m.
On Sat, Nov 21, 2009 at 10:47 AM, Pete Muir <pmuir(a)redhat.com> wrote:
* I would prefer to not actually bootstrap Weld core inside the Weld
constructor (I believe this should be an explicit step), hence the boot() method. We could
rename this to initialize() for example. Opinions?
Fine by me. Especially since that at some stage we will need to pass
some kind of settings before booting.
* What API do we want to expose to allow people to get hold of an
Instance<?> ? IMO we need more syntatic sugar than offered by BeanManager. Do we
want to just allow access to Instances (as above)?
Stick the following two methods on the object returned by initialize():
Instance<Object> instance();
Instance<Event> event();
So I can do:
Weld weld = new Weld().initialize();
weld.instance().select(Foo.class).get()
weld.event().select(Bar.class).fire( new Bar() );
weld.shutdown();
Or whatever.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
7:45 p.m.
https://jira.jboss.org/jira/browse/WELDX-50
Pete R - do you want to take this, or do you want me to do it?
BTW, to make use in JavaSE easier (especially to avoid RSI by typing crazy long -cp
entries) we should add a single jar that includes all deps
https://jira.jboss.org/jira/browse/WELDX-51
On 21 Nov 2009, at 18:36, Gavin King wrote:
On Sat, Nov 21, 2009 at 10:47 AM, Pete Muir <pmuir(a)redhat.com>
wrote:
> * I would prefer to not actually bootstrap Weld core inside the Weld constructor (I
believe this should be an explicit step), hence the boot() method. We could rename this to
initialize() for example. Opinions?
Fine by me. Especially since that at some stage we will need to pass
some kind of settings before booting.
> * What API do we want to expose to allow people to get hold of an Instance<?> ?
IMO we need more syntatic sugar than offered by BeanManager. Do we want to just allow
access to Instances (as above)?
Stick the following two methods on the object returned by initialize():
Instance<Object> instance();
Instance<Event> event();
So I can do:
Weld weld = new Weld().initialize();
weld.instance().select(Foo.class).get()
weld.event().select(Bar.class).fire( new Bar() );
weld.shutdown();
Or whatever.
10:03 a.m.
On 21 nov. 09, at 19:36, Gavin King wrote:
On Sat, Nov 21, 2009 at 10:47 AM, Pete Muir <pmuir(a)redhat.com>
wrote:
> * I would prefer to not actually bootstrap Weld core inside the
> Weld constructor (I believe this should be an explicit step), hence
> the boot() method. We could rename this to initialize() for
> example. Opinions?
Fine by me. Especially since that at some stage we will need to pass
some kind of settings before booting.
Which probably means you don't want Weld to host both the
configuration and the operation methods
WeldContainer weld = new Weld().initialize();
weld.instance().select(Foo.class).get();
2:18 p.m.
On 23 Nov 2009, at 09:03, Emmanuel Bernard wrote:
On 21 nov. 09, at 19:36, Gavin King wrote:
> On Sat, Nov 21, 2009 at 10:47 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>
>> * I would prefer to not actually bootstrap Weld core inside the
>> Weld constructor (I believe this should be an explicit step), hence
>> the boot() method. We could rename this to initialize() for
>> example. Opinions?
>
> Fine by me. Especially since that at some stage we will need to pass
> some kind of settings before booting.
Which probably means you don't want Weld to host both the
configuration and the operation methods
WeldContainer weld = new Weld().initialize();
weld.instance().select(Foo.class).get();
Yes, this seems sensible to me, as it will allow us to provide flexibility with the
configuration in the future.
2:11 p.m.
> WeldContainer weld = new Weld().initialize();
> weld.instance().select(Foo.class).get();
Yes, this seems sensible to me, as it will allow us to provide flexibility
with the configuration in the future.
Emmanuel, master of fluent APIs, has made an important point that we should
keep in mind when designing a sequential call chain. Think twice before
returning "this" and think if there is a more specific type that you can
return that narrows the options based on where you are in the sequence. That
way, you prevent being able to invoke methods out of sequence.
You can now prevent:
new Weld().event()
Returning a more specific type is also self documenting.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
12:12 a.m.
Hi,
I've done the first iteration of this (checked in - r5173). It doesn't yet
separate out the initialisation, I'll do that next.
One problem is that I can't get the following line to compile:
weld.event().select(CustomEvent.class).fire(new CustomEvent());
I get:
Compilation failure
org/jboss/weld/environment/se/test/WeldMainTest.java:[70,18] cannot find symbol
symbol : method
select(java.lang.Class<org.jboss.weld.environment.se.test.beans.CustomEvent>)
location: interface javax.enterprise.inject.Instance<javax.enterprise.event.Event>
I think the problem is that my CustomEvent doesn't implement or extend Event. I
don't think it has to though (am I mistaken?). Anyone know what I'm missing?
Cheers,
On 24/11/2009, at 11:11 PM, Dan Allen wrote:
> WeldContainer weld = new Weld().initialize();
> weld.instance().select(Foo.class).get();
Yes, this seems sensible to me, as it will allow us to provide flexibility with the
configuration in the future.
Emmanuel, master of fluent APIs, has made an important point that we should keep in mind
when designing a sequential call chain. Think twice before returning "this" and
think if there is a more specific type that you can return that narrows the options based
on where you are in the sequence. That way, you prevent being able to invoke methods out
of sequence.
You can now prevent:
new Weld().event()
Returning a more specific type is also self documenting.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
1:25 a.m.
It looks as if event() is returning
javax.enterprise.inject.Instance<javax.enterprise.event.Event>
instead of javax.enterprise.event.Event.
On Sun, Nov 29, 2009 at 6:12 PM, Peter Royle
<howardmoon(a)screamingcoder.com> wrote:
Hi,
I've done the first iteration of this (checked in - r5173). It doesn't yet
separate out the initialisation, I'll do that next.
One problem is that I can't get the following line to compile:
weld.event().select(CustomEvent.class).fire(new CustomEvent());
I get:
Compilation failure
org/jboss/weld/environment/se/test/WeldMainTest.java:[70,18] cannot find
symbol
symbol : method
select(java.lang.Class<org.jboss.weld.environment.se.test.beans.CustomEvent>)
location: interface
javax.enterprise.inject.Instance<javax.enterprise.event.Event>
I think the problem is that my CustomEvent doesn't implement or extend
Event. I don't think it has to though (am I mistaken?). Anyone know what I'm
missing?
Cheers,
On 24/11/2009, at 11:11 PM, Dan Allen wrote:
>
> > WeldContainer weld = new Weld().initialize();
> > weld.instance().select(Foo.class).get();
>
> Yes, this seems sensible to me, as it will allow us to provide flexibility
> with the configuration in the future.
Emmanuel, master of fluent APIs, has made an important point that we should
keep in mind when designing a sequential call chain. Think twice before
returning "this" and think if there is a more specific type that you can
return that narrows the options based on where you are in the sequence. That
way, you prevent being able to invoke methods out of sequence.
You can now prevent:
new Weld().event()
Returning a more specific type is also self documenting.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
5:33 a.m.
Yep that was it thanks.
On 30/11/2009, at 10:25 AM, Gavin King wrote:
It looks as if event() is returning
javax.enterprise.inject.Instance<javax.enterprise.event.Event>
instead of javax.enterprise.event.Event.
On Sun, Nov 29, 2009 at 6:12 PM, Peter Royle
<howardmoon(a)screamingcoder.com> wrote:
> Hi,
> I've done the first iteration of this (checked in - r5173). It doesn't yet
> separate out the initialisation, I'll do that next.
> One problem is that I can't get the following line to compile:
> weld.event().select(CustomEvent.class).fire(new CustomEvent());
> I get:
> Compilation failure
> org/jboss/weld/environment/se/test/WeldMainTest.java:[70,18] cannot find
> symbol
> symbol : method
> select(java.lang.Class<org.jboss.weld.environment.se.test.beans.CustomEvent>)
> location: interface
> javax.enterprise.inject.Instance<javax.enterprise.event.Event>
> I think the problem is that my CustomEvent doesn't implement or extend
> Event. I don't think it has to though (am I mistaken?). Anyone know what I'm
> missing?
> Cheers,
>
>
> On 24/11/2009, at 11:11 PM, Dan Allen wrote:
>
>>
>>> WeldContainer weld = new Weld().initialize();
>>> weld.instance().select(Foo.class).get();
>>
>> Yes, this seems sensible to me, as it will allow us to provide flexibility
>> with the configuration in the future.
>
> Emmanuel, master of fluent APIs, has made an important point that we should
> keep in mind when designing a sequential call chain. Think twice before
> returning "this" and think if there is a more specific type that you can
> return that narrows the options based on where you are in the sequence. That
> way, you prevent being able to invoke methods out of sequence.
>
> You can now prevent:
>
> new Weld().event()
>
> Returning a more specific type is also self documenting.
>
> -Dan
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
11:38 a.m.
OK I've added WeldContainer, so now it's as Emmanuel suggested:
WeldContainer weld = new Weld().initialize();
weld.instance().select(Foo.clas);
weld.shutdown();
So:
new Weld().event() // doesn't exist
new WeldContainer(InstanceManager, BeanManager) // is package protected
Pete R.
On 30/11/2009, at 9:12 AM, Peter Royle wrote:
Hi,
I've done the first iteration of this (checked in - r5173). It doesn't yet
separate out the initialisation, I'll do that next.
One problem is that I can't get the following line to compile:
weld.event().select(CustomEvent.class).fire(new CustomEvent());
I get:
Compilation failure
org/jboss/weld/environment/se/test/WeldMainTest.java:[70,18] cannot find symbol
symbol : method
select(java.lang.Class<org.jboss.weld.environment.se.test.beans.CustomEvent>)
location: interface javax.enterprise.inject.Instance<javax.enterprise.event.Event>
I think the problem is that my CustomEvent doesn't implement or extend Event. I
don't think it has to though (am I mistaken?). Anyone know what I'm missing?
Cheers,
On 24/11/2009, at 11:11 PM, Dan Allen wrote:
>
>
> > WeldContainer weld = new Weld().initialize();
> > weld.instance().select(Foo.class).get();
>
> Yes, this seems sensible to me, as it will allow us to provide flexibility with the
configuration in the future.
>
> Emmanuel, master of fluent APIs, has made an important point that we should keep in
mind when designing a sequential call chain. Think twice before returning "this"
and think if there is a more specific type that you can return that narrows the options
based on where you are in the sequence. That way, you prevent being able to invoke methods
out of sequence.
>
> You can now prevent:
>
> new Weld().event()
>
> Returning a more specific type is also self documenting.
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
1:14 p.m.
Nice work!
On 1 Dec 2009, at 10:38, Peter Royle wrote:
OK I've added WeldContainer, so now it's as Emmanuel
suggested:
WeldContainer weld = new Weld().initialize();
weld.instance().select(Foo.clas);
weld.shutdown();
So:
new Weld().event() // doesn't exist
new WeldContainer(InstanceManager, BeanManager) // is package protected
Pete R.
On 30/11/2009, at 9:12 AM, Peter Royle wrote:
> Hi,
>
> I've done the first iteration of this (checked in - r5173). It doesn't yet
separate out the initialisation, I'll do that next.
>
> One problem is that I can't get the following line to compile:
>
> weld.event().select(CustomEvent.class).fire(new CustomEvent());
>
> I get:
>
> Compilation failure
> org/jboss/weld/environment/se/test/WeldMainTest.java:[70,18] cannot find symbol
> symbol : method
select(java.lang.Class<org.jboss.weld.environment.se.test.beans.CustomEvent>)
> location: interface
javax.enterprise.inject.Instance<javax.enterprise.event.Event>
>
> I think the problem is that my CustomEvent doesn't implement or extend Event. I
don't think it has to though (am I mistaken?). Anyone know what I'm missing?
>
> Cheers,
>
>
>
> On 24/11/2009, at 11:11 PM, Dan Allen wrote:
>
>>
>>
>> > WeldContainer weld = new Weld().initialize();
>> > weld.instance().select(Foo.class).get();
>>
>> Yes, this seems sensible to me, as it will allow us to provide flexibility with
the configuration in the future.
>>
>> Emmanuel, master of fluent APIs, has made an important point that we should keep
in mind when designing a sequential call chain. Think twice before returning
"this" and think if there is a more specific type that you can return that
narrows the options based on where you are in the sequence. That way, you prevent being
able to invoke methods out of sequence.
>>
>> You can now prevent:
>>
>> new Weld().event()
>>
>> Returning a more specific type is also self documenting.
>>
>> -Dan
>>
>> --
>> Dan Allen
>> Senior Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>> http://www.google.com/profiles/dan.j.allen
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
5253
days inactive
5267
days old
19 comments
7 participants
participants (7)
-
Dan Allen -
Emmanuel Bernard -
Gavin King -
Mark Struberg -
Pete Muir -
Peter Royle -
Peter Royle