Is MVVM design pattern supported by JSF? - jsf

I am using ZK Framework right now in one of my application. ZK Framework supports MVC as well as MVVM design pattern. Now for a new project I would like to use JSF. Does JSF support the both the design patterns or only MVC?

No, MVVM design pattern not supported by jsf only MVC support.It is used only desktop application.JSF also know as MVC fremework.
From http://blog.oio.de/2011/12/05/jsf-and-mvvm/:
The first M in MVVM stands for Model, and it is the very same model that we use in our MVC approach. In fact MVVM does not replace MVC, I rather prefer to see it as an additon to MVC, so there is nothing new here.
The first V in MVVM stands for View and again, there is nothing new to this part. It is the component that takes care of the client side representation. So there wont be any notable change to our views since we will continue to define them using Facelets.
VM in MVVM stands for the ViewModel, our client side model. The ViewModel is bound to the Model but it is exisitent only on the client side, though you are free to sync it whenever needed with the Model on the server side. But, more important is, that you can do whatever you want on the client side without having to send callbacks to the server.
First of all we need a next-generation-JSF-implementation, which supports the MVVM concept. The ViewModel would be created by this yet to come JSF implementation before a requested view is delivered to the client. Our ViewModel will be created from one or more JSF Managed Beans that form the Model. I can think of a nice set of class- and field-level annotations to tell JSF what parts of our model should make up the ViewModel on the client side. Once the view is delivered to the client, the ViewModel will be manipulated by client side scripts upon the form is submitted. Then, in the following iteration of the request processing lifecycle, JSF has to deal with resynchronization between ViewModel and Model. Admittedly, this might be the most tricky part, but I’m confident that the Next-Gen JSF Impl will manage to do that ;-)
From Understanding JSF as a MVC framework:
The nodes M, V and C are a maximum connected graph, meaning each part can communicate with every other part. E.g. if the model changes, it can push this change to the view. This is particularly visible in case there are multiple representations of the view in a desktop application. Change one, and see the other update in real-time.
Due to the client/server and request/response nature of web applications, classic MVC doesn't map 1:1 to most web frameworks.
More information find this link: http://www.tutorialspoint.com/jsf/jsf_architecture.htm

I disagree with user2860053's answer because it makes unnecessary assumptions about MVVM. MVVM is not about client and server responsibilities. The blog post cited only argues that a specific web application scenario involving a combination of client-side MVVM (as implementend by knockout.js) with server-side MVVM doesn't work well with JSF. It doesn't say anything about server-side MVVM.
In my understanding (which IMO corresponds to the original definition that is also referred to by the ZK documentation), the core ideas of MVVM are:
a) to keep a distinction between the UI's concrete structure, controls and layout (i.e. the view) and its state and behaviour (i.e. the viewmodel), and
b) link these using a two-way data binding.
Figuratively speaking, starting from "MVC", part a) adds the "VM", and part b) removes the "C" so we yield "MVVM":
In MVC, the controller is written for a specific view class/interface, and it's the controller's responsibility to read user input from the view, convert it and write it to the model, and to invoke business logic according to the user's action.
In contrast, MVVM doesn't have any controllers that are tightly coupled with view or model. Instead, there is a generic mechanism which uses declarative two-way data bindings for filling the view with data and converting user input and feeding it to the model, and for binding controls to business code (or presentation-only actions from the viewmodel).
So how does this apply to JSF?
In JSF, you don't write a controller for every Facelets page you write, but let the JSF lifecycle do the work of filling model elements with data from submitted forms and invoking methods according to the user's actions according to EL bindings, so the second property b) always holds for JSF.
As for the first property a), it's up to the programmer to implement high-level view state and behaviour in separate classes.
JSF puts more focus on creating components for view state and behaviour.
Viewmodels are made specifically for one kind of view, and model the whole abstract state and behaviour of the view, so I think that even "light-weight" composite components are too generic to take the role of a viewmodel. But there is nothing to prevent the developer from creating his own classes for this, i.e. write one's own viewmodel classes and bind them in the EL context.
In conclusion, JSF is not made specifically for MVVM, but contains mechanisms that can be used for implementing (server-side) MVVM.

Related

Where to use FacesContext object? [duplicate]

I am not sure whether my approach with the MVC environment in JSF is the best way to go. Since I am trying to get the most out of JSF I would like to know how my Service Layer (or Model, speaking in MVC terms) should be 'designed'.
I know the View-Controller ratio should be 1 to 1 (exceptions ruled out).
Now in what way should I design my Service Layer? Should I use one big service (don't think so)? If not, based on what should I split my services?
Note, my Service will be called from the Beans (Controllers in MVC terms) and the Service itself will call DAO's using JPA when necessary.
Thanks in advance
The service layer (the business model) should be designed around the main entity (the data model). E.g. UserService for User, ProductService for Product, OrderService for Order, etc. You should absolutely not have one huge service class or so. That's extreme tight coupling.
As to the service layer API itself, Java EE 6 offers EJB 3.1 as service layer API. In the dark J2EE ages, long time ago when EJB 2.0 was terrible to develop with, Spring was more often been used as service layer API. Some still use it nowadays, but since Java EE 6 has incorporated all the nice lessons learnt from Spring, it has become superfluous. Note that EJB (and JPA) is not available in barebones servletcontainers such as Tomcat. You'd need to install for example OpenEJB on top of it (or just upgrade to TomEE).
Regardless of the service layer API choice, best would be to keep your JSF backing bean (action)listener methods as slick as possible by performing the business job entirely in the service layer. Note that the service layer should by itself not have any JSF dependencies. So any (in)direct imports of javax.faces.* in the service layer code indicates bad design. You should keep the particular code lines in the backing bean (it's usually code which adds a faces message depending on the service call result). This way the service layer is reuseable for other front ends, such as JAX-RS or even plain servlets.
You should understand that the main advantage of the service layer in a Java EE application is the availability of container managed transactions. One service method call on a #Stateless EJB counts effectively as a single DB transaction. So if an exception occurs during one of any DAO operations using #PersistenceContext EntityManager which is invoked by the service method call, then a complete rollback will be triggered. This way you end up with a clean DB state instead of a dirty DB state because for example the first DB manipulation query succeeded, but the second not.
See also:
Creating master-detail pages for entities, how to link them and which bean scope to choose
When is it necessary or convenient to use Spring or EJB3 or all of them together?
JSF Controller, Service and DAO
The 1:1 ratio between services and model entities maybe not bad if you have few entities in your app. But if it is a big app, there would be too much services.
The number of services depends upon the use cases of the app you are designing. Once you have identified them in the analysis phase, you must group them in several groups according to their functionality. Each group of use cases will be a Service, and each use case will be a method in that service. Each Service can manage several model entities (and you have to inject in it the DAOs it needs to perform its functionality). Usually the uses cases of a Service manage model entities inter-realationated in the class diagram of the model. The Services might follow the good practice of "max cohesion / min coupling".
The ratio between DAOs and model entities is 1:1. Each DAO perform CRUD operations and queries of its entity. If a method needs to query 2 relationated entities, put it in the more suitable DAO depending on the business concepts.
In the JSF presentation layer I neither have a 1:1 ratio between pages and controllers, that would be too much controllers. I group into one contrller all the pages needed to perform the use cases of each service. So the ratio 1:1 is between controllers and services, injecting each service in the controller whose pages perform its use cases.
Of course, these are general principles. You may have some particular cases in the app that broke them, but they are few.
You might not have too much services and controllers, but not too few neither because then they would have too much logic and fields. You must acchieve a compromise.

REST Services or Repeat Control with Java Object in a Data Table

Over the past couple of years or so I have revamped most of my Notes Applications for XPages and of late made extensive use of Java objects in Repeat Controls etc.
I am now implementing, where appropriate, jQuery DataTables in an attempt to generate the same functionality as Notes Views where appropriate. My applications vary from a few document records to several thousand.
Most of the Data Table tutorials etc seem to imply or recommend the use of REST Services for Data Tables. What is the reason for this when I can simply drop my existing Java Objects into Repeat Controls and then access the back end documents via links etc.
Sorry if this is not a coding question, but I am clearly missing something fundamental in my basic knowledge. Any advice would be appreciated.
The short version is that jQuery data tables are built by purely (CS)JS, meaning any "normal" transport of data like a REST service (such as how you're describing using xp:restService) is pretty standard and ubiquitous. jQuery itself has no knowledge directly of any underlying Java objects and doesn't care what backs the service.
If you were using an xp:repeat control you could bind to a backing List or other iterable collection from a backing Java class / bean. This would make far more sense if that's how you'll present the data. The logic shift is that specifically any time you update your xp:repeat, you must send an AJAX (XHR) wrapping around that xp:repeat tag, whereas a jQuery update from a REST service will get only the data response. There is some overhead to using AJAX to refresh part of the page (which literally is replacing part of the existing DOM with the newly fetched HTML and parsing the content), but at smaller scales, it's not a huge amount.
Using a REST service means that:
your front-end implementation will be more consistent with the majority of the rest of the web development industry
your back-end logic will be segregated, (ideally) making it more easy to port, migrate, or document
There's nothing wrong with implementing an xp:repeat (or friends) with backing Java on XPages, especially if you're using primarily XPages controls.
There are many ways to implement a RESTful service in XPages and the reasoning behind why to go for RESTful APIs in the XPages runtime is something both myself and many others have blogged about.

What are Haskell continuation based web framework?

Occasionally I encounter the notion of continuation based web frameworks for Haskell. What does that mean exactly?
Continuations as I know them are gloried goto control structures. I fail to see how they relate to web stuff.
What exactly would using continuations give?
A continuation-based web framework inverts flow of control in a web application. Instead of being page-oriented, it's flow-oriented. Displaying a web page is treated the same way as displaying a modal dialog in a desktop application. The flow of control (from the perspective of the user of the framework) is that one imperative action can request the display of multiple pages. The continuation being referred to is the rest of the action the user started.
The canonical continuation-based web framework for Haskell is the venerable WASH system.
The idea is to capture state in the continuation, allowing for fully RESTful, stateless web apps that can in some cases be generated automatically from the non-continuation-based version of the program.
From "WASH/CGI: Server-side Web Scripting with Sessions and Typed, Compositional Forms": (2001):
The main idea is to use a continuation to take a snapshot of the state
of the script after sending the form to the browser. This continuation
is then stored on the server and the form contains a key for later
retrieval of the continuation.
A modern description of the approach is given in the MFlow Monad Reader overview.

JSF's javax.faces.ViewState antipatterns

This question probably does not fit SO rules, but I'll ask it anyway. Answers might help other people struggling with JSF.
We are using JSF (MyFaces, PrettyFaces, PrimeFaces and Spring) on one of our biggest project for two years now (migrated from Tapestry 3). I can say that we are "recovering" from this migration to this day.
In my opinion one of our major mistakes was misunderstanding of JSF's VIEW SCOPE. JSF offers two basic mechanisms how you can persist VIEW STATE - CLIENT and SERVER. We went for the SERVER method, which was our first mistake as ViewExpiredException never stopped coming from that moment on. The next mistake was to store data on VIEW SCOPE as that prevented us from easily switching to CLIENT state saving method.
So I was thinking whether there are some best practices and guidelines on what should and shouldn't be stored on VIEW SCOPE (and thus serialized into VIEW STATE). Official documentation and specification does not provide that. But I came to a quite nice conclusion:
You should only store on VIEW SCOPE such information that you would normally (without JSF) pass as request parameters.
When you have a basic CRUD application without JSF, you would do this:
state of the form is preserved between requests by form values in POST parameters
state of the list (filtering, sorting, paging) is preserved between requests by query parameters
Is my conclusion correct? Do you have any other guidelines on what to store and what to never store inside VIEW SCOPE? Do any component frameworks have such guidelines?
i use the following Guidelines:
avoid VIEW SCOPE as it is only available for Faces Manages Beans.
better: avoid the usage of Faces Managed Backing Beans. use CDI Managed Backing Beans to ensure portability. (sure, this is only possible if you have any cdi container available... in Java EE 6 and newer...)
avoid AJAX with JSF. (or only use it with caution for simple UIs...)

Java EE: separating presentation logic from business logic using beans

I've been developing my first Java EE app, which has a number of JPA entity classes, each of which have a corresponding EJB class for dealing with the business logic. What I've done is changed one of those beans from Stateless to SessionScoped, so I can use it to allow a user to work their way through a series of form fields, all of which are rendered on a JSF form.
However, I'm starting to think this is clearly wrong, as I'm doing things like implementing methods such as "submitStep1" and "goBackToStep2" in my EJB. These methods set indicators which are used by render elements of various tags on the JSF page, so they are clearly "presentation logic".
My question is, how should I re-structure my code? I'm thinking that I should just have one SessionScoped (or should that be stateful?) bean, which deals with the presentation logic of my JSF page, and is able to use all the other ejbs (and by extension my JPA classes). This bean would be in the presentation-tier level of my app, meaning my business logic tier wouldn't need any Session Scoped Session Beans.
Now this all makes sense to me, and is what I am probably going to do. However the reason for my question is that on my JSF xhtml pages I use JSF EL tags a lot to refer to EJB content. Are there any JPA-related pitfalls I need to watch out for when writing presentation tier classes?
I know my question is pretty vague, and not really related to a specific example. And although I've found quite a lot out about Stateful v Stateless beans on this and other sites I just want to know my intended structure is the best one.
Why don't you use backing beans for presentation purpose, as they are intended for it, and you can easyly configure its scope, and leave the EJBs to business tier?
When using entities directly on the presentation tier, you should be aware of the transaction scope, specially regarding lazy relationships. That is, normally it is used one transaction per request, what will mean that amongst different requests, the entities will become detached, so you will need to reatach them to be able to load lazy relationships. You could use a filter that does it automatically each request or handle it by hand. You could also keep the same transaction during different requests but a long transaction is normally not a good idea, specially if there are updates/creations in the DB during this transacion.

Resources