Archive for the ‘primefaces’ Category

Edit: online demo added. See link near the end

Up to now, there was no real need for me to use a treetable in my apps. Therefore there has been little interest from me in the PrimeFaces treetable that provides this functionality. So when the need arose, I had a look and it honestly provided way to little functionality for what I need: The treetable is much closer to a tree than the datatable. The fact that more people would like to have a treetable that more closly resembles a datatable is reflected by the issues reported…

Personally, I even have some more requests: sorting, paging, filtering, so the list will become quite extensive if I would report them all.
When you have look at the usage of both components, you already see a big difference. The most common and flexible use of a datatable is in combination with a LazyDataTableModel. This kind of usage of a model is quite different than the TreeNode construction that is required in the treetable (and tree). Then it struck me, if you take a look from the other side, I would have to report only one feature request:

Have the datatable support tree like functionality

Unfortunataly, I needed it kind of quickly, so reporting it and waiting for it to be implemented is… well…  not realy an option and since the use is for a personal project, so going PrimeFaces PRO isn’t realy an option either. Fortunately, the source is open, so I had a look if it could explain the huge difference between a treetable and a datatable. The ‘outside’ usage is ofcourse a reflection of how the components internally work and the treetable is in that way very close to the tree. Luckily we are in the ‘holiday season’ so there was some free time available to start investigating how PrimeFaces components currently are created, work etc… And the be honest, the internals are clearly written, very logical and easy to understand (if you know some basics about jsf components, ajax, events, jquery etc). Since I already made a patch once (against a previous version without the new WidgetBuilder) to give the scrollable datatable an auto height (#3608) So it was then that I decided to try to implement the tree functionality myself…
And after some interesting hours, I was pleased to see it working… I call the result ‘TreeDataTable’. It shares about 98% of the current datatable (maybe more). In fact, it is backwards compatible!!!
Autoheight and tree functionality

Autoheight and tree functionality

This is the treeDataTable in a full page layout where the header is in the ‘north’ layout-section and the treeDataTable occupies 100% of the width AND height of the center section. You can even see the ‘background’ of the datatable filled with empty non-selectable rows if the number of records is lower than the avaliable visible row space. And yes there still needs to be some work done on the odd-even row coloring when collapsing rows (fully expanded it is ok). (fixed, just not updated the image)

And here you see the tree functionality at work and a scrollbar appearing AND the colum headers fitting perfectly.

Expanded some rows, so scrollbar appears...

Expanded some rows, so scrollbar appears…

Expanding is currently done client-side, has no event and the implementation still requires to have the full tree for this page available. But this is not different than with the current TreeTable and  for me this is sufficient.

The empty message works to…

An empty message after severside filtering

An empty message after severside filtering

Showing it is not ‘optimal’ imo and I probably want to display it in the middle of the datatable as an overlay, but that would mean using less of the existing datatable, but maybe some jquery might come to the rescue here.

Filtering works in the way it is done in the current datatable.

Filtering at the 'top level'

Filtering at the ‘top level’

In this example you only see that only top level records that match the filter are shown, but if you want this to be different, just implement it differently in your load method in the TreeTableDataModel (This extends the LazyDataTableModel with one method to get to the children of a node). You could e.g. choose to show matched records and it’s children, or even go ‘up the tree’ to find the ancestor of a matched record that is a top level record. It is totally up to you.

Ofcourse sorting works as well (even multi sorting)



In addition to all of the above, it also does (personally tested)

  • Draggable columns
  • Resizable columns
  • Dynamic columns
  • Conditional coloring
  • Row editing
  • Single/multiple selection (row and/or checkbox/radiobutton based)
  • Headers, footers
  • Context Menu

What is not tested yet (simply because I do not need it) is:

  • Grouping
  • SubTable
  • Summary Row
  • Expandable Rows
  • Cell Editing
  • Lazy Loading
So where can you get this? Well, nowhere yet. It still needs some tuning and testing and making it into a jar that can be used in a JSF application etc… That will probably happen in the first week of next year, so stay tuned (Yes Mr DJ, you’ll get an ‘internal’ release

But an online demo is available…

And believe me, I have next to no knowledge about all the phases in JSF. So even then it is doable for someone with basic java, html, css and some jquery knowledge (most of which I learned doing this and found things on google) to enhance a fairly complex component.

It is currently almost impossible to not like JEE6. CDI, JSF2, JPA2, Servlet3.0, Bean Validation 1.0 and what not But what then… The default JSF components give you limited functionality, so the quest for selecting an enhanced component suite comes to everybody’s path.

Long, long time ago, in the JSF1.0 era, I just myfaces components, they provided a little more, but not much. Then came the Richfaces with Ajax4JSF. I started using this when Richfaces went from being commercial at Exadel to being part of JBoss. I was fairly pleased for a while but when JSF2 came around, I just wanted to have a component suite that worked with it natively.

My shortlist contained 3: Richfaces 4, Primefaces 2/3 and Icefaces 2. The reason I left OpenFaces out at that time was (I think) because I dislike companies opensourcing their whatever they have because they fail to succeed commercially. Ok, Richfaces was commercial to, once, so I begin to doubt my own arguments a little. It might be because I have a ‘warm feeling’ for JBoss (to a certain extend).

Icefaces fell of the list when I noticed their ‘commercial’ touch, having only a few JSF2 components in the open. Mind you, I have nothing against commercial companies, but using JSF mainly for my personal projects, I did not have the money to buy their enhanced components. The Richfaces project took a long, long time to produces something that was usable, could be demonstrated etc. Now I know they developed a new ‘component development kit’, started all from scratch wanted to deliver high quality components, but I just could not wait.

So Primefaces remained, I started using it at version 2.1 and was fairly pleased. A nice set of components that are easily themable since they use the jquery-ui conventions. This means that with JqueryThemeRoller you can create your own themen within minutes. But as always, the devil is the details. Details here meaning developing more complex applications. For me one of the most important components is the datatable. It should have sufficient functionality to begin with, a clear outlook of what additional functionality will come and when, not to many issues etc…

For the Primefaces datatable there are many feature requests. Some duplicates, some not triaged (invalid in the meantime), some nice to haves, and some must haves. Fixed columns and horizontal scroll is for me a nice to have, but having a multi-select like in file browsers is (almost) a must.

Cagatay validly pointed out that the PF datetable is the most complex component with many features already (for the details see below in his reply) so there was already a lot of time and effort put into it. I should have mentioned that.

So instead of complaining, like some others do, I started implementing this myself. Contratry to what people think, developing JSF2 components is not that hard, and most of the things (all in case of the multi select) had *nothing* to do with JSF, but were merely html/jquery things. So what now…

Well, as you can see in the next post in the same topic by the Primefaces lead, they have a policy that issues that are most often voted for get a higher priority then others, but requests by paying customers have an even higher priority. Now this is not strange, since Primefaces is not backed by a company like JBoss or Oracle and since they are human, they do need to eat and drink and go on holiday now and then. So a vibrant community around Primefaces is a great thing to have.

Every now and then they post a tweet about the number of posts that were reached in the forum. Honestly, this can be interpreted as negative as well. If a huge number of posts is required in the forum, It might be that things are not (always) that obvious or bug free. Both are the case, but posters often forget to search the forum or issue list and just post and so you cannot draw a real conclusion from the number of posts. Yes there are many users, yes there are people that help others, a lot, blog about it etc, but that does not constitute a community.

It is obvious that the Primefaces teammembers to a lot of work in their free time as well, so all the work is very much appreciated, but as mentioned, in my opinion, Primefaces does not realy have a community. I can accept that Prime Technolgy wants to stay in control of the direction Primefaces is going and there is no need for an Apache PMC like ‘environment’ now.

But there are some people that do not get a warm feeling on how things are currently going or at least how they are perceived. So, and this is going to be a bold and not realy well founded statement  but jsut to cause ripples/controversy, I get the impression that the Primefaces team rather waits for a paying customer to come by then to accept patches from the community. It might be wrong, they might jsut be scared of copyright infringement, but that can be solved by a contributors agreement. Heck I do not even want/need commit rights (Git instead of SVN might help here)

Don’t get me wrong ,I do like Primefaces and will continue using it,  but at the same time I do not want to ‘fork’ certain components just to speed up fixings issues, enhancing things  or even introducing new components. I want Primefaces itself get to a higher level and want to HELP