Monthly Archives: June 2011

Resource bundle for dynamic content –server side or client side?

In fully RIA clients such as Flex, I got in taking a design decision –where to keep the names of the columns for a table, Server side resource bundle or Client Side resource bundle .
If number of columns is fixed, choice is rather simple –put it at client side. Having bundles at client side give flexibility to UI programmers to manipulate them as per business need.
But, Often we come across use case where the number of columns in a table are not predefined –they vary according to the result of business use cases executed. If there are fixed columns, resource bundle can stay at client side, challenge is when there are variable number of columns to deal with that?
Approach 1: I prefer keeping it at server end, and passing an Array of “column display labels” which will be used to display the names of the columns, along with actual column names. UI programmer can blindly loop through the “Labels” array and generate column names.
Advantage: Varying of column names has no Impact on UI programmer, UI team blindly iterate through Array of labels.
Disadvantage: If a column name needs to be changed, UI programmer cannot handle it independently. It should be coordinated to server side team.
Approach 2: In second approach column names can be kept in a client side resource bundle.
Advantage: UI programmers can independently manipulate the names.
Disadvantage: UI programmer will have to maintain a list of “Master Columns”. At any point in time if business case warrants adding more column, UI team should be notified and changes made in client side Resource Bundle as well. This could result in real sync up issue.

Leveraging factory pattern for UI components in Flex

Using Factory method for UI components is always a good Idea. This helps adding common look/feel, validation etc. to a set of similar component at centralized place.
For example:

  • Text box for price input with custom requirement (as only two decimal places, in a given range, a custom look and feel etc.) can appear on multiple pages
  • Standard stuff as email entry boxes can have similar custom requirement

There are two approaches to deal with above

  1. One argument that most of validation is standard and out of box these day (Email, Date) while css and styling can be leveraged from a shared location, so these can be done “in place”. But greatest flip side I see that any change, say decimal precision from 2 places to 3, color change, background image change etc., will have to be tracked at multiple pages, even if just a reference change (CSS name, Validator name etc).
  2. Factory approach -I can have a method as
    UIElement getATextBoxWith2PlaceDecimal(){

    This can encapsulate all validation and custom requirements.

I tend to use factory If I see repeatation on lot of pages -it seems to be a cleaner and maintainable approach.