I have an architecture problem with the following use case.
I have a JSF page for creating JPA entities, for example orders.
The Order entity has two fields: invoiceRecipient and receiver. Both of the type Customer.
There are two fields on the Order form, each with a button that opens a selection list for choosing a customer from the customerSelectionController.
when the customer has been chosen the customerSelectionController bean does something like:
#Inject
#Selected
Event<Customer> customerSelectedEvent;
public void select(Customer customer) {
customerSelectedEvent.fire(customer);
}
and the orderFormController reveives the event with
public void customerSelected(#Observes #Selected Customer customer) {
}
and here is the problem ^^
The orderFormController knows the customer has been selected but is it intended to be set as the invoiceRecipient or as the receiver of the order?
I know you could specify more accurate qualifiers like #SelectedAsInvoiceRecipient but is this really the way how to do this?
Should I copy the customerSelectionController bean as an invoiceRecipientSelectionController and a receiverSelectionController and let both of them fire differently qualified Customer entities?
I am also using Apache Deltaspike that supports GroupedConversations and other complex things, but I couldn't find a specified rule how to achive this.
Thanks for your help
You can either use qualifiers or wrap your Customer entity in a more specific event type, e.g.
public class InvoiceRecipientSelected {
private Customer customer;
// ... add accessors ...
}
Event<InvoiceRecipientSelected> invoiceRecipientSelected;
Related
If I have page, lets say includes two different customers informations, how can I use two different managed beans (which is same java class) in the same page?
As a summary, in the same page I want to hold information of one customer in one bean, another in another bean.
I want to hold information of one customer in one bean, another in
another bean.
Another bean for same purpose is duplication, and If you are thinking it logical. Every page have its page's state (life). when you try #{bean.customer} it will return same value. Because its object is same.
I would suggest to improve your code use another class for the view, layer your application. like
//Base class
public class Customer {
private String id;
/*
*Other fields
*/
//getter Setters
}
#ManagedBean
#RequestScoped
public class PageBackingBean implements Serializable{
List<Customer> customer = new ArrayList<>(); //can Hold more than one customer
public PageBackingBean(){
Customer cus1 = DataBase.loadByCustomerId(id);
customer.add(cus1);
Customer cus2 = DataBase.loadByCustomerId(id);
customer.add(cus2);
}
}
I`m kind of noob to JSF and I'm trying to figure out which would be the most elegant solution for the following scenario:
Let's say that I have a user managed bean called UserMB:
#ManagedBean
public class UserMB {
private User user;
private List<User> users;
// getters and setters here
public void addUser(User user){
// do add user logic here
}
public List<User> listAllUsers(){
// do list All users logic here
}
#PostConstruct
private void init(){
// populate List<user> users - for the listAllUsers scenario
}
}
Let`s assume that i do not have a form to submit directly to listAllUsers() method, but instead i want to see all users when I open the page list-all-users.xhtml.
When I hit the managed bean from addUser.xhtml a query will be performed to DB to load all users because the bean will not know if i want to use listAllUsers() method or addUser() method.
Should i split this functionality in 2 managed beans ?
Because if so I would have to create several managed beans to deal with "User" business (ie. in Struts2 i would have only one Action that would take care of all user interactions).
P.S. I know that there is the solution to populate List in getter method but I read one article of BalusC that advise us not to do this...
Should i split this functionality in 2 managed beans ?
Yes. Use one bean per view/form. Keep the backing bean class as slick as possible. Don't give it too much responsibilities.
I have 2 classes (managed beans) in my business that of type X, the 2 classes merely have the same attributes except for 3 attributes, can i make a DTO contains all the attributes in the 2 beans and let them extends this DTO or i have to group the attributes in the DTO and associate it with the 2 beans so that each bean could set and get its attributes, i want to know the appropriate solution from the point of design, another question is it a correct design for the managed bean and the DTO to have a relation directly.
You could do that but it'd be error-prone, violating the MVC paradigm and simply a bad practice as far as I'm concerned.
Consider and compare two simple cases. First case is a bean extending a DTO and the second case is a bean containing a DTO.
Managed bean that extends a DTO
public class ContactDto {
private String name;
}
public class ContactBean extends ContactDto {
//has name inherited
private boolean renderedAdminPanel;
public void action { }
}
In this case who will be producing managed beans? When will they be instantiated and how? Will your DAO be tightly coupled with ContacyBean? What if you decide to give up using DTOs and use detached entities instead?
All of it increases discrepancies in your architecture and makes it at the very least less manageable.
Now let's consider the alternative approach.
Managed bean that contains a DTO
public class ContactBean {
private ContactDto contactDto;//all fields contained inside
#PostConstruct
public void init() {
//get data from your service based on injected parameter's value and assign it to your DTO
}
private boolean renderedAdminPanel;
public void action { }
}
In this case all logics is crystal clear. Also, you don't need to write 'extras', because all of your properties will be available in EL context with an additional accessor. Your object's lifecycle is predictable and well-formed.
Ultimately, a DTO is a DTO and you wouldn't like to spice it up with additional and possibly secure information, like injected current user, contexts, session variables, etc. to pass that information around. Keep it simple and in its own place.
I've first seen annotating Seam entity classes here
http://www.developer.com/java/ejb/article.php/10931_3715171_5/Introducing-JBossreg-Seam.htm
and for whatever reason I've been doing so ever since:
#Entity
#Table (name= "GADGET")
#Name("gadget")
public class GadgetBean implements Serializable {
private String mDescription = "";
private String mType = "";
...
}
However, I do not use "entity components" like this anywhere in my views. Can anyone explain the use of this and what this gains? Is it a non-practice?
If you are not using any of these entity components in your views, you should remove the #Name annotation.
Seam is great, but seam components come with overhead in the way of interceptors firing every time you access a method in that class. Since you are not accessing these attributes in your view, there is no need to make them into seam components. You are incurring the interceptor overhead every time you use a getter or setter from your entity beans.
Seam-gen, the tool used to create seam projects, can also generate entities that are reverse-engineered from your database tables. By default, the seam-gen entity generator does NOT add the #Name annotation to these classes. That should tell you something!
Hope this helps.
I'm new to JSF and am wondering if I got things right. Let's say I have a simple CMS that makes it possible to write pages.
First, I define a JPA entity called Page:
#Entity
public class Page {
#Id
#GeneratedValue(strategy = GenerationType.AUTO)
#Column
private Long id;
#Column private String title;
#Column private String content;
// getters & setters ...
}
Then I would like in a view to create Page-s. For that, it looks like I need a page bean of some sort. For now I handled things like this:
#Model
public class PageBean {
private Page page = new Page();
public String getTitle() {
return page.getTitle();
}
public void setTitle(String title) {
page.setTitle(title);
}
// rest of properties & getters & setters ...
public void save() {
// persist using EntityManager
}
}
My question is the following one: given that my JPA entity model and the model I want to use in the views are most of the time exactly the same, is there a way of avoiding to have to create a batch of getters & setters in the PageBean?
I read somewhere that you should not use a same bean as JPA entity and JSF model bean (because JSF does repeated calls to getters that may affect JPA), yet I do wonder if there is not a simpler way that would help avoiding this kind of code duplication. Especially when you've got an application with a large model and in many instances do not require anything special in the view beans, it looks like this can get quite cumbersome.
[...] given that my JPA entity model and the model I want to use in the views are most of the time exactly the same, is there a way of avoiding to have to create a batch of getters & setters in the PageBean?
I don't see the point of using a wrapper around an Entity and adding such a layer is indeed duplication. Just use the entity from your JSF page. Yes, this introduce some sort of coupling between the view and the domain but, in general, modifying the database usually means adding or removing fields on the view. In other words, I don't buy the "decoupling" argument and I've written enough extra layers, mapping code, boilerplate code, etc to favor the simple approach when possible.
I read somewhere that you should not use a same bean as JPA entity and JSF model bean (because JSF does repeated calls to getters that may affect JPA)
I'd be interested if you could provide a reference but a wrapper class (delegating calls to the entity) is not going to change anything if there is a problem somewhere.
Just in case, some additional resources:
EclipseLink/Examples/JPA/JSF Tutorial
It's not code duplication. The are no algorithms duplicated. The business logic is still in one place.
What your bean is doing is just connecting the View to the Domain model. This is good, it's part of the MVC pattern.
If you were using your JPA entity as your backing bean, you would be breaking the MVC pattern. For example, if one day instead of displaying a plain String you would need to add a Date to this String because the view requires so (i.e. interface requirements), are you going to write this view logic inside the JPA class? That does not make sense, mixing domain model and view model.
On the other hand, why the view has to know about how the domain is implemented? What if the domain values format change? (For example you save a timestamp String instead a date class in de Database for performance reasons). All you would need to do is just rewrite the method in the backing bean, it would take the timestamp and adapt it to a Date so everything would work as it was before. Just one change outside the JPA class. If you had it in the JPA class you would end up maintaining both logics in just one class (interface logic and domain logic).
What if you want to develop a new view (for example for mobile version)? Are you gonna add even more code to the JPA class? It would be better to keep the JPA as it was and create another Bean (that extends a common bean for both views) for the mobile version.
If after all this, you still want to not to write the getters and setters, you can do
#{myBean.page.title}
all you need is a getPage() inside the backing bean.