Name given to that extra code or work you did when you were inspired or just had an espresso.

Month: September 2009

A common problem is Ajax applications is what to do with the user when their session times out. Everyone handles this one differently, so there isn’t really a right or wrong way to do it. It depends on the business cases that you have how you will implement it. I decided to share the way I have done it for an application I am working on.

The first thing you need is a custom object that you will use to create the timeout and publish the idle and active events that we will subscribe to later. This is a copy of a class that I found on the Dojo Website, but it’s been heavily modified to make it work correctly.

console.debug("idle...logging out");var logoutTimeout = setTimeout(logoutNow, 60000); //Show the logout dialog for 1 minute. Give time to reset.raiseQueryDialog("Session Timeout", "Your session is about to timeout. Would you like to continue?", function(isContinue){

What happens in this example is that after 14 minutes of idle, a message will popup asking the user if they would like to continue. If the user chooses to continue, then the timer is reset, if no, then they get logged out. If they aren’t around to confirm anything, the app will automatically logout after 1 minute from displaying the message.

A while back, I released my spring security configuration for doing Spring Security with Active Directory. I have since made a few changes to my configuration that has simplified it and I also got the remember me functionality working. For those of you who don’t know, remember me is a way to tell the application to remember a user for a given length of time and expire when that time is up to make them relogin.

The remember me functionality came in real handy for us since we have so much Ajax going on. It was a pain for users when they would time out after 15 minutes and immediately get redirected to the login page. I also made my configuration utilize a database to store the saved user data instead of allowing it to create everything in a cookie on the user’s machine which is extremely un-secure. I use this technique in two applications. One of them uses an in-memory database mapped with hibernate and the other uses a physical Oracle database. In order to make the PersistentToken storage for Spring 3.0 work, you need to create a table. Below the configuration is a hibernate class you can use to automatically create the table for you. I mapped the table with hibernate so that I could create a screen that tracks all logged in users, when they logged in, etc. It also gives me the ability to play God and log people out just by deleting their user record.

Another reason I chose the Persistent token mechanism is that I couldn’t get the plain token mechanism to work.

Well enough of my chatter and let’s look at my updated Active Directory and LDAP configuration with Spring 3.0. Take note that this configuration is a hybrid configuration between namespace and bean configurations. The key elements to making this configuration sing are in bold.

<!–Used if access is denied to the application. errorPage = the page todisplay if access is denied.–><bean id="accessDeniedHandler"class=”org.springframework.security.web.access.AccessDeniedHandlerImpl”>

<!–LDAP Authentication Provider uses the bindAuthenticator andauthoritiesPopulator to authenticate the user and populate the userobject with roles based upon Active Directory groups.–><bean id="ldapAuthProvider"class=”org.springframework.security.ldap.authentication.LdapAuthenticationProvider”>

I almost forgot one important step. You need to pass the correct paramter when a user logs in to trigger the remember me. I use a hidden field, because we didn’t want users choosing the option. It will be automatic. Remember the parameter must be _spring_security_remember_me=on or it will not work. The following code is in the login form I use.

Also, don’t forget to provide a logout button somewhere or the user will never be able to log out until the cookie expires and the above configuration is for two weeks.

In earlier versions of Spring Security/Acegi, the UserDetails object contained a method called getAttributes(). This method would return the custom attributes assigned to a user. In the case of Active Directory, this contained all the little minutia about a user that a domain defines, a good example in my case was that it contained personal information about a user’s work location that I needed to access.

The getAttributes method was deprecated and removed in Spring 3.0, leaving no way to access these attributes. The documentation states that now in order to get at these attributes you need to define your own implementation of a UserDetailsMapper and populate your own implementation of a UserDetails object. I was really shocked that this functionality was completely removed, but I two good reasons I can think of is that the data is stored differently in other LDAP implementations and the attribute list could get quite large and since it gets carried around in memory and if you have several hundred users logging in…well you can see the memory problem.

I wrote my own implementation for this in hopes that it might help others. There isn’t any other implementation out there I could find so I was forced to write it from scratch.

There is some overlap here. I set mapAllAttributes to true in the xml, so it will place all of the LDAP attributes in the HashMap inside of UserDetails and I also could have set this to false and just mapped certains ones that I want to load instead of loading the entire list.

Now we need our new UserDetailsClass. This class is a carbon copy of LdapUserDetailsImpl with a few changes.

public ExtUserDetails createUserDetails() { Assert.notNull(instance, "Essence can only be used to create a single instance"); Assert.notNull(instance.username, "username must not be null"); Assert.notNull(instance.getDn(), "Distinguished name must not be null");

We just cast the UserDetails object back to our instance so we can access the values it is holding for us.

For my taste, this is too many steps to providing a UserDetails mapping strategy. spring needs a better mechanism or it at least needs to include my methods above as an option for folks to use. A default strategy is better than none at all.

By Chris L HardinSr. Software ArchitectHave you ever wanted to do away with the paging aspect of your grids. Chances are you have grid that have page and you click next and back and all that jazz, but I want to give you something better… a grid that populates data as you scroll along.

Let’s get right to the example using Dojo. First you need to create a Grid in your page.

Your going to need to define the layout of your grid using Dojo. This layout is simple. It only contains two columns.

We set Rows per page to 10, this means that after you scroll closer to the 10th row,Dojo needs to go back to the server to get more data.

Now we need to create a QueryReadStore to get our data. I amusing Spring to convert my objects to JSON and the object returned is always a QueryReadStore result that I define. Below is how the returned json looks and how I extended QueryReadStore to get the result properly. Note that the elements in the JSON data are required to be in this structure for the QueryReadStore to work property with the Grid.

Dojo will send the parameter of name=Bob to the server and also a start=0 and count=10. As you scroll, these parameters will get updated and resent until the total number of rows are loaded. Really cool eh?

Here are some final thoughts and concerns I have about this.

1. The Grid needs to work in reverse as well. This grid will continue to display rows until all are loaded in memory. It needs to remove older rows as you pass them and ifyou scroll back up, go back to the server an reget them. This should be done via some type of setting on the Grid or Store.

2. There needs to be some paramter on the store itself to tell the store what object contains the items, this way I wouldn’t need to extend QueryReadStore.

3. I would prefer that instead of post parameters,the QueryReadStore send pure JSON to the server inside of a single post parameter, but I couldn’t get that to work. The documentation states that this behavior is the default, but it didn’t work that way for me.

4. Pay particular note to

thisGrid.setStore(thisStore, query, {ignoreCase:false});

If you don’t call setStore on the grid this way, it will not send your paramters back to the server correctly the first time. It took me about 10 hours to figure this out. I read documentation, looked at the API and then went digging and I finally found an example where someone is doing it.

All in all, this is a great feature to have on your application, it saves a lot of trouble with paging. One thing that I do as well, it that I wrote a cache on the server side to handle all my data. The first call loads everything in the cache and as you scroll, you are getting data from the cache instead of some backend services. It really comes in handy if you are hitting a mainframe onthe back side as we are.

Extending existing components to make slight modifications to their behavior isn’t a very difficult concept, but often, it’s difficult to find good examples on how to get started, so today for Dojo week, we will look at a few short examples. If you have some examples of this you’d like to share, please comment them in or email them to me and I will post them and give you credit. Also, if you have a better way to do some of these examples, please submit those as well.

As you can see the structure of this is really simple, just name your component, list what component it extends and then override the events, methods you want to change the behavior of. It is that simple.

a good idea would be to use your own namespace for these extensions just to prevent namespace collision. let’s look at an example.

This time, I used a package prefix that is the same as the prefix I use in my Java Source code. This will prevent any possible naming collision that might occur with an existing component that might be lurking somewhere. Dojo’s require method will also help you to prevent such problems. Only import the widgets you need.

d.require(“dijit.form.ValidationTextBox”); //Works just like a Java Import

Has anyone noticed how the Dojo framework seems to be slipping to a “not so happy place” lately? Dojo is a powerful Ajax framework full of features and it is totally free. I’ve used it on two projects over the past 4 years and I have been pleased with the results. What I have not been pleased with is the direction the Dojo support community is headed, the volatile nature of the codebase, lack of working examples and very poor documentation.

Dojo support has been reduced to a primitive mailing list that is almost useless and a hidden forum that the developers of Dojo seem reluctant to use. If you post a question to the mailing list, there is a one in ten shot that someone will actually answer it and you’re chances are slightly better than that the answer you get will be helpful. If you are looking for a working example of how to do something, good luck, the web is full of examples, but most pre-date the latest versions of Dojo and it takes some work to get them going. The Book of Dojo and API documentation are pretty crude, incomplete and in some cases are just plain wrong. The API search is case sensitive as well, so you better know exactly how the object you are looking for is spelled. Good example, I typed in DropDownSelect earlier and it didn’t find it, but I know it is there.

Another issue with Dojo is that the developers don’t care much for backward compatibility. Refactoring is a good thing, but when you keep changing the API interfaces on every dot release, you are creating unnecessary work when your users attempt to upgrade. I’ve upgraded 3 times in 3 years and each time, I had to change code.

A good example of this is in the recent release. The release was changed so that by default text(HTML) in a grid cell is escaped. I upgraded and it broke all of my grids. In a bug report I read they changed it to prevent newcomers from having problems with grids due to errors in data interpretation in grids. It also mentions there is a parameter to switch this behavior on and off, but it is not released. This kind of non-backward compatible code can completely turn someone off wanting to continue to use the framework. It ticked me off something fierce. This isn’t an isolated incident either, there are many other examples of rogue development making the framework extremely volatile.

The problem with Dojo examples on the Web is that there has been so many changes to the codebase for Dojo that you have a 1 in 4 shot of getting a correct example. Say you have a particular issue you need to solve, for example, I needed to remove the ability to type into the FilteringSelectBox and make it act more like a true HTML Select Box, but still retain the look and I couldn’t find an option in the code or an working example, I did however find another person who was frustrated with the omission of the ability of allowing the user to input data into the Select box. Going back to the examples being correct, if you take into account the constant refactoring that the programmers are doing with Dojo when looking at examples, the examples you find are going to be based on one of 4 versions of Dojo and for the most part, you just have to try them to see if they work. You’ll get no apologies from Dojo developers when something is completely changed out from under you either.

Another issue is the options for a component. The Dojo documentation and API is very poor at laying out all of the options. Developers need to know what all the methods, events and properties for a component are. If you go look at the Ext documentation, they really have their stuff together. I rarely ever had a problem with their documentation. It is top notch.

I love the Dojo framework, but were are on the verge of a revolution here. The time is ripe for another open source framework to pull ahead of the game. It’s not Extjs thanks to the new stricter licensing scheme some bonehead decided to implement either. I guess I could always embrace Google Web Toolkit or YUI, or maybe just go back to Prototype and Scriptaculous. I’ve used Dojo with Prototype and Scriptaculous all in the same project before, but I just wasn’t using it to it’s full potential.

I just hate to see Dojo fall by the wayside due to a lack of proper support. The first few examples that a person writes in a framework usually determine how they will respond to that framework and whether they will accept it or not. If Dojo had the documentation and forum that Ext does, I could gurantee Dojo would be the most popular Ajax framework around, but alas, we are reduced to a pathetic mailing list. The Dojo forum is hidden and can’t be found easily and when you do find it, you can’t locate anything in it.

I have another issue with the Dojo mailing list. You have about a 1 in 10 shot of getting answer from it and generally that takes days. I noticed a few weeks ago as a user left the mailing list, he first left a scathing email about how it was useless, this generated conversations from almost 50 people, but post a message about a problem you have or a particular thing you are trying to do with the framework and you have a 1 in 10 shot of getting a single individual reply and then the answer may be totally off.

As an experiment, I posted an email proclaiming my dissatisfaction with the mailing list and in the email I mentioned that many people would reply to it, but if it was a technical issue, almost no one would reply. Sure, enough 4 hours later, over 30 people had chimed in to either agree with me or vehemently disagree with me about the viability of the mailing list. I even had one little man tell me to “piss off” and if I didn’t like Dojo, then don’t use it. Another guy told me that all the developers are volunteers so we shouldn’t criticize the support methodologies. I responded simply, “Most firefighters are volunteers as well, but they wouldn’t last very long in the court of public opinion if they only responded to 1 out of every 10 calls for help.”

The experiment proved my point. Even though I love Dojo, several of the members of the mailing list took it personal as if I was insulting their religion or something. Hello, I just said I love Dojo…I only have a problem with the support community.

I’ll give you a great example of how difficult it is to find out how to do something in Dojo. I spent four hours last night trying to find a way to highlight rows in a Dojo grid and make it work. I hit the mailing list with this question last week and someone responded with how to highlight a column. I wanted to highlight the entire row. I appreciated that he responded, but his answer wasn’t close enough to the problem to be of any use.

Last night I quested to find and implement how this should work and I finally found someone who was doing it and it worked. It was really a very simple task that should have been easy to find. if it takes 4 hours to find a method to complete such a simple task, most folks would tend to steer clear of the framework all together.

Of course most of you are going to say, “why didn’t you just write it yourself, instead of taking 4 hours to find an example.” I take a very pragmatic approach to this. I do not reinvent the wheel. If someone out there is already doing it and I find a working example, then I would rather do that and same myself the time if I can. A lot of times common examples make their way into the framework itself anyway. A lot of times, I do however write my write out of these situations and resubmit the method to the framework itself and it makes it in.

My point to all of this is that I really like using Dojo and I want it to survive. I’ll even help and volunteer to assist in completing a cookbook and some better documentation if that is what it takes. We also need to get a good community forum going again.

Let’s get involved, but someone involved with the Dojo development needs to get on the mailing list and start answering questions or get us started by creating the forum and inviting people to get involved. A unified, centralized documentation effort is in order here. Get the codebase stable, document the heck out of it, post tons of examples based on the release and clean the Dojo sites and the Web of the old examples based on the old codebases. A Dojo cookbook based on the a late stable release would be great. I’ll even volunteer to write it if Oreilly doesn’t already have someone on it. I would really like to see Dojo be the king of the mountain in the framework wars.

NOTE to DOJO Developers and Zealots: My point of view is an opinion and not necessarily fact. The fact is that I use Dojo, I want to continue using it. Criticisms are a part of life. Personal comments about me will not be published as comments. Comments presenting a pleasant tone and providing sound arguments will be published. Comments degrading anyone who does not share your point of view will not. If I reject your comment, please review it for tone and resubmit and I will be happy to publish your views. Thanks.