I'm a french computer science student, and I have a small JSF project for school. I'm a little bit noob and I try to pass data between 2 view but I fail.
First I have a view which list all my customers, in a datatable. In this datatable I have a link to show a customer profile. I use, for both view, a CustomerController which is a requestscoped managedbean.
Before I use a global sessionscoped controller but I think it's not the good way to pass data.
Then I found this article : JSF Best Practices, it recommend to use to pass object between views. I didn't manage to make it work.
And finally I found also this question from Stackoverflow : f:setPropertyActionListener sets null value instead of intended value which use
My question is : what is the best ways to pass data ? And how manage it ?
It's explained in this article from BalusC. You need to send id of your selected item to second view through h:link and catch it then with <f:event>.
Related
I am trying to understand MVC pattern correctly.
I am using Java and JFS, which means that each HTML page is linked with back-end Java View class. Then View class calls Controller to retrieve some data. Controller use Data class if needed.
For me it is logical and seems like it is described in this way on this image:
But on this Image I can see another situation, when a front-end HTML calls a Controller class, which is not logical for me.
Both images are taken from here, but other resources gives me the same confusion.
Please, advice where do I have wrong understanding and what should I read to understand it correctly ?
Let me give you my own understating of MVC may be it will help you too.
Modal -> Contains functions process data which comes from the database (Note it is not the actual database. It's just like a shop keeper who knows that when you buy something they are surpossed to pack it for you )
Controller -> If you get data from a user e.g passwords and you are surpossed to checkin if it has a certain chararcters. Functions that are surpossed to do that are the controllers. (Note you could do both Controllers and views in the same place but we divide it to simplify work.)
views -> Views are just like redirectors to the controllers that are surpossed to process what ever the user requests for.
So actually in your second image the requests and response from the browser should be pointing to the views.
With all the tutorial out there, I managed to make a view displayed by a controller. However, I don't understand how do I allow the user to navigate through the site with MVC. Every request to the server must go through the controller? If every request must go through the controller, how am I supposed to let the controller define the type of response it should forward the request to.
Edit: I'm doing a school project which required me to convert my current not reusable code to MVC pattern but I'm not understanding the navigation part of different views. How to get from one view to another view. For example, the navbar element should point to the controller or the view?
The controller comes first, it comunicate with the model and send you to the view you want.
So, for what you need, in the view, just put some link with the url mapped in the controller you want...
The short answer is that all actions "point" to the controller with a parameter telling it what the action is supposed to be, together with any other necessary parameters.
Suppose you have a simple registration form. You may have the following two actions: showRegistration and Register. MVC is not specific to the web, but I will provide the examples in that context (based on your comments). These two actions will point to your controller (say index.jsp) with URLs like this: /index.jsp?act=showRegistration and /index.jsp?act=Register.
Your controller will then have different logic for the different actions (you can do it in many ways yourself, or use some framework which does this switching logic for you). At the end of the day the logic in the controller will boil down to something like this:
if showRegistration:
model.getCountries //to populate a dropdown maybe
view.showRegistrationForm
if Register:
model.validateRegistrationForm
if not valid
view.showRegistrationNotValid
else
model.createUser
if userCreated
view.showSuccess
else
view.showCouldNotCreate
The idea is that the Controller contructs the full action using reusable model and view components. You can use the same model.getCountries in many different places, thus reusing the logic of retrieving a country list.
In practice, it requires a nontrivial effort to generalize the model and view actions. I've seen many projects decent into a chaos of hundreds of components created for a single purpose and used only once, and many components which are essentially duplicates because the developer did not know a similar one already exists, or needed slightly different logic and did not want to bother modifying the old code.
If I have a set of HTML building blocks that are used by many different components, can I use a Java class for that ? Currently I use JSP, but it seems a bit difficult.
For eg: com.mydomain.view.Table.java
and from a JSP I create an object of it, like this :
Table tb = new Table(data);
String html = tb.getHtml();
So is this okay ? good ? better ? or best ?
if not, what is the standard way to achieve this ?
PS: The Table class here has nothing to do with html <table> tag. What that class does is create a tabular structure of data. It may or may not use a html <table>.
Certainly there is no standard way.
So is this okay ? good ? better ? or best ?
The answer depends on the goal of the software you are making.
One important factor to consider is "eventual efficiency".
Looking only at the Table class, it looks good. Constructor clearly states it's dependency on 'data'. getHtml() method, in my opinion, is where it should be.
If you have other views (Swing, Android, ...), you end up with having additional getSwing() or getAndroid() methods. Anyway that's OK, if the Table class is a generic intermediate layer between the real model and the view.
Another possibility is to pass the model or the Table to the JSP view layer, and let the view layer decide how to transform it to HTML. For example by using a taglib (which eventually may call getHtml as well). If you pass the Table, the view gets generic somehow as well (because it can't really decide on how the data is rendered).
With html building blocks, one solution is using jQuery load that returns html.
The combination of Spring MVC with Apache Tiles view is best suited for this.
$("elementId").load("${context}/rest_url_returning_html_building_block");
I have to 4 objects, Group, sections and Questions and their options. Every Group has different Sections and Sections have Multiple Questions and Questions have options. Now I have to design form input system so that every group and sections can be covered up step by step. I’m doing all this in spring mvc.
Can you tell me a way, how can I solve this problem?
You can surely do that in Spring MVC thanks to easy list binding.
Spring MVC allows a big lot of freedom, so basically if you only use this framework, you will have to come up with a solution from scratch.
Here is a use case and a solution. It is a bit tough to implement, as it is from scratch. Feel free to adapt it to your specific needs, add whatever fancy UI framework you want, but you should get a general idea. You can skip to part III for a quick answer.
Let's say you want to create/edit a group in one single page :
you want to edit/add sections to the group
you want to edit/add questions to any section
you want to edit/add options to any question
I. Page design :
You have a JSP Group page with one big single form (again this is just an example)
There will be buttons to add nested stuff. When clicked, some javascript will show a blank form allowing with the information of the stuff. This blank form will itself have buttons to add nested nested stuff to it, and so on (until the stuff is an option).
The design is the same for existing stuff that you want to display/edit, except that the forms won't be blank
You are able to tell whether you are creating or editing the current group (context of the page or javascript/html tricks).
There may be a list of existing sections you could "drag & drop" inside a group thanks to some javascript/jQuery
II. Code design :
You have a GroupController corresponding to the JSP
The Group object has a List<Section> sections attribute, the Section object has a List<Questions> questions attribute, etc.
You have methods createGroup and editGroup
When submitting your JSP form and calling createGroup or editGroup, you are able to know if the submitted elements of the group already exist, so you can decide to add or edit/update them in the DB. All this logic could be done in another class, like a Spring service.
You always provide a possible list of existing sections (by adding this list to the model in both methods, or better yet, by doing a single method annotated with #ModelAttribute). This list could be computed in another class (a Service/DAO/both which taps the DB in the end).
III. The magic : binding the JSP form with the Java controller :
In the page you'll have a <form:form commandName="group">, and in the controller methods parameters you'll have a #ModelAttribute("group") Group group.
Now, to submit the name of the very first option, you would have this in the JSP :
<form:input path="sections[0].questions[0].options[0].name" />
(or the equivalent in html generated by some javascript).
i have a question that is more design and architecture related. I am coming from a classical MVC based background and have to get my hands dirty on JSF2. I read the IBM articles on JSF2 (http://www.ibm.com/developerworks/library/j-jsf1/) and think i understand the overall concept.
I started to get in touch with JSF2 trough ROO. I have the feeling that ROO (maybe this is true for any JSF2-Type App, or maybe not) is making very strange/unclear use of beans. It is in general really not clear to me what the actual role of a Bean is! For example, if i have a view with a form that is for editing a single user-entry, i would initialize the user in a, lets call it UserBean (maybe store in in a member variable) and access this variable trough getters. If i now want to overview all users, i would again render the view in in the UserBean hold a collection of users and again access this collection trough getters. The previous description is actually the way i would do things with jsf. This means i would user the UserBean more as a statefull-service as a controller.
In a typical controller situation i would create for every type of action (list user, edit user, view user, etc) a separate controller, with specific initialized data and this way i would separated the context of the logic by controllers.
I often make use of context specific services, e.g. if i handle user's often an spread over the application, i create a user-service that handles user specific logic that is maybe to complex to be put into the itself. If i now for example look into roo generated Beans, i would find methods that programatically render forms, input fields, labels, that again store list's of users, boolean fields that indicate if data had already been loaded, single user members and a lot of methods that more look like to be put into a UserService (or whatever). I am wondering if this is the way JSF2 is intended to be used, in words: pushing everything that is related to one context into on bean, not making use of service and writing "super-controller-beans" that handle everything.
I don't really know if you get the question right, but what would maybe help me is, a hint to
a very exemplary and commendable example application that makes use of beans the way they where intended to be used in combination with jsf2 features and usecases that for example implement basic CRUD usecases around a given type of entity. (One big confusing point is, that in my case ROO always makes use of AJAX and javascript stuff like Modal-Dialogs to implement CRUD logic. I wonder if with JSF there is a more classical way to to this?[With 'classical' i mean for example URL-Based views and separated views for listing, editing and viewing entities])
a resource that enlightens typical "thats-the-way-the-good-guys-do-it" JSF-Patterns (maybe this is J2EE Patterns?).
Thanks you so much!
Please feel free the push me to concretize specific points if i am not clear!
The link for JSF2 you have posted points to JSF1.2 article. In case you want to start of with JSF2 or JSF I suggest following links.
JSF 2.0 Tutorial # mkYong.com
BalusC JSF blog
Stackoverflow wiki for jsf
I'll suggest start with plain vanilla JSF rather than ROO with JSF to get a hang of JSF.
To answer your question
First link provides you with simple jsf examples, in JSF you can have both ajax based and classical way of submitting form. In JSF 1.x versions ajax was not part and parcel of JSF it was implemented by third party component library mainly RichFaces and PrimeFaces to name few. In JSF2 there is inbuilt support for ajax, this does not apply third party components are no longer required, they still provide some extended features. I'll suggest go through this link to find differences between JSF 1.x and JSF 2.
Patterns I am not aware of as such as specific to JSF apart code can be categorized in model - view - controller. Typical case Person represents model, PersonMangedBean plays role of controller which plays central role of getting data from view(jsp/facelets) and after processing data in bean itself or service beans handles navigation to classic views may be listPersons.xhtml.
JSF managed beans are not "super-controller-beans" handling every thing in that bean. I try to categorize things the way you mentioned i.e. have a service layer where we have all business logic may be EJB or Spring managed bean and it decouples at-least business logic away from view technology JSF whereby it(service) can be reused somewhere else as a library if designed properly.
Tip: JSF is component based framework not an action based and it has lifecycle of its own, do get a grip of that life-cycle will save lots of time and proper understanding of the framework. This link though for JSF 1.x holds good for JSF2 too, for basic understanding of life-cycle.
Hope this helps.