Code Luck

The choice of the backing store in a large project is almost always a political decision that's already been made for you. If your company already has a farm of Oracle 9 databases, well... that automatically becomes your choice. Rarely does a single consultant or developer get to pick a database solution. It's almost always a case of, "This is what we have; deal with it."

So chances are high that I'll never ever get to use Object Databases in a project situation, given their poor market penetration. However, here is an excellent comparison of Object Databases versus traditional RDBMS systems from DevX.

I am playing around with an Object Database called db4o, which is licensed under GPL for non-commerical use. More on that later.

I've played around quite a bit with the Jakarta Commons libraries over time and over several projects. Among these, the Jakarta Commons Configuration library is extremely useful.

Very often, we encounter a particular crosscutting concern when developing medium to large scale projects: that of managing user and/or application preferences. This seemingly simple task often leads to much wasted and duplicated effort when the development team should really be focusing on core project tasks. The Commons Configuration library can come to the rescue in such situations.

Managing user/application preferences can get complex depending on the requirements. Consider:

(1) The project may start out storing configuration information in simple ".properties" files, but later, some genius might want to migrate everything to XML files. In such instances, you want the property accessor calls abstracted out enough so that the migration can take place with minimal, localized code change and without breaking property accessor calls which might be sprinkled throughout the codebase.

(2) You might want to support a hierarchy of property sources. For example, you might have an application-wide property source that provides the default values, but allow each user to specify his or her own property file to override the defaults. In other words, you need to support multi-source, composite configurations.

(3) You will in some cases want to support nested and/or list-based properties in your properties files.

(4) You will want to synchronize access to shared properties files in case of concurrent updates.

(5) You might want to provide an "autosave" feature or an "auto reload" feature when a preference/property is updated.

Well, the Jakarta Commons Configuration library goes a long way in providing a very flexible framework for configuration/preferences management. It supports ".properties" file based configurations and XML files. The accessor syntax for the XML files is XPath-like and can get quite intricate, I noticed.

A wonderful feature is the provision of configuration change listeners which can listen for changes to a properties file and respond appropriately. Any Java class can set itself up as a listener to a Configuration object, which fires the required events.

I have yet to compare the Jakarta Configuration library with the Preferences API in Java, but from a cursory glance, it seems to me like the Preferences API does not even come close in power. Also, the .Net System.Configuration classes seem to be much more specific in the sense that they seem to concentrate on providing access to the .Net framework config files like machine.config and web.config and not so much on supplying a flexible and generic configuration management framework.

Wishlist: A nice addition to the Commons Configuration library might be access methods to configuration data stored in relational databases and hierarchical stores like LDAP, but that is probably asking for too much.

If the Java Collections Framework is too limiting for you, then you should check out the open source Jakarta Commons Collections from the Apache project.

It adds several important extensions such as ordered maps, bi-directional maps, bags (i.e. multi-sets), Fifo queues, and certain other convenience features like iterators and transformation primitives.

I believe .Net has a multiset implementation in its System.Collections.Specialized namespace, but no bidi maps. Also Jakarta Collections adds a type-check primitive to ensure that only objects of a certain type get stored in a collections, though I don't think this removes the overhead of boxing and unboxing that you typically encounter in generic collections that store data as "Objects". Type-safe collections that don't do boxing and unboxing will necessarily speed up operations on large collections, but the only way to have that seems to be the C++ templates, .Net generics, or Java 5 generics. The trade0ff with generics is of course binary code bloat leading to larger executables, not to mention more intricate syntax.

I came across this old post about some 'Don't' with SQL server. I found it helpful and elightening about some facts.
http://www.sqljunkies.com/Article/92CC4817-604D-4344-8BE0-4490F8ED24B6.scuk

Here are some snippets from it.

1. SCOPE_IDENTITY() Vs @@IDENTITY

@@IDENTITY will return the last identity value entered into a table in your current session (this is limited to your session only, so you won't get identities entered by other users). While @@IDENTITY is limited to the current session, it is not limited to the current scope. In other words, if you have a trigger on a table that causes an identity to be created in another table, you will get the identity that was created last, even if it was the trigger that created it. Now this isn't bad, as long as you ensure that things are done in the correct order. Where this can get ugly is when there is an application revision and a new trigger gets added that gets fired from your stored procedure. Your code didn't anticipate this new trigger, so you could now be getting an incorrect value back.

SCOPE_IDENTITY(), like @@IDENTITY, will return the last identity value created in the current session, but it will also limit it to your current scope as well. In other words, it will return the last identity value that you explicitly created, rather than any identity that was created by a trigger or a user defined function.

2. Prefix Stored Procedures with "sp_"

It is strongly recommended that you do not create any stored procedures using sp_ as a prefix. SQL Server always looks for a stored procedure beginning with sp_ in this order:

1. The stored procedure in the master database.
   
2. The stored procedure based on any qualifiers provided (database name or owner).
   
3. The stored procedure using dbo as the owner, if one is not specified.

Therefore, although the user-created stored procedure prefixed with sp_ may exist in the current database, the master database is always checked first, even if the stored procedure is qualified with the database name.

I took time and broke the tradition of prefixing the stored procs with sp_ and renamed all my stored procs by removing the prefix, also replaced @@IDENTITY with SCOPE_IDENTITY() for future maintainance purposes.

For Pros these might be 101s, but his article explained by exactly not to do some things, rather than just putting it down as a rule on the holy grail.

HTML templating has always appealed to me. For most database-backed web pages, dynamic generation of the entire page--especially the static parts that don't change--is a bit of a bother. Conceptually, a HTML page can be seen as a combination of static bits that don't change often and dynamic bits that change often depending on data coming from a backend data store. A good example is a roster of students signed up for a course. The static bits in this page might be the navigation bars, course information, faculty information, etc. while the list of students might be an incremental and dynamic HTML table that grows/shrinks as students sign up or drop the course.

Generating the static parts of the above page in say, a servlet, is a pain. A simple edit like a change in a faculty's phone number will require a code change if the generation of the static parts is embedded in code. Templates solve this problem by abstracting the static parts out in a template file which looks like a HTML file but with the addition of placeholders for dynamic content. In the case of Velocity, the dynamic content is generated by a Java program or a servlet. The dynamic content is then merged with the template to produce the final output to the client. An edit to a prof's phone number now becomes a simple edit in a text editor to the template. No code change is required.

Velocity facilitates a separation of concerns. Web designers can work with the template (provided they don't mess with the dynamic content), while business logic gurus can take care of serving up the dynamic data in the page.

In my opinion, the separation is not very clean because it is quite easy to distribute the dynamic placeholders all over the template, making the template look like a horrible mess of HTML tags and Velocity tags. Web Designers might recoil in horror at working with such a template. But if some discipline is exercised in the structuring of the templates, it can be an useful tool.

One concern that might be expressed is that the merging of templates is a relatively slower operation than generating the page by hand. The good news is that some of that loss in speed can be mitigated by turning on template caching in a properties file that Velocity supplies for configuration purposes. If the data does not change between requests, the output page is fetched from the cache instead of being merged and re-generated.

Note: Velocity is a generic template engine and therefore can be used for any sort of templating task, not just HTML templates. For example, it can be used for sending out bulk mail with a mail merge sort of feature by utilizing email templating.

The idea behind the Google Web Toolkit is simple.

When building rich-n-thin clients using DHTML and AJAX, many people have noticed that Javascript standardization in browsers is--how shall we say it--piss-poor. Differences in event handling, divergent error handling, DOM quirks; it's a party. Throw in the fact that Javascript is loosely typed and you will soon start pulling your hair out by the handfuls.

The Google Web Toolkit offers this proposition: Write your AJAX apps in Java and then compile the code into Javascript. You get the benefits of programming in a strongly typed, true OO language and also some protection from browser quirks since they are abstracted out for you by the GWT.

Note that you can't use the entire set of Java libraries while coding a GWT app, of course. You can only use a subset that can be translated into Javascript. For example, it is crazy to use the threading classes and expect that to be translated into Javascript. But quite a few classes from the java.lang and java.util are available for you to use. Personally, I wasn't very impressed with this. For example, why can't I use the Drag and Drop Java API and have the resulting code translated into browser-agnostic Javascript? More and more AJAX apps are providing drag-n-drop support; it would have been nice to have this support in GWT.

Where GWT really shines is in the custom wrapper classes that are provided for you. The DOM has been completely abstracted out for you. So have events, cookies, timers, the top level browser window, the history list. A HTTPRequest object serves as an interface to the XMLHTTPRequest to make AJAX calls in a cross-browser way. There are classes for JSON parsing, XML parsing, and making RPC calls.

Also, the list of widgets provided is impressive: a Grid, a FlexTable (a dynamically growing/shrinking table), a Tree, a TabPanel, among others. It really beats coding these common UI elements in pure DHTML and Javascript.

What really speeds up the development cycle is that you can code up a storm in Java and then run your app in a "hosted" mode which is like a local Java runtime. If your application runs in hosted mode, it is guaranteed to run in "web" mode, which means it will run cross-browser. Once you have your code tweaked in hosted mode, it is a simple matter to run a compile shell script (provided by the GWT) to translate the Java to Javascript.

Shortcomings of GWT: Sometimes you have to get down and dirty with Javascript because the GWT doesn't quite manage to encapsulate everything for you behind a Java facade. A good example is lack of support for drag and drop. Or something like, say the Observer/Observable classes in Java--surely that could have been translated to Javascript. I know that pure Javascript libraries exist that implement the Observer pattern.

Personal opinion: I think GWT is here to stay, unless the next version of ECMAScript i.e. version 4, makes toolkits like the GWT philosophically redundant.

Note: I believe the Microsoft community has something similar to the GWT called Script# that uses C# as the front-end language instead of Java.

I was using rangevalidator in my user controls.

the ranges I was setting was

0 - 49
0 - 100

For some reason, the validator for (0-100) range was validating only 0 & 100 and invalidating the rest. It wasn't clear to me why it wasn't working for 0-100 while it was working for 0-49.

Both being part of same user control there was no discrepancy in settings of the control.

After searching on the net I found that one has to set the "Type" property of the asp:RangeValidator to "Integer" apart from setting the "MaximumValue" and "MinimumValue", in order for it to consistantly work for any range of integers.

Other Type options are

Currency
Date
Double
Integer
String

On my current project I have discovered a nice way to write generic database access code in the business layer.
Most database access operations are

a. returning DataTable of results (for binding with
objectdatasource & other controls)

b. Inserting/updating data

c. returning a single value (execute scalar)

The approach I have been following is to reduce the number of places where I write database code (code reuse) so as to make it maintainable and make necessary changes in a few places instead in all of the business layer.

e.g

  148 public class DBHandler

  149 {

  150     private static DataTable GenericGetDataTable(string storedProc,

  151     params SqlParameters[] parameters)

  152     {

  153         DataTable retTable = null;

  154         string connStr = Configuration.AppSettings["ConnectionString"];

  155         using (SqlConnection conn = new SqlConnection(connstr))

  156         {

  157             conn.open();

  158             SqlCommand cmd = new SqlCommand(storedProc, conn);

  159             foreach (SqlParameter para in parameters)

  160             {

  161             cmd.Parameters.Add(para);

  162             }

  163             cmd.CommandType = CommandType.StoredProcedure;

  164             .

  165             .

  166             .

  167             .

  168             conn.close();

  169         }

  170         return retTable;

  171     }

  172     public static DataTable GetBooks( int publicationID, string authorName)

  173     {

  174         SqlParameter pubID = new SqlParameter("@pubID", publicationID);

  175         SqlParameter authName = new SqlParameter("@authName", authorName);

  176         return GenericGetDataTable("sp_getAllBooks", pubID, authName);

  177     }

  178     public static DataTable GetPapers(int journalID, int year)

  179     {

  180         SqlParameter jourID = new SqlParameter("@journalID", journalID);

  181         SqlParameter jYear = new SqlParameter("@year", year);

  182         return GenericGetDataTable("sp_getAllPublications", jourID, jYear);

  183     }

  184     .

  185     .

  186     .

  187     .

  188     // similarly for INSERT & Execute Scalar methods

  189     private static object GenericExecuteScalar(string storedProc,

  190     params SqlParameters[] parameters)

  191     {

  192 

  193     }

  194     private static int GenericInsert(string storedProc,

  195     params SqlParameters[] parameters)

  196     {

  197 

  198     }

  199 }

Here we use the params SqlParameters[] parameters to accept variable number of arguments in turn enabling us to write generic methods.
This way we minimize the places where we write database access code. I think I achieved a lot of code reuse by this aproach.

One would say that why not have ONE generic public method in DBHandler (for each operation) that accepts a storedProc & parameters. The only argument I have against this approach is that, with this approach my "page behinds" (controllers) will be clouded by names of stored procedures and SqlParameters statements. I think this would cause more maintainance depending on all the places from where it is called. I think it wouldn't be completely MVC complaint.

In this approach, only the changes need to made to the DBHandler class and specific methods if needed.

I have also realised from reading some posts from microsoft gurus that they are prominently using "using () { }" in their database access operations in order to dispose of the connection objects.