Win a copy of Head First Android this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

One View:two backing beans and a commandButton

 
Greenhorn
Posts: 23
Eclipse IDE Tomcat Server Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a view that is supposed to show data from different tables. For this, I have separated the business logic into different backing beans, sdHandler and urlaubHandler,which then connect to the DAO-Layer. The first iinitialization of the urlaubHandler initializes a parameter "sd" via faces-config.xml, but after the first loading of the view the component "showUrlaub" has no way of knowing for which person it should load the corresponding data- when <h:commandButton styleClass="calNavBtn" value="Edit"
action="#{sdHandler.editStammdaten}"> is called

What is the best for backing beans to share a "global" property? Is it possible or even suggested?

 
Saloon Keeper
Posts: 24553
168
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My current standard architecture for complex JSF programs with extensive database interaction is to use the Spring Framework to construct and wire the persistent logic objects and inject the Spring beans into JSF backing beans as needed.

The persistency subsystem has 3 layers:

1. Business-logic persistency ("service")
2. Database-logic persistency ("dao")
3. Domain model objects (via JPA)

The dao layer consists of Spring beans that each deal with a single table (or sometimes parent/child table). The methods are all basic CRUD and finder methods, not business-related.

The service layer consists of beans that support specific business functionality. They provide the support needed to co-ordinate the storage and retrieval of related sets of domain-model objects (working sets). The methods within this layer are each implementations of a single transaction. The service beans are injected with dao beans that handle the per-table support. The service methods are injected as managed properties into JSF backing beans, or occasionally into application business-logic beans. The domain objects at these higher levels are detached and non-transactional.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic