Showing posts with label jsf. Show all posts
Showing posts with label jsf. Show all posts

Friday, July 11, 2014

Difference between Request MVC and Component MVC

In request (action) based MVC, a single front controller servlet will delegate to action models based on request URL/params. You works directly with raw HttpServletRequest and HttpServletResponse objects in the action model. You've to write code yourself to gather, convert and validate the request parameters and if necessary update the model values before you can ever invoke the business action.
In component based MVC, a single front controller will gather, convert and validate request parameters and update the model values itself so that you only need to worry about the business action yourself. How the controller needs to gather/convert/validate/update the values is definied in a single place, the view. Since that's not possible with "plain" HTML, a specific markup language is required to achieve the goal. In case of JSF 2.0, that's XML (XHTML) based. You use XML to define UI components which in turn contain information about how the controller should gather/convert/validate/update the values and itself generate the necessary HTML representation.
Advantages and disadvantages should be clear at this point: With a request based MVC framework you need to write more code yourself to achieve the goal. However you end up with much more fine grained control over the process and the HTML/CSS/JS output. With a component based MVC framework you don't need to write much code yourself. However you have less fine grained control over the process and the HTML/CSS/JS output. So if you'd like to do things a bit differently than the standard describes, you'll waste a lot more time in a component based MVC framework.

See also:

Friday, January 24, 2014

Conditionally displaying JSF components

Yes, use the rendered attribute.
 rendered="#{some boolean condition}">
where some boolean condition can be anything like:
 rendered="#{bean.booleanValue}" />
 rendered="#{bean.intValue gt 10}" />
 rendered="#{bean.objectValue eq null}" />
 rendered="#{bean.stringValue ne 'someValue'}" />
 rendered="#{not empty bean.collectionValue}" />
 rendered="#{not bean.booleanValue and bean.intValue ne 0}" />
 rendered="#{bean.enumValue eq 'ONE' or bean.enumValue eq 'TWO'}" />
Let's assume that the link is passing a parameter like
 href="page.xhtml?form=1">link
then you can show the form as follows
 rendered="#{param.form eq '1'}">
(the #{param} is an implicit EL object referring to a Map representing the request parameters)

See also:

Wednesday, November 6, 2013

How to choose the right bean scope?

It represents the scope (the lifetime) of the bean. A request scoped bean lives as long as a single HTTP request-response cycle. A view scoped bean lives as long as you're interacting with the same JSF view by postbacks returning null/void. A session scoped bean lives as long as the established HTTP session. An application scoped bean lives as long as the web application runs.
Which scope to choose depends solely on the data (the state) the bean holds and represents. Use the request scope for simple and non-ajax forms/presentations. Use the view scope for rich ajax-enabled dynamic views (ajaxbased validation, rendering, etc). Use the session scope for client specific data, such as the logged-in user and user preferences (language, etc). Use the application scope for application wide data/constants, such as dropdown lists which are the same for everyone.
Abusing an application scoped bean for session/view/request scoped data would make it to be shared among all users, so anyone else can see each other's data which is just plain wrong. Abusing a session scoped bean for view/request scoped data would make it to be shared among all tabs/windows in a single browser session, so the enduser may experience inconsitenties when interacting with every view after switching between tabs which is bad for user experience. Abusing a request scoped bean for view scoped data would make view scoped data to be reinitialized to default on every single (ajax) postback, causing possibly non-working forms (see also points 4 and 5 here). Abusing a view scoped bean for request scoped data doesn't affect the client, but it unnecessarily occupies server memory.
Note that the scope should rather not be chosen based on performance implications, unless you reallyhave a low memory footprint and want to go completely stateless; you'd need to use exclusively request scoped beans and fiddle with request parameters to maintain the client's state.

See also:

Wednesday, October 9, 2013

Java - How to change context root of a dynamic web project in eclipse

I'm sure you've moved on by now, but I thought I'd answer anyway.
Some of these answers give work-arounds. What actually must happen is that you clean and republish your project to "activate" the new URI. This is done by right-clicking your server (in the Servers view) and choosing Clean. Then you start (or restart it). Most of the other answers here suggest you do things that in effect accomplish this.
The file that's changing is workspace/.metadata/.plugins/org.eclipse.wst.server.core/publish/publish.dat unless, that is, you've got more than one server in your workspace in which case it will be publishN.dat on that same path.
Hope this helps somebody.

Not sure if this is proper etiquette or not -- I am editing this answer to give exact steps for Eclipse Indigo.
(1) In your project's Properties, choose "Web Project Settings".
(2) Change "Context root" to "app".
screen shot of Eclipse project properties Web Project Settings
(3) Choose Window > Show View > Servers.
(4) Stop the server by either clicking the red square box ("Stop the server" tooltip) or context-click on the server listing to choose "Stop".
(5)On the server you want to use, context-click to choose "Clean…".
enter image description here
(6) Click OK in this confirmation dialog box.
Screenshot of dialog asking to update server configuration to match the changed context root
Now you can run your app with the new "app" URL such as:
Doing this outside of Eclipse, on your production server, is even easier --> Rename the war file. Export your Vaadin app as a WAR file (File > Export > Web > WAR file). Move the WAR file to your web server's servlet container such as Tomcat. Rename your WAR file, in this case to "app.war". When you start the servlet container, most such as Tomcat will auto-deploy the app, which includes expanding the war file to a folder. In this case, we should see a folder named "app". You should be good to go. Test your URL. For a domain such as "example.com" this would be: http://www.example.com/app/
Thanks so much to Russ Bateman for posting the correct answer to this frustrating problem.
Vaadin toolkit programmers may need to rebuild their widget set if using visual add ons.
--Basil Bourque

Monday, October 7, 2013

Difference between managed bean and backing bean

What is Managed Bean?
JavaBean objects managed by a JSF implementation are called managed beans. A managed bean describes how a bean is created and managed. It has nothing to do with the bean's functionalities.
What is Backing Bean?
Backing beans are JavaBeans components associated with UI components used in a page. Backing-bean management separates the definition of UI component objects from objects that perform application-specific processing and hold data. The backing bean defines properties and handling-logics associated with the UI components used on the page. Each backing-bean property is bound to either a component instance or its value. Backing bean also defines a set of methods that perform functions for the component, such as validating the component's data, handling events that the component fires and performing processing associated with navigation when the component activates.
What are the differences between a Backing Bean and Managed Bean?
Backing Beans are merely a convention, a subtype of JSF Managed Beans which have a very particular purpose. There is nothing special in a Backing Bean that makes it different from any other managed bean apart from its usage.
MB : Managed Bean ; BB : Backing Bean
1) BB: A backing bean is any bean that is referenced by a form.
MB: A managed bean is a backing bean that has been registered with JSF (in faces-config.xml) and it automatically created (and optionally initialized) by JSF when it is needed.
The advantage of managed beans is that the JSF framework will automatically create these beans, optionally initialize them with parameters you specify in faces-config.xml.
2) BB: Backing Beans should be defined only in the request scope
MB: The managed beans that are created by JSF can be stored within the request, session, or application scopes .
Backing Beans should be defined in the request scope, exist in a one-to-one relationship with a particular page and hold all of the page specific event handling code. In a real-world scenario, several pages may need to share the same backing bean behind the scenes. A backing bean not only contains view data, but also behavior related to that data.

Friday, January 13, 2012

Mojarra JavaServer™ Faces JSF 2.0 from Sun

What is JavaServer™ Faces (JSF)?
>JSF is the Java™ EE and de-facto standard web framework that hides complexity to maximize
developer productivity. JSF provides a component model, page templating, Ajax support, client device
independence, and world-class IDE integration from every available Java IDE.
>There is a vibrant market for high quality third party extensions such as components, including ADF
Faces, Trinidad, ICEFaces, RichFaces, NetAdvantage, JViews, and many others
>Easy Integration with popular enterprise technologies, including Hibernate, Spring, Seam, Jasper
Reports and more.
>JSF 2.0 is compatible with JavaEE 5 application servers, or any server implementing Servlet 2.5.
>The JSF 2.0 standard was finalized in May 2009 and will be included in JavaEE 6, and in all
application servers that meet the JavaEE 6 standard, including Glassfish V3, available in a preview
release for JavaOne 2009.
>JSF is very widely used in production. A selection of users taken from the public Wiki page, at
. includes: Credit Suisse, Federal Express,
Deutsche Bank, Apple Computer Inc., Garmin, RiteAid, BigLOTS!, Virgin online, and more.
What is Mojarra?
>Mojarra is Sun's high performance, battle-tested implementation of JSF, and is used in IBM
WebSphere™, Oracle WebLogic™, Oracle 10g Application Server, SpringSource dm Server™, and
other popular enterprise platforms.
>Like all of Java, Mojarra is open source, dual licensed with GPL+Classpath Exception and CDDL.
>Mojarra was the first JSF runtime to support Groovy, and does so for all of JSF
Why should you use JSF 2.0?
>Built in templating with Facelets
>Full support for Ajax, as easy as adding one tag
>Easy component creation, as easy as building a Facelets page
>OO component model maximizes maintainability
>Great support for building internationalized and accessible applications
>“Pay as you go” complexity tax: features you don't need don't get in the way
>Highly secure, with built in protection from cross site scripting, CSRF, and other kinds of attacks
>Java EE standard guarantees the safety of your IT investment
>Comes with every Application Server, giving you a large pool of developer talent, training, and books in
many languages.


Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. Phone 1-650-960-1300 or 1-800-555-9SUN Web sun.com
©2009 Sun Microsystems, Inc. All rights reserved. Sun, Sun Microsystems, the Sun logo, Java, Glassfish, JavaOne, and NetBeans are trademarks or
Registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All other terms are the property of their respective trademark owners.
Information subject to change without notice.

http://javaserverfaces.java.net/presentations/20090520-jsf2-datasheet.pdf

Thursday, January 12, 2012

What is the difference between JSF, Servlet and JSP?

JSP (JavaServer Pages)

JSP is a Java view technology running on the server machine which allows you to write template text in (the client side languages like HTML, CSS, JavaScript and so on). JSP supports the so-called taglibs which are backed by pieces of Java code with which you can control the page flow and/or output dynamically (programmatically). A well known taglib is JSTL. JSP also supports Expression Language which can be used to access backend data (actually, the attributes which are available in page, request, session and application scopes), mostly in combination with taglibs.
When a JSP is requested for the first time or when the webapp starts up, the servlet container will compile it into a class extending HttpServlet and use it during the webapp's lifetime. You can find the generated source code in the server's work directory. In for example Tomcat, it's the /work directory. On a JSP request, the servletcontainer will execute the compiled JSP class and send the generated output (usually just HTML/CSS/JS) through the webserver over network to the client side which in turn displays it in the webbrowser.

Servlets

Servlet is an Java application programming interface (API) running on the server machine which can intercept on the requests made by the client and can generate/send a response accordingly. A well known example is the HttpServlet which provides methods to hook on HTTP requests using the popular HTTP methods such as GET and POST. You can configure HttpServlets to listen on a certain HTTP URL pattern, which is configureable in web.xml, or more recently with Java EE 6, with @WebServlet annotation.
When a Servlet is requested for the first time or when the webapp starts up, the servlet container will create an instance of it and keep it in memory during webapp's lifetime. The same instance will be reused for every incoming request whose URL matches the servlet's URL pattern. You can access the request data by HttpServletRequest and handle the response by HttpServletResponse. Both objects are available as method arguments inside any of the overridden methods of HttpServlet, such as doGet() and doPost().

JSF (JavaServer Faces)

JSF is a component based MVC framework which is built on top of the Servlet API and provides components in flavor of taglibs which can be used in JSP or any other Java based view technology such as Facelets. Facelets is much more suited to JSF than JSP. It namely provides great templating capabilities such as composite components, while JSP basically only offers the for templating, so that you're forced to create custom components with raw Java code (which is a bit opaque and a lot of tedious work in JSF) when you want to replace a repeated group of components by a single component. If you can, I recommend to drop JSP and go for Facelets when you want to develop with JSF.
As being a MVC (Model-View-Controller) framework, JSF provides the FacesServlet as the sole request-response Controller. It takes all the standard and tedious HTTP request/response work from your hands, such as gathering user input, validating/converting them, putting them in model objects, invoking actions and rendering the response. This way you end up with basically a JSP or Facelets (XHTML) page for View and a Javabean class as Model. The JSF components are been used to bind the view with the model (such as your ASP.NET web control does) and the FacesServlet uses the JSF component tree to do all the work.

http://stackoverflow.com/questions/2095397/what-is-the-difference-between-jsf-servlet-and-jsp