If in your Java XOM you implement getters and setters, do the Navigation methods in the BOM execute the getters?
Yes, getters and setters can be used as any other methods in the rule. But, you can use the XOM even without getters and setters. And my suggestion is to go without getters and setters. Else if you need you can go..!!
Indeed, the getter and setter, if they exist, are used in preference of directly using the field, if the getter and setter are public.
Yes.
The tricky part is that Java getters and setters typically show up in the BOM as attributes, not methods. ODM automatically maps them like that by default. And then the navigation phrase will be on the attribute.
You can override that behavior overall by setting an option or one at a time by deleting the BOM attribute from the BOM class and definingthe getter (and setter) BOM method in its place (with B2X that references the Java method).
Related
In a UML class diagram, if a class has 5 private attributes that need to be mutable and readable, the UML gets pretty ugly with 10 get/set methods even without any of the class' interesting functionality:
Ugliness aside, I feel like the UML should focus on the class' more interesting functionality. Am I correct?
Is there some standard shortcut for denoting or implying getters and setters for private attributes?
You are correct: there is no need to include the (noise of) "boilerplate" signatures of standard setters and getters in a class model. Unfortunately, UML does not define a standard notation for implying getters and setters for private attributes. So, you'd have to use your own convention. For instance, you could include a general explanation (that all private properties have getters and setters, while private read-only properties have only getters) as a UML Comment, shown as a rectangle with the upper right corner bent (also called a “note symbol”) attached to the diagram.
If you prefer to make the getter/setter convention more explicit for the properties concerned, then create your own stereotypes (e.g., «get/set» and «get») to be used for categorizing these private properties, as shown in the following diagram:
I'm also using this for describing/documenting the implicit getters and setters of ECMAScript 6 classes.
UML does not define getter setter operations. Get and Set method are used in programming languages to realize attribute definition. For example, readonly attribute will have getter method only in implementation code. if attribute is defined as calculated, getter method is usually used in code to implement calculation, and setter can be leaved out, because calculated attributes are usually readonly. Visibility of attribute is usually moved to visibility to getter and setter methods in code as well.
It does not make sense to define geter and setter methods in code for attributes defined read write and not calculated.
In a button I can see three properties action, actionListener & actionListeners. I tried to use the actionListener property by creating a class implementing java.awt.event.ActionListener and implementing actionPerformed method and then calling the class using expression language. But nothing happened.
Even the documentation on these properties is cryptic. Can anyone explain how these properties are used and their purpose?
I think you need to use "javax.faces.event.actionlistener" and it uses processAction method. I assume you know though that xpages uses xp:eventHandler's instead of the vanilla JSF 1.1 attributes you mentioned.
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.
I am new to JSF and managed beans. I have a managed bean with some private property with public setter and Getter methods. Now when I add the managed bean's properties to JSF forms, should I add the private methods directly or should I use call the property by Getter methods?
For example:
<h:inputText value="#{BeanName.userName}"/>
<h:inputText value="#{BeanName.getUserName()}"/>
Which one is correct in above?
Assuming that you're using JBoss EL or EL 2.2+, both ways would work fine in the initial display. But the first one is actually more correct because the second one would only get the value, but never set the value. If you want to collect input values, you should always go for the first way. The EL (Expression Language) will then automatically locate the getUserName() and setUserName() methods whenever needed.
The second way will never work when you're using standard JSF EL implementation since it doesn't support direct method calls.
To learn more about JSF, start at our JSF wiki page.
If in your java class you have something like
....
private String coolStuff;
public String getCoolStuff() {
return coolStuff;
}
....
Then in your jsf page you access it like so:
#{myBackingBean.coolStuff}
The framework automatically looks for a method called getCoolStuff()
Hope that helps
number 1 is correct from above it is the private field that you connect if you are using EL with JSF in your form.
You still need the getter and the setter which the managed bean calls to get the values so you can save them in a database ....etc