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