17:29:46 <lightguard_jp> #startmeeting
17:29:52 <jbott> Meeting started Wed Mar 16 17:29:46 2011 UTC.  The chair is lightguard_jp. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:29:52 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:29:54 <lightguard_jp> #topic Seam 2 bridge for Seam 3
17:29:58 <lightguard_jp> #chair mojavelinux
17:30:03 <jbott> Current chairs: lightguard_jp mojavelinux
17:30:16 <gastaldi> #info CDI does not supports @Out from Seam 2
17:31:14 <mojavelinux> if you turn outjection on it's head and expose the state of the system rather than pushing objects to the top level
17:31:19 <mojavelinux> then you have producers
17:31:36 <mojavelinux> true, we could emulate an @Out by writing to a bucket, like a map
17:32:10 <mojavelinux> but I think we want to encourage people away from that model, the reason it was dropped it because tooling (and humans) didn't know what populated a variable
17:32:14 <gastaldi> #info It´s a good practice never mess with the top level context
17:32:37 <mojavelinux> now, you can click on an EL expression and it jumps you to the matching producer
17:32:41 <mojavelinux> now that makes sense
17:33:02 <mojavelinux> and a producer can be a calculated product
17:33:13 <mojavelinux> it can be an alias to a getter method
17:33:20 <mojavelinux> or it can be a direct field reference
17:33:30 <mojavelinux> which is about as close you get to outjection
17:33:44 <mojavelinux> the one benefit that outjection added
17:33:56 <mojavelinux> was that it woudl transform the data transparently before it was pushed out
17:34:01 <mojavelinux> like wrapping a list as a datamodel
17:34:07 <mojavelinux> that can be done with a producer method
17:34:12 <mojavelinux> and we could even have that dynamically
17:34:16 <mojavelinux> in seam faces
17:34:21 <mojavelinux> like this
17:34:25 <mojavelinux> @Produces @DataModel List<Stuff> getStuff() {}
17:34:37 <mojavelinux> CDI can register a new producer method dynamically
17:34:42 <mojavelinux> that provides
17:34:48 <mojavelinux> @Produces DataModel getStuff() {}
17:34:53 <mojavelinux> good feature for seam faces ;)
17:35:12 <mojavelinux> being about to add producer methods is super cool
17:35:26 <mojavelinux> and have them delegate to the original producer method and wrap the result
17:37:23 <gastaldi> Anything else ?
17:38:24 <mojavelinux> one of the real pains that we have to deal with
17:38:28 <mojavelinux> that outjection was good for
17:38:32 <mojavelinux> is that in jsf
17:38:37 <mojavelinux> producers are read as a page is restored
17:38:44 <mojavelinux> and often you want to reproduce before the page is rendered
17:38:54 <mojavelinux> so we've solved that problem in part with some new scopes in seam faces
17:39:04 <mojavelinux> but without those scopes, you get the problem where your producers are too sticky
17:39:10 <mojavelinux> if they are request-scoped that is
17:39:17 <mojavelinux> request scope turns out to be a pretty bad scope in jsf
17:39:25 <mojavelinux> because really there are two parts of a jsf request
17:39:35 <mojavelinux> and what is good for restore often isn't good for render, things change
17:43:18 <gastaldi> I think this is enough. Anyone ?
17:44:04 <gastaldi> #endmeeting
17:46:00 <lightguard_jp> #endmeeting