Search
Categories

Entries in CSS (5)

Wednesday
23Sep2009

Coloring Specific View Rows Using a Dynamic Table and CSS in XPages

I had a student ask recently about the ability to set the background color of a table row based upon a value in the data.  This is something that was pretty commonly done in traditional Domino Web Development.  In investigating how to do this I couldn't find a way to implement this using the standard View control, so I developed the following technique.

I use a dynamic html table (I showed how to implement this in my previous post here) but this technique can be used with a Data Table as well.

Create a CSS Style sheet that will map the colors to be used to the data values from the Domino View data. In the View I'm using as a data source there is a column that contains a Status value with one of the following values in it

  • New
  • Existing
  • Terminated
  • Pending

I have the following CSS in a stylesheet resource called rowclasses.css that I will be using in this demo.

.New {
background-color: red;
}
.Existing {
background-color: blue;
}
.Terminated {
background-color: fuchsia;
}

The class definitions in the CSS stylesheet are the same as the values from the status column.

Add the style sheet as a resource for the XPage.

 

 Before the Stylesheet is applied the XPage rendered in the browser looks like the following

 

We want the individual table rows background color to be set using the colors from the CSS style sheet based upon the value from the Status column in the View data.

To review, the dynamic table uses a repeat control that has a variable called "customers" for each row of data that will be displayed.  The value in the status column can be read from that variable using the Expression Language syntax customers.Status.

To set the value of the table rows background color, select the table row.  On the Style tab of the Properties tab click the computed diamond icon next to the Class field and choose "Compute value...".

 

In the Script Editor dialog box that opens up change the language to Expression Language and type in the expression customers.Status.  Click the OK button to save the expression to the class field.

Save the XPage and preview it in the browser.  Now each rows background color will be set to the value in the CSS stylesheet based upon the value from the status column.

The status column does not have to be displayed, but it does have to be available in the data.

The style does not have to be applied to the entire row, it could be applied to one or many table cells as well.

The application with complete source code can be downloaded from my website here.

 

 

 

Friday
18Sep2009

XPage videos on demand!

Last night I published a new episode of Notes In Nine.  This one talks about using the Blueprint CSS Framework.  It can be found here:

Episode 6 - A blueprint for XPages

As a reminder, my other XPage focused shows can be found here:


Episode 1 - The Repeat Control

Episode 2 - You don't need to re-write your apps to start using XPages.

Episode 3 - Basic Searching of a view.

Episode 4 - Scoped Variables and learning how to so an "Embedded View with Show Single Category"

Monday
10Aug2009

Writing Efficient & Scalable XPages

I spent quite a bit of time recently profiling and optimizing an xpage application I've been working on. I needed to be quite ruthless, every fraction of a millisecond counted, so I dug deep to squeeze everything I could out of it. The application was tested for client performance, as well as on the server while under load. Here are some of the tips and tricks used to optimize my application. Steve Castledine has already made some excellent comments on xpage performance on his blog in this post XPages Memory Usage and Performance Tips - 8.5.

Use the correct container

Be careful not to over use <xp:panel>, if you not displaying or editing data use <xp:div>. If you don't need any xpage functionality such as themes or computing visibility then consider simply using a HTML <div>. If you are using <xp:panel> but it's contents are read only be sure to add the attribute readonly="true"

Avoid unnecessary computations
This might seem obvious, but while profiling my application I found that there were a lot of calls that could have been made once at load time, externalized or even simply hard coded. For example, I was displaying the name of the application, it was a computed field with @DbTitle as its value, I replaced it with a hard code string since it never changed, a small saving but when there are several of them and the server is under high loads they add up.

Serve static resources from disk

From client side and server side this can potentially offer the greatest overall improvement. Having all the resources such as images, css and client side javascript, nicely wrapped up in a nsf is a great way to share and quickly deploy an app. Unfortunately there is additional overhead serving the content from the nsf. Instead consider placing them on the disk, somewhere under the .../domino/data/html/ directory. It may require a little be of a rework of your app but it is worth it for a fully deployed app, using themes can help reduce the effort.

Use Partial update

Use partial update whenever you can. One, it gives the user the impression of better performance and two, it reduces the work load on the server. There is a lot more I can say here but I think it warrants a post of its own so I will return to the topic in the near future.

Less controls

Avoid having too many custom controls. When a control is loaded there are several java new calls, which are relatively slow. If you can roll several controls into one, do so. For example if you have a sidebar control that always has the same three controls in it, roll them into one sidebar control.

Themes

Create your own themes from scratch. Creating a theme that extends from the webstandard or another supplied theme will include extra stylesheets and styles that you might not need. Be prepared to spend more time writing css though.

$ vs #

Whats the difference? #{javascript:...} is called at render time, whereas ${javascript:...} is called at load time. Use $ when the value computed is not going to change once the xpage is loaded, this is particularly usefully when using partial updates.

Scopes
Generally I try to avoid using any of the scopes, but when I do use them it tends to be for data I want to store long term e.g. the user session. If you are using any of the scopes, be sure to use the scope with the shortest span you need and clear variables once they are no longer required

HTML optimizations
From the client point of few, general HTML optimizations apply to XPages as well. Make sure all your javascript and css files are minified, use sprites and long expiry headers on static resource such as images. Tools like YSlow & FireBug are great for analyzing your pages.

Data source vs @Functions

For small views, such as a Table of Contents view consider using @DbColumn instead of a data source and repeat control to access and display the data. For small views there is a small gain but it adds up when your application is under load. The downside of this is it is more difficult to render the data nicely and its not a generic solution.

Ad Hoc Caching

This was a sneaky suggestion someone else came up with, we generated some data from a view then stored in it in the session scope. The data was always pretty small so we thought it would be better to take the hit in memory rather than having to calculate the data ever time the page was loaded. Again this is not really a general solution, but one I thought worth mentioning.

That's about all the tips I can think of for the moment, as I come across more I'll try to update this post, or make additional post. Originally posted on my blog here

Friday
17Jul2009

Themes and CSS Frameworks

When writing sample XPage applications I tend to use the oneUI theme that is distributed as part of the IBM Lotus Domino server, the main reason being that it can make the sample applications look good while reducing the size of the NSF file.

When it comes to creating your own internal applications you may not want to use oneUI as it contains a LOT of CSS that you may never even use so that will mean you need to build your own style sheets that will include layout stylings, font settings and color schemes. Fortunately you don't need to start from scratch, there are a couple of CSS frameworks that work well with XPages and it's very easy to create a theme document for them.

The main CSS Frameworks that I have been looking at are Blueprint ( Modified MIT License & GPL License ) and Tripoli ( GPL License ) and a merging of the two, plus some bits from a few others, called BlueTrip ( GPL License ). When selecting a CSS framework one of the important things to look at is if it uses ID's to apply it's styles or if it uses classes. As XPages dynamically changes the ID's of elements rendered to a web browser you will need to use a CSS Framework that only deals with classes. You can quickly determine this by opening the CSS file and if you see any #'s at the start of a style definition then you know it's using ID's so avoid that particular CSS framework for use in XPage applications. So far I have found that the YahooUI ( BSD Licensed ) uses some ID's for layout controls so it it probably a bad choice.

Once you have picked the CSS Framework that you want to work with adding it to your application is very easy. In your Domino Designer client got the Resources -> Style sheets section in your NSF file and import the CSS files that are part of the framework. In Blueprint these consist of screen.css, print.css and ie.css. The main file, screen.css, will reset the browsers css to basic settings so that all browsers start with the same defaults, it then contains settings for standard elements like check boxes, input fields, buttons and fonts so that these elements will appear the same across any browser and lastly it contains a grid layout system that you can read about on the Blueprint website. This grid system is where a framework like blueprint will save you a lot of time.

The other two files are not necessarily needed, ie.css contains special css hacks so that some of the framework will work in Internet Explorer 6, if your not planning on supporting that browser then you should just leave it out entirely. print.css contains special css definitions that are only applied if a web page is printed. Currently in Xpages there is no way to specify the media type for a CSS file that is added either as a resource on the XPage or via a theme so it is probably best to leave this file out also but if you don't mind editing the css file you can wrap the css in an '@Media print{}' rule to work around this current limitation. Your theme document will look something like this when finished :

<theme>

<resource>
<content-type>text/css</content-type>
<href>/screen.css</href>
</resource>

<resource>
<content-type>text/css</content-type>
<href>/print.css</href>
</resource>

<resource rendered="#{javascript:context.getUserAgent().isIE(0,6) == true}">
<content-type>text/css</content-type>
<href>/ie.css</href>
</resource>

<resource>
<content-type>text/css</content-type>
<href>/application.css</href>
</resource>

</theme>

The extra theme reference to application.css would be your own custom css resource where you will add in all your own layout and color schemes for the application. As you can also see I am using the rendered= method to make sure the css for Internet Explorer 6 does not get sent to Firefox or other web browsers.

Using a CSS framework can help you cut down on some of the more basic parts of building your XPages web application. If your not interested in using the grids portion of blueprint then even it's reset and standardization sections will ensure that all browsers start on a level playing field.

Wednesday
15Jul2009

Using Themes In XPages Part One

When developing XPage applications you have two options for adding CSS style sheets to your code. You can attach them directly to the XPage or Custom Control resources section or you can create a theme document and reference them from there.

Adding the style sheet directly to the Xpage or Custom Control does have some advantages. The list of classes will appear in the styles section for all the controls on that page which will make selecting them a little easier and the 'design' perspective for the XPage will try and apply the styles so you get a better idea of how the page will look when it's rendered in the browser. It's not perfect but it can help.

Creating a theme document, however, allows you to build different sets of style sheets so the person deploying your application can easily change the look and feel of the application by selecting which theme to use. As an example you could have different color based themes. The disadvantage is that the list of classes in the CSS file(s) won't display in the styles section for each control so you need to have some sort of cheat sheet to help you remember them and the design perspective won't render the controls with the css.

A theme document is just an XML file within the notes database. You'll find them in the Resources -> Themes section of the designer client. The basic structure of a theme document looks like this :

<theme extends="webstandard">
<resource>
<content-type>text/css<content-type>
<href>stylesheet.css</href>
</resource>
</theme>

The first thing to note is the opening <theme> tag. As you can see you can decide to extend one of the builtin XPages themes. When the 'extends=' attribute is added to the theme tag the Xpages renderer will first process and add all the resources from that theme before processing your theme resources. The built in themes are 'webstandard', 'oneui', and 'notes'. If your not extending one of the built in themes then you can leave this attribute out completely.

Inside the theme tags you have resource tags. The resources can be style sheets as in the example above but it's also possible to add other resources, you just need to change the content-type as required by the resource type. You can have as many resource sections as you need for your theme.

The resource tag can also contain a 'rendered' attribute like this

<resource rendered="#{javascript:context.getUserAgent().isIE(0,6) == true}">

In this example the rendered attribute is running some server side javascript to determine which browser is being used. If it is Internet Explorer versions 0 thru 6 then the resource is rendered to the web browser, if your using higher version of IE or a different web browser then the resource does not get sent to the users web browser. This is a great way of adding special stylesheets that contain hacks for some of the behaviours of CSS in earlier versions of IE.

In the next part of this mini series I'll show you how to automatically add certain style classes to controls using a theme document.

Using Themes In XPages Part Two