Introducing PrimeUI

We are excited to announce a new spin-off project project called PrimeUI from PrimeFaces Team. PrimeUI is a set of javascript widgets to create rich UIs easily. So basically we’re decoupling the homegrown widgets in PrimeFaces from JSF and creating a pure javascript library to make our widgets available to any framework like php, asp, wicket, gwt,, jax-rs and more. These widgets are implemented with plain jQuery, designed to work with JSON for data progressing and use client side progressive enhancement to render UIs. PrimeUI would be using jQuery UI WidgetFactory APIs to provide the widgets as jQuery Plugins. Code will be open source with Apache License same as PrimeFaces.

Here is a sample inputtextarea widget, to see the PrimeFaces component version see here.

<textarea id="basic" rows="5" cols="30"></textarea>

<textarea id="resize" rows="5" cols="30"></textarea>

Maxlength with Remaining Chars
<textarea id="counter" rows="5" cols="30"></textarea>
<span id="display"></span>

<textarea id="ac" rows="5" cols="30"></textarea>
       <script type="text/javascript">
            $(function() {


                $('#counter').inputtextarea({counter:'display', counterTemplate:'{0} characters remaining.', maxlength:10});

                        ,completeSource:function(request, response) {
                                type: "GET",
                                url: '../autocomplete',
                                data: {query: request.query},
                                dataType: "json",
                                context: this,
                                success: function(data) {
                          , data);

completeSource is a function that expects json response(data) with an array of label-value options so server side can be any technology like JAX-RS or php.

And here is an example with TabView and the PrimeFaces version;

        <div id="default">
                <li><a href="#tab1">Tab 1</a></li>
                <li><a href="#tab2">Tab 2</a></li>
                <li><a href="#tab3">Tab 3</a></li>
                <div id="tab1">
                    Content 1
                <div id="tab2">
                    Content 2
                <div id="tab3">
                    Content 3
$('#default').tabview({orientation: 'left'});

We plan to make an initial release with at least 5 widgets by the end of november, overall planned widgets for PrimeUI are;

- InputText
- InputTextarea
- SelectOneMenu
- RadioButton
- Checkbox
- CheckboxMenu
- Rating
- Spinner
- AutoComplete
- TabView
- AccordionPanel
- DataTable
- DataList
- DataGrid
- Paginator
- Tree
- TreeTable
- MindMap
- Button
- ToggleButtons
- Menu
- Menubar
- TieredMenu
- ContextMenu
- SlideMenu
- Breadcrumb
- Growl
- Fieldset
- Panel
- Toolbar
- Dialog
- OverlayPanel
- ProgressBar
- Inplace
- Tooltip
- Carousel
- TagCloud
- PickList
- OrderList
- …more

So we plan to provide a PrimeUI widget for all the homegrown widgets we have in PrimeFaces and make them available for any technology.

Teaser Video

Keep an eye on this blog for more exciting news from the PrimeFaces Team. While you are reading this, we are also working on PrimeFaces 3.5, 3.4.2 and Mobile 1.0.

18 thoughts on “Introducing PrimeUI

  1. Interesting blog post, and definitely a way to grow PrimeFaces’s user base. If the decision is made in favor of PrimeFaces being dependent on PrimeUI, I wonder if this will impact PrimeFaces Extensions. I assume it will.

    • This is not a problem for PF Extensions. The most widgets, third-party and ours own, are already jQuery plugins. Maybe some day we will port them all in the same manner to Prime Extensions UI. I don’t know, this is not a main focus for us at the moment because we are all JSF developers and don’t need to use widgets in ASP, PHP, JAX-RS, … But of course, a new spin-off product is a good decition. From our point of view there are even more reasonable spin-off products for PrimeFaces. We would like to see e.g. two JAR files: one with most used components like button, datatable, … and another one with rare used like captcha, mind-map, … The most time we don’t need all widgets, only most used. This would reduce the size of primefaces.js and primefaces.css and leads to less resource loading time. I can imagine e.g. primefaces-core.js and primefaces-advanced.js. PrimeFaces is growing and having one big file is not efficient according to studies because 3-4 small files are loaded faster parallel. We follow this concept in PF Extensions. But it’s a different topic from this blog post…

      Thanks for your effort PrimeFaces team and keep up your good job!

      • Yeah, PFExt don’t need this own PFExt UI right now.And separating as two different jars (one for commonly used and one for advanced components) will be good in performance point of view.But Mojarra JSF itself having single jar for all components and it won’t sounds good for user cofiguration also. The definition of Primefaces will change with this idea …….:)

        “PrimeFaces is a lightweight library with one jar, zero-configuration and no required dependencies. You just need to download PrimeFaces, add the primefaces-{version}.jar to your classpath and import the namespace to get started”

        • But it will be still valid in most cases. Most time you will use the JAR with common used components. PrimeFaces is growing and only one JAR will grow continuous. In PF Ext. we have moved e.g. big resources (many KBs) for CKEditor and CodeMirror to separate JARs. No needs to pollute core JAR with additional resources. Right?

          • +1000 Agreed, Oleg.
            Most of the users(almost 80-90%) will use the commonly used components only and it need to be categorized properly between these two sections(based on PF Users components usage).

            Experience JSF developers understood the advantage of this idea but JSF or PF newbies may think like they need more jars and configuration. Ofcourse ,it is rare case.

            I will vote for your good suggestion…..:)

  2. Yes very interesting. Sometimes I just want some design components similar to the primefaces widgets without any jsf interaction at all and have to “redo” it in html with the appropriate classes.

    I think from a programmer point of view you should make primefaces dependant on primeui, since this will reduce programming time. And ui changes in base primeui will directly be reflected in the primefaces version.
    Even if at some points it maybe is not the best idea performance wise.

    With so many widgets it will get very time consuming and demotivating making changes and writing almost duplicate code.

  3. As long it is transparent and that it will not break my existing facelets code. Also if we upgrade to later version, significant amount of regression testing will be required.

  4. It would be great to see Primefaces and PrimeUI move forward together, no fork, the rationale being that neither code base would get left behind.

    This is a very exciting development as while we are developing new products with Primefaces and we can re-skin some of our older products with Prime UI without the need to upgrade the back end.

    Well done to the Primefaces team. Keep up the good work.

    • We’ve done a lot of POC work and trying to make JSF optimized widgets generic introduced many boilerplate code that is obsolete in PrimeFaces so decided make a port instead which is much more cleaner. They will be developed in parallel for sure.

  5. We use Backbase and bought into their JSF framework about 5-6 years ago. They also have split a Client UI and have now discontinued support for their JSF framework. This has put us in a difficult position as we have to mostly support ourselves and getting any help from Backbase is difficult or not as rewarding as we would hope. The decision for PrimeFaces to go the UI route makes a lot of sense, providing that both the JSF and the UI customers are supported. This split makes me a little nervous as I wonder if this is the start of the discontinuation of the JSF framework. I sincerely hope it is not!

    • No worries at all, PrimeFaces is our precious and will always have our main focus. Other modules are spin-offs. So our main work will always be PrimeFaces.

      • PrimeFaces Rocks! I’m glad to hear this, too! As Helge said in comment below, JSF/PrimeFaces is soooo much fun to me! I’ve seen Oleg and others say the same!

        We just passed the Halloween season, while there may be many JSF frameworks out there that turn out to be ‘tricks’ to their users, PrimeFaces is such a ‘treat’ to me and all those that ‘love’, lean, and depend on PrimeFaces (JSF)!!!

        Live on, PrimeFaces! :)

  6. Promising!!
    I’ve been working with Primefaces/JSF for a while now and its great fun, but for a couple of projects I need to use a HTML5/angularJS solution. And by adding PF to the mix, the future’s so bright…. I gotta wear shades :-)

    Absolutely brilliant!

  7. I recently switched from JSF2 + Primefaces to Thymeleaf + Twitter Bootstrap + jQuery due to heart not signing in with JSF2 and its complexities. I look forward to PrimeUI and thanks for the liberal license.

  8. Excellent!!!
    JSF Primefaces is a wonderful framework but I like the idea to have a full client Side Web application with a stateless server for certain type of applications.

    Do you plan to create a javascript MVC framework like sencha ExtJS??