Salient Soft

Blog Archives

November 23rd, 2010

11:38 am

Using floats to place a border around a control group/toolbar

Posted under CSS Permalink
Tags CSS, Gestalt, HTML, inline-block, Primefaces, Tip, Tutorial, UIDesign

I originally used display:inline-block, line-height and vertical-align:middle to do this as detailed here, but the results were inconsistent across browsers.

Using floats is a much better solution for a number of reasons – details are as follows:-

The controls are floated left inside a div which is itself floated left. As the div is floating, it auto resizes to fit around the content, and so scales to fit unknown control sizes.
The controls are all set to have fixed top and bottom margins (4px in the example), and the leftmost and rightmost also have similar left and right margins respectively.
The floated div is set to have the desired border and background etc. – in my case, I use Primefaces/jQuery UI theme style classes to apply theme look and feel.
The floated div is then placed inside another outer div, which may be of fixed dimensions. This allows the control group to adjust in size, but to be located inside a fixed area on a page.
If the outer div is of fixed size and non floating, the floating inside it is invisible to the rest of the document, so it is not necessary for example to clear the float.
If desired, the outer div can be set to overflow:auto to allow scroll bars if the size of the inner floating div exceeds the space allocated for it on the page.
If the area surrounding the control group is also floating, the outer div can also be set to float with no size specified, so the concept works well in both floating and fixed size situations.
display:inline-block and vertical-align:middle are not used with this method.

This mechanism has the following characteristics:-

The control group bordering works nicely and consistently with the Primefaces/jQuery theme styling, as rather than trying to centre the controls in a fixed border, instead we vary the border size and keep the margin between the controls and the border constant.
The approach makes use of the laws of Gestalt Psychology – the eye notices even small imperfections in the alignment of the controls and their relationship to the border because they are close and obviously grouped/related.
Conversely the position of the entire bordered control group within its surroundings (the outer div) will typically not be so critical – it will likely be in a larger area of white space between it and adjacent items, and so its position and size within that space matters less than the control / border relationship.

A caveat to all this is that it is still not perfect – the simple example below does not perform quite as well in terms of cross browser alignment as the Primefaces/jQuery UI version, as the Primefaces themes apply their own styling as well which changes the situation. This could of course be improved by adjusting the margins individually for different controls in the group to get the best overall cross browser alignment. One very important goal I am trying to acheive is to avoid browser specific CSS. The Primefaces/jQuery UI CSS does in general have browser specific tweaks which will help it in certain situations.

Overall though this approach performs significantly better than the previous method using vertical-align:middle etc. and has the advantage of being fully floating/dynamically sizing if required. An example of this approach follows :-

<!DOCTYPE html>
<html>
<head>
<style type=”text/css”>
  .ss-outerdiv {
   height: 40px;
   width: 200px;
   background-color: orange;
  }
  .ss-controlgroup {
   float: left;
   background-color: green;
   border: 1px solid black;
  }
  .ss-select, .ss-leftbutton, .ss-rightbutton {
   margin-top: 4px;
   margin-bottom: 4px;
   float: left;
  }
  .ss-select {
   width: 120px;
     font-family: Arial,Verdana,sans-serif;
     font-size: 11px;
   margin-left: 4px;
   margin-right: 4px;
  }
  .ss-leftbutton, .ss-rightbutton {
   height: 20px;
   width: 30px;
  }
  .ss-leftbutton {margin-right: 2px;}
  .ss-rightbutton {margin-right: 4px;}
</style>
</head>
<body>
<div class=”ss-outerdiv”>
<div class=”ss-controlgroup”>
  <select class=”ss-select”>
  <option value=”Test”>Test Value</option>
  </select>
  <button class=”ss-leftbutton ss-button”></button>
  <button class=”ss-rightbutton ss-button”></button>
</div>
</div>
</body>
</html>

No Comments »

November 16th, 2010

2:59 pm

JSF 2.0 Composite Components

Posted under JSF Permalink
Tags CSS, Facelets, HTML, JSF, Primefaces, Tip, Tutorial

This post highlights a few lessons learned whilst experimenting with a simple composite component, in this case an experimental Primefaces theme switcher component. The component does the following:-

Automatically iterates the themes directory on the server to build a list of available themes which are presented for the user to select
Generates a simple theme control panel with a border, consisting of a drop down combo listing the themes, with previous theme/next theme buttons to the right.
Also allows theme switching via ctrl/shift/left arrow and ctrl/shift/right arrow, to give a quick way of cycling through the themes when choosing one.
The component is used on the JSF page in two modes – the first usage is with outputStyle=”true”, themeBase and defaultTheme attributes. It is placed in the <head> section, and it defines the base path for all the theme directories, and the default starting theme (which may be programmatically overriden by setting the theme property in its backing bean, themeSwitcherBean). This mode also outputs the link directive to link the current theme stylesheet to the page. It does not result in the display of the control panel.
The second mode is used inside a <form> on the page, and results in the theme switcher panel being displayed.
A theme switch results in a form submission, so this must be acceptable to the form logic. If not, i.e. if the form is dirty, the theme switcher must be disabled. This would be done by passing a disable flag attribute to the component, which maps to a disable property of the backing bean, which results in enabling/disabling the controls. At present, a disable feature is not supported.

The following salient points were picked up along the way:-

The component does not have to be placed in a form. The examples in the Core JavaServer Faces book seemed to always show the client page with the control placed on a form, and also with <form></form> tags present in the custom component implementation. There is absolutely no requirement for the custom component implementation definition to be in its own form.
With JSF 2.0, it is easy to pass a value e.g. from a composite component attribute in a call, direct to a backing bean property, as JSF 2.0 now supports method expressions with parameters in EL expressions – just add the brackets and the call arguments. This used to be tricky, and many posts on technical blogs just seemed to answer ‘why on earth do you want to’. Well, perhaps it is unusual, but in this example it feels just the right thing. Normally when linking to a style sheet, one would put the path to the sheet directly on the page in the <link> tag, as one also would when referring to other resources such as images. I have therefore done exactly the same with the themeswitcher – you pass the theme base web context path (along with the default theme name) to the component just as you would do to a <link> tag. This then allows the backing bean to discover the physical theme directory location on disk and automatically iterate it to generate a list of the available themes which are present, which is then passed to the select list of the combo. Whilst the theme base context path could be set up as an injected property of the backing bean, it just does not feel right to do it that way, as normally this knowledge is encapsulated on the page. Sometimes, passing values from the page to a bean is actually the right thing to do!
When using an EL method expression to write to a bean property, note that you can just call a setter on the bean directly as if it was a method, giving the “set” prefix, and passing the value as an argument. You literally just plant the EL call on its own in the middle of the page. (You can of course also use another custom method if you wish, for example if you want to pass a number of properties in a single call). Furthermore, when calling for example a setter or any other method that returns void, nothing is written to the page, as you would expect. In the example code below, the EL expression #{cc.attrs.bean.setThemeBase(cc.attrs.themeBase)} does exactly this.
A composite component acts as a JSF naming container. Naming containers are required to ensure uniqueness of IDs on a page , by modifying Ids to add a prefix. For example a composite component could be placed many times on a page, and the Ids of all its constituent components/controls must be unique. As a test example, when the above component was placed in the <head> section (i.e. not in a form), its clientId was j_idt4. When placed on the page a second time, in the form to show the control panel , its clientId was frmTest:j_idt9. Notice that by default the clientId was automatically prefixed by the form ID. This issue becomes important when Javascript is in use to refer to controls in the component, as the Id given to a control is in turn prefixed by the clientId. For example, when on the form, a select box which was given an Id of cmbTheme actually ended up with an id of frmTest:j_idt9:cmbTheme. This needs to be taken account of in the code. Note that in the Javascript examples in Chapter 9 of Core JavaServer Faces (p369), the form is inside the composite component. This turns things around, as the form ID is then prepended by the clientId of the composite component as the latter is a naming container – our case is different.
By default a form’s controls have the form id prefixed to their id, as the form is also a naming container. This behaviour can be disabled if desired by adding the attribute prependId=”false” to the form tag, but I did not do this.
JSTL functionality can be used such as c:if, and for example you can test parameters passed to composite components (cc.attrs.attrname)– the themeswitcher example uses this with the outputStyle attribute to determine whether to output a <link> tag for the theme stylesheet and set the theme base directory/default theme, or whether to output the themeswitcher control panel. The use of c:if in this way is a powerful means of controlling exactly what a custom component renders on the page, and is a useful alternative to using the render property on a component to prevent it being rendered. In addition, it can for example conditionalise the setting of backing bean properties from the page, as is done in the themeswitcher, which could not be done via toggling the render property on components. In this case, it seemed more convenient and clearer to give two modes to the same component, so that all the design decisions where encapsulated and visible in one place, rather than inventing another component. Other examples of where this might be useful is where a general purpose composite component might be tailorable via its call attributes. For example a table component might have adjacent up/down buttons to allow re-ordering/moving of a block of selected rows, but the re-order capability might not always be needed, so it could be conditionally selected with c:if.
When using JSTL, there are limitations. As an example, I tried c:set to copy an attribute containing the backing bean reference to another variable, to use later in a subsequent instance of the composite component and save passing it twice. Setting a valueChangeListener using the saved copy of the bean reference gave a run time error and is not supported. However, reading and writing properties on the bean using the saved copy of the reference worked fine.
Note that other JSTL functions can also be used, e.g. to return the size of a string or list, as noted here.

Comments Off on JSF 2.0 Composite Components

November 11th, 2010

12:59 pm

Scrollable containers in Primefaces

Posted under CSS Permalink
Tags CSS, HTML, Primefaces, Tip

Some Primefaces containers appear to support scrolling, but this is not universally supported. Layout panels support it, but ordinary panels appear not to.

Fortunately, with IE7 and above, scrolling on a <div> (JSF panelGroup with layout=”block”) works reliably and consistently across modern browsers, so scrolling can just be added within e.g. within a CSS class rule as follows:-

.ss-scroll {
overflow:auto;
}

or:-

.ss-scroll {
overflow: scroll;
}

Using overflow:auto will only add the scrollbars if they are needed, i.e. if content is clipped. Using overflow: scroll will add them all the time so you will get redundant scrollbars when the content does not clip.

Note that for Primefaces, to make a scrolling panel for example, the attribute needs to be added to a containing div inside the panel, and not the panel itself, otherwise the panel header will scroll out of view when the contents scroll which is undesirable.

The w3schools documentation on overflow will be found here.

No Comments »

November 11th, 2010

11:35 am

Fonts reduce in size when Primefaces table moved inside a panel

Posted under CSS Permalink
Tags CSS, Gotcha, HTML, Primefaces, Tip

Update 22/09/2011

The following selector (as documented below) did not work when used for a particular table. CSS ignored the rule presumably for reasons of specificity:-

.ss-nested-widget, .ss-nested-widget .ui-datatable {
font-size: 100% !important;
}

However, the following selector did work (and was also modified to include a dialog as well as a table). This has the advantage of not relying on having ss-nested-widget as a class on the table in order to work.
This has now been adopted as standard as the solution for this issue :-

.ss-nested-widget,
.ui-widget .ui-datatable,
.ui-widget .ui-dialog {
font-size:100% !important;
}

Original Post

This issue is due to font size inheritance.

My default font for all Primefaces components was specified globally as follows:-

.ui-widget {

font-size: 75% !important;

}

The reason for this is that in general it is considered more flexible to go for percentage sizes as these can then be scaled automatically when viewed on smaller devices.

Unfortunately, it appears that when for example a table is nested inside a panel, the font size appears to be 75% of 75% as the rule is inherited and applied twice, as 75% is a relative measurement, The table ends up rendered as a 9px font which is too small. The situation is further complicated by the fact that in the Primefaces skinning, there is a mixture of fonts specified in ems, percentages and pixel sizes, which means that not everything is specified in relative sizing anyway.

There are 2 solutions to the issue, both are straightforward, 1/ is the simplest although arguably not the best due to absolute sizing:-

1/ Change the global ui-widget rule above to use a fixed font size (12px works as a replacement for the above 75%)

.ui-widget {

font-size: 12px !important;

}

2/ Keep the 75% for ui-widget and introduce a new rule to specify a 100% size for nested elements:-

.ss-nested-widget {

font-size:100% !important;

}

This rule needs to be introduced inside the panel. If it is placed on the panel itself, which is the parent element, then the font size just ‘goes large’ to 100%, i.e. larger than the desired default font. To obtain the correct behaviour, the sub-elements inside the panel must be tagged with the style class. It is possible to tag an enclosing <div> just inside the panel, so that the sub-elements inherit it. However, whilst this worked for input selectors and buttons in the panel, tables refused to play ball, and the following rule was needed to ensure that a table in the panel inherited the correct size:-

.ss-nested-widget, .ss-nested-widget .ui-datatable {

font-size: 100% !important;

}

The same kind of trick can be used to target other nested elements which do not inherit the correct size.

An alternative method would be just to add the class to sub-elements individually where required.

No Comments »

November 8th, 2010

3:11 pm

Changing Primefaces Structural CSS – Thin Panel example

Posted under JSF Permalink
Tags CSS, JSF, Primefaces, Tip

Update 10/5/2011

The example project which contains this example is PrimeThemeSwitcherTableNonCC, on page ThinPanel.xhtml. This project may be found in the repository here.

Note that the styling for the repository version has changed slightly from below and is as follows:-

div.ss-thinpanel.ui-panel{
    padding:0px !important;
    border-top-width: 1px !important;
    border-right-width: 1px !important;
    border-bottom-width: 1px !important;
    border-left-width: 1px !important;
    margin-bottom: 1px !important;
}
.ss-thinpanel > div.ui-panel-titlebar {
    padding-top: 4px !important;
    padding-bottom: 3px !important;
    border:none !important;
}

Original Post

Sometimes it is desirable to change not the skin of a component but its structure – size, borders etc.
One example of mine was when I wanted an accordion like component which allows multiple panels to be open simultaneously. The accordion used to allow this but does not any longer. A good alternative to the accordion in this case is a stack of panel components, as they can all have independent expand/collapse buttons, and the close button is optional and so can be removed. As a bonus, a submenu can be added if desired as shown in the component showcase.

My issue with the panel for this use case was simply that it looked too chunky and took up too much real estate on the screen when a stack of them was present. I therefore produced some alternative structural CSS to produce a weight watcher’s version of panel, with the aim that a stack of them would take up no more vertical space than a similar stack of the same number of accordion tabs. In fact, in the end my weight watcher’s panel has ended up slightly slimmer than the accordion.

The following example page shows a stack of 3 standard ‘full fat’ panels followed by a similar stack of 3 of the thin version.
Note the following important points about the way the CSS is implemented:-

The CSS selectors are all driven by the CSS class ss-thinpanel. Simply including this in the styleClass attribute of the p:panel component enables the thin version.
As the new version is tied to the new class ss-thinpanel I have done nothing in CSS which would affect existing use of the panel component – as the example shows, the old can be used alongside the new.
The CSS overrides the structural CSS for the panel component, not the skinning CSS. This way, the changes work consistently across all the themes and do not require any theme changes to be made.
This technique is useful for any occasion where an alternative flavour of a component is needed – just ensure that the structural CSS is targeted (so all themes work), and drive the change by a new CSS class name. You can then have a number of alternative flavours of a component which are useable just by including the required classname.

<!DOCTYPE HTML>
<html xmlns="http://www.w3c.org/1999/xhtml"
   xmlns:f="http://java.sun.com/jsf/core"
   xmlns:h="http://java.sun.com/jsf/html"
   xmlns:p="http://primefaces.prime.com.tr/ui">
<f:view contentType="text/html">
<h:head>
    <link type="text/css" rel="stylesheet"
     href="#{request.contextPath}/resources/themes/eggplant/skin.css" />

No Comments »

November 8th, 2010

1:18 pm

Header width incorrect on Primefaces scrollable table

Posted under JSF Permalink
Tags Bug, CSS, Gotcha, JSF, Primefaces, Tip

If a header facet is used on a Primefaces table, the header does not allow for the scrollbars if present. the column headers do adjust for the scrollbars (although there are issues with column alignment between the headers and the data – a number of such errors have been posted to the Primefaces forum).

One workaround for this is to selectively include a CSS selector to adjust the header <div> width when the scrollbars are present.
The following selector achieves this:-

    .ss-tableheader-scrolladjust > div.ui-datatable-header {
        width:495px;
    }
</style>

The following table definition selectively includes this when enough rows are present to require scroll bars (this must be derived empirically as it depends on the height of the table, font size used etc. :-

     <h:panelGroup layout=”block” style=”width:500px;”>
     <p:dataTable var=”car” value=”#{tableBean.carsSmall}” scrollable=”true”
         styleClass=”#{fn:length(tableBean.carsSmall) lt 8 ? ” : ‘ss-tableheader-scrolladjust’}” height=”200″ >
         <f:facet name=”header”>
            Ajax Sorting
         </f:facet>
         <p:column headerText=”Model” sortBy=”#{car.model}”>
             <h:outputText value=”#{car.model}” />
         </p:column>

         <p:column headerText=”Year” sortBy=”#{car.year}”>
             <h:outputText value=”#{car.year}” />
         </p:column>

         <p:column headerText=”Manufacturer” sortBy=”#{car.manufacturer}”>
             <h:outputText value=”#{car.manufacturer}” />
         </p:column>

         <p:column headerText=”Color” sortBy=”#{car.color}”>
             <h:outputText value=”#{car.color}” />
         </p:column>
     </p:dataTable>
    </h:panelGroup>

No Comments »

November 8th, 2010

12:51 pm

Setting Column Headers on a Primefaces Table

Posted under JSF Permalink
Tags Gotcha, JSF, Primefaces, Tip

The normal way to add JSF table headers is to use a header facet :-

<p:column sortBy=”#{car.model}” >
    <f:facet name=”header”>
        <h:outputText value=”Model” />
    </f:facet>
    <h:outputText value=”#{car.model}” />
</p:column>

In Primefaces tables, this can give column width and alignment issues in some cases, so the headerText attribute of the column should be used instead :-

<p:column headerText=”Model” sortBy=”#{car.model}”>
<h:outputText value=”#{car.model}” />
</p:column>

No Comments »

November 5th, 2010

6:34 pm

Issues with JSF h:outputStylesheet and Primefaces/jQuery skinning

Posted under JSF Permalink
Tags Bug, CSS, Gotcha, JSF, Primefaces, Tip

I tried to use this whilst experimenting with dyamic style sheets, but this support post here confirms that it does not work due to an issue with the way the images are referenced.
The symptom is that you get basically correct looking layout/colours but none of the images have loaded.
The solution is to use a link tag directly e.g.:-

Whilst on the subject of h:outputStylesheet, it should be noted that for the following example:-

<h:outputStylesheet library=”css” name=”styles.css”/>

Whilst the href of the resulting generated link tag looks like this:-

the actual physical directory containing the style sheet in this case will be

…\WebContent\resources\css\style.css

i.e. the logical to physical mapping of the web path in this case is not straightforward and obvious. If you just create the resources folder under your project’s WebContent folder and place all your libraries as subfolders under that, it should all work correctly (the above issue with jQuery/Primefaces notwithstanding)!

No Comments »

November 5th, 2010

11:08 am

Tying Primefaces page styling to the theme

Posted under JSF Permalink
Tags jQuery, JSF, Primefaces, Tip

With Primefaces, rather than applying your own style for borders, headers etc. it is important where possible to tie the styling in to the theme using theme classes.
Here is an example of this from the Primefaces showcase, used to display the header for each example:-

<h1 class=”title ui-widget-header ui-corner-all”>DataTable – Pagination</h1>

This example places a border around the header according to the theme, sets the appropriate background, and adds corner rounding as per the theme.
Whilst in some cases another Primefaces component might be the right approach (in this case a panel would do it), in many cases this is undesirable and also overkill for the job. Taking our lead from the Primefaces showcase, it is clearly acceptable to use the underlying jQuery UI classes where appropriate, as I have also done here.

Here is another example page fragment which I have used to group a few controls/buttons in a box:-

<h:head>
    <style type=”text/css”>
        .ui-widget, .ui-widget .ui-widget {
            font-size: 80% !important;
        }
        .ss-controlgroup {
            float: left;
        }

</style>
</h:head>
<h:body>
<h:form>
<h:panelGroup layout=”block” styleClass=”ui-widget-content ui-corner-all ss-controlgroup”>

(controls in the box go here)

</h:panelGroup>
</h:form>
</h:body>

Details of the jQuery UI, on which Primefaces is based, may be found here.

No Comments »

November 4th, 2010

5:22 pm

Creating Primefaces icon buttons using the built in theme icons

Posted under JSF Permalink
Tags JSF, Primefaces, Tip, Tutorial

There is a quite a large collection of useful built in icons, such as those used for the table paginator buttons. It is useful to be able to reuse these in your own buttons:-

It simplifies coding as you don’t need to roll your own icons.
The Unicode character set has quite an extensive library of symbols (see here for details of how to use numeric unicode references in HTML to access them), and it is at first tempting to use them as they are readily available. The font color used for them will change automatically with your chosen theme, so it seems like you might be home free with minimal effort for buttons with symbols on, by just using them as text labels on a button. However, you are at the mercy of the theme font stack/Browser font fallback/font rendering as to how well they are represented in a given font. When I tried some of them out the rendering was very poor in some Primefaces themes, and getting them centrally positioned on buttons of various sizes involved some quirky bits of CSS which were dependent on your chosen font size, particularly if you wanted multiple symbols on a button (e.g. 2 triangles to give a double arrow). I decided this was a blind alley and in the end discovered that using the theme icons was better and easier.
You don’t need to tweak a set of new ones for each theme. Themeroller may assist with recolouring them for a theme (haven’t used it yet) but even if it does reusing is still easier than running themeroller to tweak every theme.
It promotes consistency – your own e.g. arrow buttons can have the same look and feel as e.g. the table paginator ones, so as well as making your life easier you have scored points for better user interface design. When a user sees the same icon used consistently in different places this gives a strong visual cue on how the interface works and what to expect.
Reusing them minimises downloading and caching additional icons.

After quite a bit a bit of experimentation with both commandButtons and commandLinks, and learning about how JQuery (which Primefaces is based on) works, I came up with the following example page which illustrates how to add a built in theme icon to a commandButton:-

<!DOCTYPE HTML>
<html xmlns=’http://www.w3c.org/1999/xhtml’
   xmlns:f=’http://java.sun.com/jsf/core’
   xmlns:h=’http://java.sun.com/jsf/html’
   xmlns:p=’http://primefaces.prime.com.tr/ui’>
<f:view contentType=’text/html’>
<h:head>
    <link type=”text/css” rel=”stylesheet”
     href=”#{request.contextPath}/themes/cupertino/skin.css” />

    <style type=”text/css”>
        .ui-widget, .ui-widget .ui-widget {
            font-size: 80% !important;
        }
        .ss-iconbutton {
            height:21px;
            width:30px;
        }
        .ss-spacer {margin-right:4px;}
        .ss-iconbutton-icon {
            background-color: transparent;
            border:none;
        }
    </style>
</h:head>
<h:body>
<h:form>
    <p:commandButton styleClass=”ss-iconbutton ss-spacer” onclick=”alert(‘Previous button clicked’)”
      image=”ss-iconbutton-icon ui-icon ui-icon-seek-prev”/>
    <p:commandButton styleClass=”ss-iconbutton” onclick=”alert(‘Next button clicked’)”
      image=”ss-iconbutton-icon ui-icon ui-icon-seek-next”/>
</h:form>
</h:body>
</f:view>
</html>

Note the following points about the example:-

The image property of the commandButton accepts a CSS class which loads the icon as a background property. If you inspect one of the command buttons e.g. with Firebug you will note that it applies this class to a <span> tag. The advantage of this is that the icon is defined in theme switched CSS rather than HTML. Note that as is normal when applying CSS classes, multiple classes may be passed as a space separated list as I have done.
The example uses some of the standard jQueryCSS classes from WebContent/themes/cupertino/skin.css which is the skinning css present for each theme (in this case, the theme used is cupertino).
Class ui-icon defines and loads an icon file for the theme. The chosen file may be modified by the jQuery state classes such as ui-state-default, ui-state-disabled, ui-state hover etc. Therefore,the added benefit of using the standard jQuery classes and icon files is that mouse hover automatically causes a switch of icon file to change the colour as determined by the theme, and things like enable/disable of the button also have the correct effect. In short – it all just works as it should with no effort if the built-in classes are correctly used.
A fundamental mechanism used by jQuery for states like hover is to use Javascript functions triggered by the hover/mouseover to dynamically add and remove CSS classes from elements. For example, class ui-state-hover is added and removed on hover. this may be seen within Firebug when you hover over the button with the mouse. Note that therefore jQuery does not only use CSS Pseudo-classes such as :hover, :active to support this as one might expect. Examples of the latter will be found in skin.css but they do not give the whole picture about what is going on internally. This is presumably done for reasons of browser compatibility as CSS pseudo classes do not work consistently across different element types and browsers (IE is especially limited in this regard).
Primefaces/jQuery stores multiple icons in a single icon file, and uses the css background-position property with appropriate X and Y pixel coordinates in the file to pick out the desired icon. If an icon file is examined with Windows you will see all the icons store in the file in a matrix fashion. A set of classes is defined in skin.css , one for each icon, to encapsulate the position of that icon within the icon file. In the above example, ui-icon-seek-prev and ui-icon-seek-next have been used to select the next and previous icons used on the dataTable paginator.
By default, the icon in a commandButton is given a border and a background colour, which in this case we do not want. These are removed by class ss-iconbutton-icon above which is also passed as one of the classes to the image attribute of the commandButton.
Whilst we are to an extent going “under the hood” and using mechanisms and CSS classes which are not part of the documented Primefaces interface, they are a standard part of jQuery upon which Primefaces is based. When extending a user interface a fashion similar to the above, it is highly recommended to gain familiarity with the workings and operation of jQuery, as this can allow additional functionality to be harmonised with the existing functionality. This will typically make adding functionality easier, promote consistency with the existing feature set, and as in this case can give a number of side benefits for no extra work. Of course, using features that are not part of a formally documented Primefaces interface may mean that your code needs to change with later releases, but in this case, as these are jQuery features, it definitely feels the right way to go.

The jQuery UI web site, which contains full documentation, tutorials and demos, may be found here. In my opinion it is certainly worth delving into further to augment your understanding of Primefaces, especially when you want to extend or reuse features and components in ways like the above example.

No Comments »

Blog Archives

Search

Pages

Categories

Archives