Is it good to code JSP-specific information in EJB??

[hsiung]

Hi all architects in this forum

in all Seam examples you can see that the idea of Seam is to code JSP specific information like the next page ("/registered.jsp") in the Session Bean on the EJB container.
Doing so the EJB level is aware of the upper level, Web in this case.
Wouldn't it be better to stay neutral and enable Rich-Client (Swing or any Standalone Java-Client) to use the same Stateless Bean?
Originally, the idea of EJB was to allow at least these 2 clients (Web-Container and Java-Client).
Or is the Seam idea to duplicate Session Beans, one for web container and another for Java-Client?

What is you opinion?
Thanks for a feedback.

Alain Hsiung

[pmuir]

You can use pages.xml navigation to completely remove navigational information from the EJB or outcomes to partially remove navigation

[hsiung]

hi Peter

thanks for your reply. I agree with you: pages.xml may remove JSF information from the EJB layer.

And what about UIData instances?
If UIData instances live on the Web Container we do not have JSF information in the EJB layer but how can you implement it without backing bean (that Seam is intended to remove)?

Cheers
Alain

[pmuir]

If you use the Seam Application Framework (or even @DataModel) you shouldn't need to put UIData into your Seam components. Unfortunately we still haven't got it that good for trees yet (the other case where you need to put JSF stuff in the backing layer) - but that is really the only case when I have to put UI in a component.

[hsiung]

do I understand you correctly that using @DataModel won't impact the interface of the session bean for swing clients? In other words swing clients will use the exact same session bean interface as JSF.

[pmuir]

Yes, You can use the same interface BUT Seam doesn't yet support Swing - so stuff like Seam's injection won't work. Shane's work on WS should start to close this gap - we will have a model for building bridges to clients other than JSF

[hsiung]

Hi Pete

I don't understand how to avoid using UI elements like ValueChangeEvent when using SelectOneRadio.
Or simply how to use SelectOneRadio in a table without using UI information on the EJB container.
I just want to select a row (I think SelectOneRadio is apropriate) and then choose an action (press a button). On the SFSB the action should know which row has been selected.

Thanks for your help
Alain

[jazir1979]

Hi,

If seperating these UI concerns from the business logic is a great concern, there is no reason you can't have a more traditional stateless service layer that your Seam EJBs talk to, and which could then be used by other clients.

You'll need to get your persistence context strategy right, so that your Seam-managed PC propagates into the next layer (if you want that), but it's definitely possible.

Remember though that other non-Seam clients of this service layer won't have a Seam-managed PC and will need everything fully populated if you want to avoid lazy initialisation exceptions and the like.

Daniel.

"hsiung" wrote:
Hi Pete

I don't understand how to avoid using UI elements like ValueChangeEvent when using SelectOneRadio.
Or simply how to use SelectOneRadio in a table without using UI information on the EJB container.
I just want to select a row (I think SelectOneRadio is apropriate) and then choose an action (press a button). On the SFSB the action should know which row has been selected.

Thanks for your help
Alain

[jazir1979]

...and remember - 95% of web apps never end up needing this, which is the whole point of simplifying and unifying things in a framework like Seam. So make sure this is a true requirement that you'll actually make use of before you go and complicate the architecture..!

[hsiung]

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

[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

[jazir1979]

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

[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