I've got a stringly-type view defined using #model MyNamespace.Customer with a form created using Html.BeginForm( "NewCustomer", "CustomerReg", FormMethod.Post ) helper.
The NewCustomer action on my CustomerRegController controller looks like
[HttpPost]
public ViewResult NewCustomer( MyNamespace.Customer objCustomer )
I am "filling" from model-bound fields on the page a portion of the Customer fields.
When I submit I get into the correct action, but the objCustomer is all initial values. I though I could pass strongly-typed data that way; am I doing something wrong?
The fact that your view is strongly typed to #model MyNamespace.Customer doesn't mean that this model will somehow be automagically posted to your action when the form is submitted. Basically you need to have input fields for each property you want to retrieve inside your form if you want this property to be passed to your POST action.
Also make sure that this Customer object is a POCO with a default (parameterless) constructor where each property you would like to retrieve has public getters and setters. Otherwise the default model binder will never be able to deserialize the request to this model. The ideal solution to this problem is to use a view model which is a class that you specifically design to meet the requirements of your view and stop passing your domain models to it. This view model will of course have a default constructor and public setters and getters for all properties you would like to retrieve.
Related
I have a method in my JSF controller that is invoked by an ajax tag nested inside a visual component (really irrelevant which one). The method takes a single argument of type AjaxBehaviorEvent, from which I can obtain a Java representation of the invoking HTML visual component as a UIComponent and also downcast it to its specific corresponding type (e.g. h:inputText corresponding to HtmlInputText).
I understand that, in most cases, the value of the HTML visual component would be retrieved easily by referencing either the controller or entity [g|s]etters to which the form fields are mapped in the view. However, in my particular case, I would like to fetch the value of the visual component (in my case a form field) through its Java object rendering. While studying the faces API, I found ways to read various properties of the object, such as the ID or context but not the value that the component currently holds in the view.
Can anybody explain whether I am just not finding the right way to read it or it is so by design? If the latter, can you explain why it is designed like that? Is it to disable "backdoor" access to form fields as opposed to going through the view mapping?
There are a multitude of ways to pull values off a component. Going by what you already have UIInputt#getValue() and UIInput#getSubmittedValue() will provide the value.
The UIInput#getSubmittedValue() is fit for the purpose only between the APPLY_REQUEST_VALUES and VALIDATE phases of the JSF request. All other phases after, use the UIInputt#getValue(). You'll be using UIInput instead of the raw UIComponent you pulled from the event (UIInput extends UIComponent and it's the parent class for all input components that accept user-edited values). What you'll have will eventually look like:
UIInput theInput = (UIInput)event.getSource();
Object theValue = theInput.getValue();
There are other ways (not as clean) to get values within the request lifecycle also
I have created my application using seam-gen. Seam-gen has created all the crud operations & forms for all my objects. They all inherit from seam's EntityHome.
I have this requirement that I need to create from an object A another object B (A has a List). So I need to redirect the user to the B form, save a new B object, and then redirect him to the original A form with the updated List contents.
I am a newbie in Seam and I am not sure how to implement this properly.
Edit: I am using seam version 2.2.2 final.
You can create an action class (similar to how entityHome works without the baggage that comes with it) to manage your contained entities and their behaviors. If no relationship exists between the entities you can make one here.
Refreshing the original list can be tricky, but once you have some code started post it.
So I would start with something like:
Class ActionBean {
ClassAObj classA;
List<ClassBObj> classBList;
public void methodThatLinksAandB() {
// ... stuff happens here
}
// getters and setter for view
// private worker methods
}
for a my current project I would like to overide the context.getUser() method to return a custom pojo which extends the default object returned?
The reason I would like to do is so that I dont have to use the sessionScope technique of saving person specific data and just can call context.getUser() instead (which checks which user is logged on (or anonymous) and retrieves all data needed without.
I would not override context.getUser() - you don't know what else that may require. Have you looked at the userBean and or peopleBean from the extension library? You could use that to get any information you need, then if you need more, or want to create a custom class that extends those beans, install it as a scoped bean in your application, and then use it as the base for your own getUser().
In FubuMVC, when I want a controller action method to return a json result, I use the JsonEndpoint attribute on the method. However there is not a corresponding attribute for a void method that I can see.
For a particular action, I don't want to return anything, but if I have a void return result Fubu fails because it starts looking for a view to match an empty model to.
Is there a attribute or easy change to allow a particular action method to return void?
Thanks
When I updated to a newer version of the framework, one-model-in, zero-model-out controller actions became instantly usable. The only thing I'm not sure how to do is controller-less views.
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.