Hi Alain, I think that should work using the @DataModelSelection annotation to inject the selected row. I guess our experiences are different, because I've rarely used existing EJB services written "years before" for a new UI. But as I said, it's easy to keep this separation, so what is the big deal with having UI concerns in your Seam EJBs? If you use RichFaces, being able to inject a UI component and manipulate it based on an AJAX-initiated action can be very handy: @In(required = false, value = "#{uiComponent['panel']}") private UIPanel richPanel; Daniel. "hsiung" wrote : hi Daniel, | | I'm not sure I understand your point. In a matter of facts, actually in most cases I know of, the EJB services are settled. New web applications running on a web container use EJB services already written years before. It would be complicating the architecture to introduce UI concerns in a service layer that is per definition a UI neutral layer. Yes, separating UI concerns from the service layer is a true requirement. | | I was refering to Pete's statement | anonymous wrote : [the tree case] is really the only case when I have to put UI in a component. | As I understand his statement, SelectOneRadio (which is NOT a tree) works without putting UI concerns in the EJB layer. I'm sure he is correct. So I simply ask how do SelectOneRadio works without ValueChangeEvent in the EJB, assuming we remove the backing bean in the web container with Seam. | | Alain View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4047080#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...