or better process event handlers or action can be 1. in pure java beans (which have to be managed-beans) 2. in the backing beans.
in context of ejb 3.0 you only have to prepare data the and pass the gap between jsf/shale and ejb 3.0. in last the business processes were handled for preparations 1. or 2. should implementing "application controller" or "view controller" to have access to utilzed functions like getbean etc. so model should begins in the called method 1 or 2 end ends there... in context of ejb 3.0 - you couldn't have direct acces to ejb from jsf - and also it isn't possible to mark them as managed beans and dependency injection of ejbs only works in ejb-container itself http://www.diotalevi.com/weblog/?p=129 so the models will be "extended" from web to another container! isnt it? 2006/9/21, stephan opitz <[EMAIL PROTECTED]>:
craig answered for possibilies how to solve shale and ejb 3.0 logic Given that, there are really four general approaches to the business logic of a JSF based application (and they apply pretty much the same with or without Shale). * Embed the business logic in the event handlers (roughly corresponding to embedding business logic in an Action.execute() method in Struts. * Use standard JavaBeans for the JSF backing beans, and put the business in other pure JavaBeans. * Use standard JavaBeans for the JSF backing beans, and put the business logic into an EJB session bean (most likely using annotations to inject this) * Dispense with using a standard JavaBean, and make the EJB session bean be *both* the backing bean and the business logic (this is the approach that JBoss Seam uses, for example). i suppose method 1-3 are one and the same. they use shale backing beans to save the ui component data and only if logic is not inside the backing beans they should be pojos (but for shale lifecycle postback need implements "view controller" or tiger - the pojo too)! the methods: 1a. we can call event handlers: which calls method in the backing bean or outside (pure or a shale javabean implementing "application controller" to have access to utilzed functions like getbean etc.). in both we have the possibility to handle the business logic or we can call business method in ejb 3.0 by given its necessary data 1b. use instead event handlers "normally" action and same conditions as 1) 2. craigs 4 method where merging backing bean and the business logic so i would prefer to say model begins after a method is called! 2006/9/21, Kito D. Mann <[EMAIL PROTECTED]>: > Generally speaking, backing beans serve as adapters between JSF views and > your business logic (which is usually in some other class -- in your case, > EJBs). So, I tend to think think of them as part of the controller, > especially since they can have direct references to UI components, which > definitely isn't something you would do in the model. In your case, I think > that's the role they're playing in your application, because they're > delegating to EJBs. > > That being said, JSF's interaction with backing beans is pretty flexible, so > you could actually use them more as model code, and I believe that's the > approach JBoss Seam takes... > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Kito D. Mann ([EMAIL PROTECTED]) > Author, JavaServer Faces in Action > http://www.virtua.com - JSF/Java EE consulting, training, and mentoring > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info > > > > -----Original Message----- > > From: numpsy beelzebub [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 20, 2006 7:44 PM > > To: [email protected] > > Subject: shale / jsf mvc problems > > > > i tried to understand the context of mvc on which shale is > > built if we use ejb 3.0 as models with business logic... > > > > if i try a button a action will called. mostly an method in > > my backing bean. > > > > tthis prepares data for ejb and afterwards method gives back > > etc navigation case... > > > > so is the action called also model! > > > >
