Java Purefaces
Upcoming SlideShare
Loading in...5

Java Purefaces






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Introduction slide 1 of 2: I’m Matt Pickell and this is Ariel Raz. We work at B6 Systems, which is a Pittsburgh-based company that specializes in the development of custom software solutions, such as enterprise and web applications. We have developed a new JSF extension that we call java purefaces for developing the UI in java without the use of static JSP/XML files. This is not a framework . It is a very light addition to any JSF project that simply allows the developer to use swing-like Java programming to create UI instead of having to maintain many different XML and JSP static configuration files. As we have already done in-house at B6, you can use this for creating entire projects, or you can add it to existing projects very easily. We have found that this extension for creating JSF applications has made us very effective and able to develop custom software very quickly. Because we think it is so useful we have decided to make it open source (available at our site) and present it here to get more opinions on it. (Switch to next slide to show major presentation sections – text comes up automatically )
  • Introduction slide 2 of 2: So, what we are going to talk about is generally this: First, Ariel is going to quickly review Web Development topics and JSF to make sure that everyone here is on the same page for the rest of the discussion. Next, we will move into purefaces itself and discuss what it is, what you can do with it, and some of the advantages we see in using it. If there is time, we’ll take a closer look at some of the things that make purefaces work. We’ll take a look under the hood. Finally, we want to take questions and get opinions from you. So, please look at this with an open mind. As we present Java PureFaces, think about the methods you currently use, and consider how pureFaces would affect your development. We have seen a lot of interest and potential for an extension like this while looking through JSF forums and really value your opinions on how we can make purefaces even better. So, Ariel will now walk you through … Feel free to ask questions at any time. We would also like to have a discussion afterwards.
  • Web Development 1 ( of 3) I will start by describing how I see the web framework evaluation in the java world. In the beginning there was static web content, all the page content was written in html and retrieved by the browsers. HTML pages are usually created with a WYSIWYG HTML editor. The next step was web application with dynamic content where the pages are created on the fly. This was done by having a web container that uses java’s servlets and JSP API
  • Web Development 2 ( of 3) Developing web application with JSP pages was not very productive as it required a lot of code writing on the JSP page and on the server side, a lot of copy paste practice and it was hard for maintenance. The reason for that, as I see it, is because JSP is not a programming language. In a programming language you can efficiently perform : Code reuse Loops Conditions statements You can do it in JSP but it is much more time consuming and hard to test and maintain . To solve that problem many new web frameworks were created. Examples are Struts, Tapestry, WebObjects, Spring MVC, JSF, Wicket, GWT, etc. Those tools where trying to simplify : Writing condition statement Hooks to the server tier (method and attributes) Loops Code reuse Error handling, validation, conversion, navigation, i18n, Struts, Spring MVC and JSF did that by providing better tags to be used from the JSP page and better hooks to attributes and methods on the server side. Those frameworks use JSP/XML templates to design the UI. With those frameworks came JSP/XML editors for designing the pages but as the page content is more dynamic and have more logic in it, it is really hard to know how the page will look until you deploy it and look at it with a browser . On the other hand Wicket and GWT are providing an API to create all the page content in java, which already have the capabilities of code reuse, loops, conditions and the power of an object oriented language . I think that is the way to go when developing dynamic page content because HTML was intended for the browser -- not for the developer. Developers have java. Java is a great programming language much better then JSP, XML. It’s Object oriented, very powerful and has many libraries and great development tools.
  • Web Development 3 ( of 3) We work with JSF specifically, and that is what purefaces is based on. So I want to end the web framework review with a comparison graph of java web frameworks from
  • JSF Review 1 ( of 4) Now let’s take a quick look at the features of JSF. JSF is a web framework developed by Sun’s and is part of the j2ee spec, it is very popular. In JSF you develop the UI with JSP/XML files using JSF tags and bind the JSP/XML to java objects. The idea behind JSF is that the JSP/XML will be developed by UI developers and the java classes by application developers . The UI developers will be using JSP/XML editors for writing the pages. Some of JSF features are: Backing beans , java objects that are used for binding attributes and methods to the JSP/XML page, all of the backing beans need to be defined in the JSF configuration file. The connection from the bean to the JSP page is created using a binding, and the format is a JSF expression language string like : #{}, which will return the city name from the address object. The binding must be spelled correct or the page will fail to load (i.e., you must use java naming conventions so reflection can work). Navigation rules , In the JSF configuration files navigation rules are defined statically, they define what will be the next page to view after a page submit Like many other frameworks JSF has support for Input Conversion, validation and error handling.
  • JSF Review 2 ( of 4) – HIGHLY animated slide. Need to view this slide as presentation. JSF consists of a lot of pieces to make up the final view. Much of it is static. Show an example from the guessing number I will show how the jsp file looks like( binding, jsf tags) I will show how the backing bean looks like, setters, getters and methods. I will show how the configuration file defining the backing beans and navigations rules.
  • JSF Review 3 ( of 4) Transition slide to finalize previous messy slide.
  • JSF Review 4 ( of 4) In big project you get many JSP/XML files to maintain and a lot of static configuration. JSF also provides a java api to create the UI Components. These components are used by JSF tags but can also be used directly, for example: That tag is binding a UI component to a view, the “root” backing bean “getRender()” method return a HtmlPanelGroup that will be rendered in to HTML code .
  • PureFaces – What is it? (1 of 8) Like I said earlier purefaces is an extension of JSF, we are using standard JSF and richfaces components to create purefaces classes that can be easily use to create the entire UI from java. All The development is done by using java, css and JavaScript’s. We use only a single JSP page for binding, and a single bean for that JSP page. There is a single entry for navigation because there is only one jsp page. Purefaces can be added to an existing jsf application, you just need to declare a purefaces backing bean in the configuration file and bind it to the JSP page. Like this: Because all the code is in java it can be testing with junit . It supports AJAX through the RichFaces framework. We tried to make the API easy to use as possible . So, for example, to create an output text you will do: new PureOutput("Hello World")
  • PureFaces – vs JSF (2 of 8) Now I will show a comparison between an application created with JSF compare to one created in purefaces. This demo is the guessNumber application again, but this time implemented using PureFaces. I will show the separation of the view and the domain object I will show how the UI is created I will show how the methods are binded Source code for this example is available at :
  • PureFaces – component demonstration (3 of 8) I will now show a simple application that demonstrates some of the purefaces components and how to create them with java code. The demo is available on our web site for trying out the component and also for download, to run it you only need unzip the file and run: mvn tomcat:run DEMO Using the component demo on line : Demo app construction: The demo adds a left navigation menu for the different components. When you select a component we are using ajax so only the right part of the page changes. Show the input component I have here two types of inputs: a string bound to a PureEditableValue, and an integer bound to an object by defining the attribute name. With purefaces you can bind to any object you don’t need a backing bean. You just need a setter and a getter for it or to use the PureEditableValue Show the button component With purefaces you bind a Runnable or an object with its method name to a button, when you bind used object methods name you can also pass arguments. Like the input component you can bind to any object, no backing bean Show the panel group component A panel group is a good container for laying out other components, you use the add() method to add any PureComponent. PureComponent is the interface that all purefaces components implemen t. A panel group allows easier CSS design compared to a panel grid. To layout the component in a table structure you can use the panel grid.
  • PureFaces – the PureComponent Interface (4 of 8) Most components in purefaces are pretty much direct wrappers for the components available through JSF. There are many advantages to encapsulating the JSF components. More complicated and repetitive implementations can be made simple by hiding the complexity in the purecomponent and having the developer only need to work with the exposed methods. A simple example of this is components that have associated javascript (like modal panel). The javascript can be written once in the purecomponent and a simple method created for the developer to use. The developer does not need to remember the syntax for these options. Another example is that all ajax can be implemented behind the scenes, and the API to use that Ajax can be made very simple. This simplification through the PureComponent helps to speed up development. What is not simplified through the creation of helper methods is simplified with the availability of java doc in the component PureComponents are designed to be serializable . we store all component properties in a purecomponent class and only build the component when needed. This practice allows us to serialize PureComponents. Now, reloading the web application on the fly is possible without losing our session. Also, custom components can be quickly and easily created and there is no need to build tags or any other configuration for them . These components can then be used in a purecomponent implementation for exposure to the developer. Custom components built from existing PureComponents are easily stored in their own classes. New custom components are also easily created. All purefaces components implement the PureComponent interface they don’t need to extends any object. PureComponent has one method UIComponent createUIComponent(); UIComponent is the class the all JSFcomponent extends from. Some examples of components are: Input components, you add jsf convertor and validator to them Output components Panels components Buttons and links components And more (file upload, file download, jquery…)
  • PureFaces – custom component example (5 of 8) This example is from the SERVER SIDE article: Create a custom component is very easy, you just need to implement PureComponent, because you don’t need to extend any class, any of your class can implement PureComponent and be displayed on the UI.
  • PureFaces – custom component example (6 of 8) This example is from the SERVER SIDE article: Creating custom component with other frameworks is very time consuming and hard to refactor. Think how would you create LabelAndInputComponent with JSF or GWT
  • PureFaces – additional features (7 of 8) Maintenance There is a saying that 80% of development is spent on maintenance , with pure faces we are trying to reduce the cost of maintenance by making the code simple, decoupled, easy to refactor and test. Simple – the api is very straight forward, swing like. Single UI Location – because all the code is in java you don’t have the code that create the UI separated between the jsp file and java class. To make a UI change you just need to change one place the java class. Easy to refactor- it is much easier to refactor java code then JSP/XML code. We have been using eclipse and find changed class structure easy. Test- because all the code is in java you can test it with junit, when creating purefaces components there binding are validated. You can also simulate attributes setting and submitting of pages.
  • PureFaces – additional features (8 of 8) Ajax We are using the richfaces API for AJAX capability, with pure faces you don’t need to write any javaScript code for ajax. When you create a component you define on what javaScript event you what to do an AJAX call and what area in the page you want to update. Show DEMO again Show the Ajax input component from the demo app Most components support ajax updates for UI events Show how PureComponentBinding  define the area to update Show how AjaxInfo is defined CSS & JS Simply stated here, we can write very semantic, CSS friendly code and add in style classes anywhere needed. Java script can be view-specific for additional targeting of hard-to-get-at component features. Set style and style class to components Set javaScripts on events Add pureJQuery components Show jQuery code example in DEMO
  • Under the hood (1 of 3): If we have time… Binding attributes to Any Object We don’t need a backing bean because we are using the JSF ValueChangeListener to bind the attributes. We created a class InputValueBindingChangeListener to set an object attribute. PropertyUtils. setNestedProperty (obj, attribute, changeEvent.getNewValue()); InputValueBindingChangeListener is called by JSF when there is a form submit and the input value had changed. That binding are tested when the object is created for unit testing
  • Under the hood (2 of 3): If we have time… Binding command buttons and link to Any Object In the button and link command we are using the JSF ActionListener, we created a CommandActionListener to execute a Runnable on a Form submit. The CommandActionListener will run() the Runnable if a Runnable was used to create the button OR it will call run() on a MethodCommand which is a Runnable class for execute a method on an Object. MethodCommand is using: runningClass.getDeclaredMethod(methodName, classes).invoke(obj, args); The binding are tested when the object is created for unit testing
  • Under the hood (3 of 3): If we have time… Creating a new UI on an AJAX event In The AJAX case we are adding an ActionListener to richfaces HtmlAjaxSupport We are using AjaxComponentUpdater which is a Runnable to update the jsf tree On the AjaxComponentUpdater run() we create the new UI component UIComponent newContent = pureContainer.createUIComponent(); and then add it to the jsf tree
  • UI Design (1 of 1): TRANSITION TO MATT If Ariel forgets to ask at this point… see if there are any questions on the previous section before moving on. This is a quick overview of how someone (me) actually uses purefaces in daily development. (DEMO COMPONENT IS USED AS EXAMPLE HERE) UI in practice I start out getting the requirements for the view so that the app can be built from it. I start with a picture of what the view should look like. Based on the diagram of the view, I design its behavior. This is standard OO design. I can choose from design patterns or whatever I need. – show component demo, view it as a “picture” and then talk about breaking up the behavior Based on the previous design, I can quickly develop a simple semantic layout of components into methods . I can quickly put together views by having the view as just a part of a class that also handles the code specific to that view (like you might have to do in the bean otherwise). Instead of switching between application, bean, and JSP, I can simply spend my time concentrating and focused on development. I then add styleclasses to the components that will need them. I use jQuery for more difficult element targeting -- show component demo again, talk about the actual implementation and how the structure of the application is, and a little about CSS At this point I have very little that I need to go back into the java code for. I make final tweaks to the CSS using firebug or Web Developer add-ons. If I do need to tweak something in code, I can change it (in debug mode of eclipse) and the app reflects it immediately. No need to reload! Very fast development! Of course, once developed in Firefox I need to go back and make allowances for the different IE versions. OTHER development notes (Some other special cases that might come up during development are customizes application components) Usage of components Inside a specific project, we create standardized custom components like PureButtonStandard that are already set up with styleclasses, images, etc, specific to the project. Just extend the existing component and add any predefined CSS, JS, etc to it. If a design requires a new component that PureFaces doesn’t currently have, we create it then. Tools What tools do I use? Pretty much the same tools any other web developer uses. Eclipse – changes are immediately available w/o reload of app, and CSS syntax is easy to add because of eclipse content assist. Browser tools Firebug Chrome and IE8 have debuggers as well Safari for fast testing. It seems to run very noticeably fast on windows. IETester – there are some sites that test pages with all browsers, but that is not always possible with apps not accessible to the outside world. GIMP for images, but that’s not related to purefaces I’ve looked at sitemesh for future projects, but I am not using it right now
  • Conclusion (1 of 3): Virtually all development in Java Other than the single JSP page and the simple bean that are necessary, all UI development with PureFaces is done in java. All PureFaces Purecomponents are plain old java objects (POJO). Maintain a clean application & stay in flow by not having to switch from java to jsp to whatever… (also, whatever different tools are used for the JSP development). Ie. Be more productive by being able to remain focused. Javascripts and CSS is added directly to the components and can be stored in constants to ensure standardization across an application. Dynamic : Creating views from java code enables the UI to be extremely dynamic. It is easy to create whatever combination of components are needed for virtually unlimited requirements. When you add ajax to this, the application because very fluid without excessive work. (very easy to make a complex app that doesn’t constantly interupt the user -- without implementing a ton of JSP pages) And, of course, the UI implementation can use OO principles since we are in Java. Direct Object Model Access A very powerful aspect of PureFaces is the removal of any restrictions on how the UI can access the application. You can enable any class to handle its own view, and that view is not restricted in any way. It has full access to the application. Simpler Maintenance & faster development Testing through JUNIT quickly enables the developer to test all bindings along with any other parts of the application required to create the view. Methods for buttons or links can be tested from JUNIT as well. Maintain the application better by only having to work within Java to make any corrects. (fix it once, because it is only implemented once in java – not partially in a bean and partially in a JSP) Refactoring is simple – using whatever tool you are already using. Refactoring the application keeps the views up to date as well The PureFaces API is intuitive and the API and API documentation is available in most development environments (like eclipse) automatically via popups. The component names are created in an almost SWING-like fashion. Easy to read UI code . With purefaces, “isRendered” is rarely used, or not needed at all, because instead you just don’t add the component to the view. The code is very easy to read because it is in context when it is viewed. You can immediately see how it interacts with the application. It is all right there in the java code. Ajax-enabled Finally, ajax is built in. By using RichFaces components behind PureFaces we have given the developer a robust implementation of ajax in JSF. With purefaces itself, we have created a simpified API for using ajax.
  • Conclusion (2 of 3): Current status of purefaces / highlights Not all jsf and richfaces component supported yet . We are a small company and continue to create the necessary pureComponents we need on an as-needed basis. And again, to repeat ourselves : PureFaces classes are seralizable, jsf classes are not, so the web application CAN be reloaded Don’t need to create a member for each ui component, like swing and some other frameworks require Can be added to an existing jsf app very easily Unique aspects of PureFaces extension depends on session to store ui – PureFaces is stateful and requires the use of the session to store the UI. State is stored on the server-side and not the client. This may or may not matter to you, but I’ll mention it so you are aware. (The single bean we use is a session-scope managed bean) Doesn’t split dev rules between java developers and ui developers – although many JSF developers tend to also handle the UI/JSP templating themselves anyway. If you REALLY need to divide the roles, an application like sitemesh can be used. We haven’t used it but it would work very well for this purpose
  • Conclusion (3 of 3): Mention : we are available for assistance for anyone who wants to test out the system. MOVE TO Q&A NOW – next slide
  • Conclusion (3 of 3): Mention : we are available for assistance for anyone who wants to test out the system.
  • Kept as backup. This is a slide from a different presentation.

Java Purefaces Java Purefaces Presentation Transcript

  • Pittsburgh Java User Group– Dec 9 2009 Java PureFaces: A JSF Framework Extension
    • Web development and JSF review
    • Java PureFaces - a JSF extension
    • Briefly discuss current state of the project
    • Q&A
    • First, static web content
      • Written in HTML
      • Sent directly to the browser
    • Next, dynamic web content
      • Web containers, Java servlets, JSP
      • HTML is dynamically generated and then sent to browser
    Web Development
    • JSP - Java Server Pages
      • UI code writing in JSP and on the server
      • Difficult to maintain
      • Not a programming language
    • Attempts to solve JSP downfalls – new frameworks
      • Struts, Tapestry, WebObjects, Spring MVC, JSF, Wicket, GWT, etc.
      • Try to solve issues such as error handling, validation, code reuse, etc.
        • Use tags to bind data to the server
      • Wicket and GWT provide Java solutions
    Web Development Java is the way to go.
    • What is it?
      • A server side user interface component framework for Java™ technology-based web applications – wikipedia
      • A specification and reference implementation for a web application development framework containing components, events, validators & converters, navigation, etc. – wikipedia
      • Developed by SUN and part of the J2EE SPEC!
    • Uses static template pages (containing mix of JSF special tags and HTML tags)
    • Uses “backing-bean” on the server side for binding. Ex: #{}
    • Navigation & backing-beans are defined in static files
    Quick JSF Overview
  • What JSF looks like.. JSP Page Backing Bean faces-config.xml
  • It can get very big quickly. (Each thing needs to be set up for each view) You can see the JSF GuessNumber demo here
  • But… JSF supports UI Component creation through Java. Ex: <h:panelGroup binding=&quot;#{root.render}&quot;></h:panelGroup>
    • An extension of JSF.
      • Uses standard JSF and RichFaces to create PureFaces components
    • All UI development is in Java
      • CSS and JavaScript are easy to plug-in
    • Can be added to an existing application
      • Add a purefaces bean in the configuration file and easily bind into existing pages using :
      • <h:panelGroup binding=&quot;#{root.render}&quot;></h:panelGroup>
    • Simple API.
      • new PureOutput( “Hello World” );
    What is Java PureFaces?
  • Java PureFaces vs. JSF Very simple. … and the JSP page and simple bean only need to be defined once at the beginning of the project. Source code available at
  • Java Purefaces components PureFaces online component demo The demo source is available at To run it locally, unzip it and run “ mvn tomcat:run” . Get maven here
    • Direct wrappers of existing JSF components
    • Encapsulation of the JSF components has advantages:
      • Simplifies the API for the developer
      • PureComponents are serializable
    • Creating Custom components is simplified
      • Components can quickly be created in PureFaces – no tags or configuration
      • Application-specific components are POJO
    PureComponents To create a component or whole view, just implement PureComponent
  • Custom components public class LabelAndInputComponent<E> implements PureComponent {     private String label;             private PureEditableValue<E> editableValue;             public LabelAndInputComponent(String label, E value) {                     this.label = label;                     this.editableValue = new PureEditableValue<E>(value);             }             public PureComponent createUIComponent() {                     PurePanelGrid grid= new PurePanelGrid(2);                     grid.add(new PureOutput(label).setStyleClass(&quot;labelStyleClass&quot;));                     grid.add(new PureInput(editableValue).setStyleClass(&quot;inputStyleClass&quot;));                     return grid;             }             public E getValue(){                     return editableValue.getValue();             }     }
  • Custom components       private LabelAndInputComponent<String> field =           new LabelAndInputComponent<String>(&quot;A Label&quot;, &quot;default text&quot;); // example       /** Create a DIV element that contains a label component */       public PureComponent createUIComponent() {             PureDiv div = new PureDiv();                     div.setStyleClass(&quot;divStyleClass&quot;);                     div.add(field);           return div;       } // ex: get the value from the field now using field.getValue(); Source code from PureFaces article on The Server Side
    • Simplified with maintenance in mind: 80% of your cost
      • Simple : Straightforward SWING-like API (without having to have a member for each UI component)
      • Single UI Location : Changing the UI can be done in one place. There is no need to keep a JSP page in-sync with its bean.
      • Easy refactoring : Everything is in Java. Use of existing, robust refactoring tools makes it easy.
      • Testing : All bindings can be tested by creating the component or view in a simple JUNIT test.
    Java PureFaces features
    • Ajax-enabled
      • Built-in by using RichFace
      • PureFaces API includes methods for adding Ajax
    • CSS & JavaScript
      • PureFaces makes it easy to use semantic HTML and add CSS / JS
      • RichFaces jQuery component makes it easy to target complex JSF component elements by adding scripts only where necessary (no additional JS files to load).
    Java PureFaces features PureFaces Demo Link
    • Binding attributes to any object
      • Get around using backing beans by using the JSF ValueChangeListener to go back into the application and set up values when the form is submitted
      • We created a class called InputValueChangeListener to set these values like this:
    • PropertyUtils. setNestedProperty (obj, attribute, changeEvent.getNewValue());
      • Bindings are tested when the object is created, so they can be tested with JUNIT
    Under the hood... PureFaces Demo Link
    • Binding buttons and links to any objects
      • Get around backing beans by using JSF ActionListeners
      • We created an ActionListener called CommandActionListener to execute Runnable s, and a Runnable named MethodCommand to execute a method in an object. MethodCommand does this using reflection:
    • runningClass.getDeclaredMethod(methodName, classes).invoke(obj, args);
      • Bindings are tested when the object is created, so they can be tested with JUNIT
    Under the hood... PureFaces Demo Link
    • Creating a new UI on Ajax event
      • We add an ActionListener to the RichFaces AjaxSupport component.
      • We then use a Runnable to update the JSF component tree with whatever is configured to be updated on a specific ajax-event.
    Under the hood... PureFaces Demo Link
    • UI with Java PureFaces in practice
      • Start with the interface requirements
      • Design the behavior of the implementation ( standard OO design )
      • Break up the view per the application design
      • Create any new components or custom application components
      • Add basic CSS, and jQuery to target HTML only accessible after HTML is created
      • Use firebug in FireFox to tweak and get the final CSS, & test in all browsers (and most likely fix some IE compatibility issues)
    • Tools
      • Eclipse : for just about everything. In debug mode, changes are immediately available without reloading app
      • Browser tools : firebug in FireFox, developer tools in IE8 and Chrome. IETester for previous versions of IE. Also, Web Developer in FireFox has some nice features
      • AjaxLog : component included in RichFaces to help debug any ajax interactions not working as expected
    UI design
    • Virtually all development is in Java
      • There is a single JSP page and a simple bean to connect it to the application
      • All PureComponents are POJO.
    • Extremely dynamic
      • Views are created directly from the application and can easily be redefined on the fly (ex: panelGrid demo)
    • Direct object-model access
      • No need to worry about what is accessible only through the bean
    • Simpler maintenance, Faster development
      • Views can be tested through JUnit.
      • Everything can be done using Java tools (refactoring, etc.)
      • Simpler, documented API
    • Ajax- enabled
    To summarize...
    • Component development
      • Need to implement more components. Built on as-needed basis
    • Depends on Session to store the UI
    • Combines aspects of UI Development with Java Developer role
      • many JSF developers handle both
    Current state
    • We are trying to raise awareness in the community so that:
      • We can get outside opinions and suggestions
      • Others can help expand and grow the framework extension.
    • There is more information available:
      • Source code at
      • Demo available at
    What’s next?
    • Want more information? Email [email_address]
    • XML was not designed to be edited by humans… and we don’t like editing HTML or JSP (JavaServer Pages) either.
    • We wanted something more dynamic for web application development!
    • Web applications using JSP pages can quickly become huge and difficult to maintain.
    • We have such nice tools for developing Java already.
    Java PureFaces – why?