May 5 2009

New jQuery Weekly Calendar Plugin

rob

After being inspired by the recent fullcalendar (month based) plugin by Adam Shaw, I decided to port a weekly calendar i’ve been working on into a proper jquery plugin. Until a couple of days ago it was practically impossible to use this calendar functionality outside of it’s host application but now it should be simple to integrate it into any jquery-ui based application.

I made a conscious decision to base the week calendar api off the fullcalendar plugin, using the same event names where it makes sense and most importantly to use an identical data format. The idea being that the two plugins could co-exist utilising an identical data source and similar programming style.

You can see the full details of the plugin on the project page but to summarise the feature set:

  • Display of calendar events within a weekly grid
  • Calendar events can be supplied as an array, url or function returning json
  • Calendar events can be dragged, dropped and resized
  • Lots of callbacks for customizing the way events are rendered plus callbacks for drag, drop, resize, mouseover, click etc
  • Automatically scrolls to current time
  • Extend the core calendar event data structure with your own data
  • Compatible with FullCalendar data sources with very similar events
jquery week calendar

jquery week calendar

At this stage there is only a basic demo in place but when time permits i’ll add a series of demos that help to show how you might extend it to fit your application requirements such as:

  • Modification of rendered events based on custom data / logic
  • Using jquery ui dialog for creating and editing events
  • Using some of the other events to provide a better experience

This plugin is an early release and i’d expect follow up revisions to be coming out very soon. Any feedback, bug reports etc would be welcome.

Check out the full documentation and demo here


May 3 2009

Evolve The Future – Evolution in Javascript

Jonathan

Evolve The Future is a “proof of concept” evolution simulator inspired by Thomas Ray’s Tierra application, which he always promised would be a networked environment for digital wildlife. I haven’t created that, but hopefully this is a step in that direction. Little animals run around, reproduce and eat each other. Each animal is written in a custom assembly-code language running on a number of virtual machines. and all of this is written in Javascript.

I wrote this application a couple of years ago, and kind of forgot about it. But now I have dusted it off, ported it to the Google App Engine and updated it a little bit here and there. I am continuing to work on it, new features (like the ability to look around) will be added soon.

Because javascript isn’t really fast enough (yet) to get enough generations through for evolution to be a useful force before my attention span wanes, this is possibly more of an environment to test your skills in writing in assembly code, and competing against the rest of the assembly-code writing world for the title of … (I’ll think of something :-)   ).

The instruction set is not documented yet, and the animals structure is not documented yet (but both of these soon will be.

Each animal (process) has the following properties

  • Memory: This is both readable and writable memory addresses starting from address 0 for each animal.
  • Threads: Each animal can have multiple threads that communicate via it’s memory.
  • CpuTime: Each animal is granted cputime by it’s parent when it is born, and after that is given cputime by the environment (like sunshine) each cycle.
  • Position: Each animal has a current (xy) position in the grid
  • Direction: Each animal is pointing in a certain direction (this is not currently shown in the display.

Each thread in each animal has the following properties:

  • Stack: this is essentially current memory. Operations can put information on the stack, manipulate the top item on the stack, or pop information off the stack.
  • Execution Pointer: Each thread is executing the same program, but potentially at a different address (different function) in memory.
  • Read Pointer and Write Pointer: These are used for copying operations.
  • Memory Pointer: This is used for writing operands only.
  • Speed: An animal can choose to operate faster, multiple operations per second. This is expensive for the animal.
  • SleepCycles: The thread can sleep for a set number of cycles. It will be woken when this counter reaches 0.

There have so far been two Ancestors created:

  1. A simple non-mobile vegetable. This has a single thread that is devoted to reproduction.
    Once all 8 slots around the animal are full, it sleeps for a period and then checks again.
  2. A simple mobile vegetable (is this a vegetable??). This has two threads: one is devoted to reproduction, the other moves in a straight line forever.
    When it reproduces, it turns right.

Animals reproduce by allocating memory at the end of their memory, then copying code into the new memory, and then dividing the new memory. This creates a new process.
The copying process has a 1 in 1000 random chance of failing to accurately copy the data requested. This results in the child not always being the same as the parent, and the chance for evolution is created.
Successful species (when a species has had enough animals with the same code, occurs at powers of 10) are sent to the server.
When the application starts it requests the 10 best animals from the server.
Things you can do:

  • Click on an individual to see information about it on the “Process Details” tab
  • View code of species on server to see what has evolved from the “Progenitors”
  • Insert new species into the environment
  • Examine the code of any running animal
  • Send me patches!!

Apr 12 2009

Unwanted IE7 Horizontal Scrollbar

rob

I came across an interesting bug today with IE7. Actually, no not interesting, frustrating is a better word to describe it. I had a random appearance of a horizontal scrollbar within a div that has a fixed height set in javascript and overflow auto to achieve a viewport style interface.  The correct  behaviour, the one exhibited in all other browsers, was to add a vertical scrollbar to the fixed height div and not to add a horizontal scrollbar. What IE7 appeared to be doing was not compensating for the vertical scrollbar and adding a horizontal scrollbar with a scroll amount of the vertical scrollbar width.

IE7 horizontal scrollbar being forced by width of vertical scrollbar

IE7 horizontal scrollbar being forced by width of vertical scrollbar

Following ?

Ok, now some searching on the web came up with a lot of mentions of this kind of behaviour in different forms and the common fix seems to be using the following css attributes:

overflow-x: hidden;
overflow-y: auto;

Unfortunately for me this didn’t work. I tried all sorts of variations like forcing widths and a whole bunch of irrational, voodoo style css attributes in the hope that i’d happen across the right combination that would slap IE into submission. Nothing!

Some other behaviour that i’d been thinking was odd but hadn’t given lot of thought to yet was:

  1. Scrolling the scrollbar to the right would cause it to disappear.
  2. Elements such as text, fields etc that appeared underneath the scrollbar showed through
underying elements showing through scrollbar

underlying elements showing through scrollbar

I tried using javascript to simulate a scroll to the right on load – something that made me cringe but it was worth a try. No luck still.

Finally, it occurred to me that the answer could be in the second of the observations described above. Ahaaaa! What if I give the element with the desired vertical scrolling a background color. Given that the elements within the scrollable dive are showing through, maybe giving the element a background color would show through as well and effectively hide the scrollbar. At that stage the element background was transparent so if I give it a white background which is was gaining from an underlying parent element that should cover this rogue scrollbar.  And that was that, the scrollbar is gone.

I immediately tried to describe my frustrations to my girlfriend of one more day of my life being wasted due to Internet Explorer and was somewhat unsatisfied with her lack of understanding.  I’m not sure what i’d expected from her but she definitely appeared to be more interested in the interview with Viggo Mortensen on the television – who’d have guessed!!


Mar 28 2009

Simple Object Assembler

rob

Going back a few years, it took a little while for me to realise the benefits of providing a clean separation of the core business domain from any consuming client, be it a web ui or remote service. I guess I always saw it as a lot of work (which it can be) and the simpler apps I was writing didn’t seem to need it – or at least I couldn’t really see the benefit at the time. While exposing dtos to the outside world is not necessarily a better option in all cases (many modern app frameworks offer rapid development because they don’t do this), i’ve found that erring on the side of caution in most of my development has set me up for a better experience as an application grows, allowing me to develop my domain without worry about how it might be used externally. This approach also has a nice side effect of allowing me to develop from the outside in, giving me exactly what I want in a web client and exactly what I want in my domain… often these are a little different.

I’ve used a few different techniques for converting domain objects to dtos and back again and it’s always turned out to be an ugly part of the application. I gave Dozer a go for a while and while it’s very capable, I found that once you have nested object graphs that need selective conversion for different scenarios, it became more and more difficult to follow, with more chance of things happening that you don’t want. Also having the mapping rules defined in xml, there were too many places to check for any different scenario. It’s been a while since I used Dozer and it’s quite possible that any statements I make about the way it works may be wrong so i’ll just say that it had some things a while back that lead me away from it and I haven’t gone back for another look since. So after trying Dozer out and not being entirely happy, I went back to having a pair of domain / dto assemblers that had dedicated methods for converting one object to another.

For example:

public class DomainAssembler {

public User assembleNewUser(NewUserRequest newUserRequest) {
//… manually convert objects here.
}

}

As you can imagine, this class will get large very quickly so you’ll want to break it down. Depending on the application, it might not be clear where or how much and what the deciding factor is. If you’re using course grained services, maybe separating assemblers on a per-service basis is the way to go. The thing with that is that you end up with lots of inter-dependencies between service based assemblers that is also hard to manage. The worst thing is that you also end up with lots of special methods for converting different parts of a graph. Clear naming is something I always find difficult, probably because I place a lot of importance on it.

So for example, this assembler has a three different methods for returning a different view of a user:

public class DtoAssembler {

public UserDto assemblerBasicUser(User user) {
//… manually convert objects here.
}

public UserDto assemblerUserWithProjects(User user) {
//… manually convert objects here.
}

public UserDto assemblerUserWithProjectsAndTasks(User user) {
//… manually convert objects here.
}

}

Depending on your application, this may or may not be a problem but you can see where it’s going. Anyway, this all bothered me a bit so I started writing something that has helped to simplify things for me a little on a couple of apps. There were a few basic requirements that I wanted to be able to satisfy and some assumptions about the environment that it would exist within. These included:

  • Runs in a Spring 2.5.x based application and it’s ok to have a dependency on this but try to avoid if possible.
  • Likely to be a Hibernate / JPA based application but again don’t tie to the Hibernate API if at all possible.
  • Utilise Convention Over Configuration where possible but don’t impose it.
    • Fields of same names are mapped automatically
    • Fields of same name but different types can be mapped by registering converters for the combination. It’s recursive.
    • Fields of different names can be mapped by explicit configuration
    • Fields to be ignored can be configured
    • Any details about how much of an object graph should be populated must be configurable at runtime
  • Can be completely overridden if necessary or at different stages in the conversion cycle.
  • Configuration information is not defined in xml and is as close to the code that uses it as possible. This being a differentiator from Dozer.
  • Should be able to detect problems in configuration such as mistyped property names.
  • Destination objects should be able to be constructed in any way required but if not defined should be done reflectively.
  • Should be capable of handling conversion of objects proxied by hibernate or JPA.
  • Can handle mapping of collections, using existing objects within the destination collection when it makes sense for integrity or performance reasons.
  • Can handle circular relationships
  • Should use direct field access to negate the need for getters and setters simply for object conversion

Object Assembly / Conversion

The object assembler is the entry point to object conversion. It maintains a registry of ObjectConverters that are written by the application developer to convert one object to another. The registry enables a single converter to exist for one type to another.

You generally call the object assembler like this:

DestinationObject destinationObject objectAssembler.assemble(sourceObject, DestinationClass.class);

This will look up it’s registry for a converter with the same source / destination combination. A converter in it’s simplest form might look something like this:

public class SourceToDestinationTestObjectConverter extends    AbstractObjectConverter<SourceObject, DestinationObject> {

public Class<DestinationObject> getDestinationObjectClass() {
return DestinationObject.class;
}

public Class<SourceObject> getSourceObjectClass() {
return SourceObject.class;
}

}

You’ll notice that this converter extends the AbstractObjectConverter which has most of the conversion logic. The end result of calling this converter via the assembler as shown above is that all properties of the same name will be converted from the source to destination object. If two properties with the same name but different types are encountered, the registry will be consulted and the assembler will recursively call itself until all properties are converted.


Selective Conversion

If you want to exclude any part of the object graph from automatically being converted, you can do so in three ways.

  1. By overriding the ‘disableAutoMapping()’ method on your converter implementation and returning ‘true’
  2. By overriding the ‘alwaysIgnoreProperties()’ method on your converter and returning a Set of field names to never convert
  3. By passing an array or var-args of property names to ignore into the assembler

The first two approaches are useful when you want this behaviour for every invocation of the converter but if you want to be able to specify what to convert upon invocation, the third approach is much more flexible.

Example:

DestinationObject destinationObject objectAssembler.assemble(sourceObject, DestinationClass.class, “ignoreFieldA”, “ignoreFieldB”);

The ignore field paths are aware of nested object graphs so it’s possible to ignore any part of the graph, no matter how deep.

DestinationObject destinationObject objectAssembler.assemble(sourceObject, DestinationClass.class, “ignoreCollection.fieldA”, “ignoreFieldB.fieldValue”);

This approach is very similar to web field binding except that collections are not indexed. This means that while you can refer to a field of an object within a collection, it will always apply to all objects in the collection, not a single one. For example you cannot specify ‘ignoreCollection[0].fieldName’ to ignore only the ‘fieldName’ property of the first element in the ignoreCollection. I can’t think of a situation where this would be that useful. Having said that, adding this capability would be reasonably straight forward.

Wildcard Exclusions

There are times when you want to convert an object that is a property of another but not actually convert any of it’s properties. Say for example, you want to look up a staff member’s manager from the database and populate the manager field in the staff member but you don’t want to actually map any of the ManagerDto fields onto the Manager object from the database. In this case you can use a wildcard in your ignorePath.

StaffMember staffMember objectAssembler.assemble(staffMemberDto, StaffMember.class, “manager.*”);

Mapping fields with different names

Sometimes your source and destination objects don’t have the same names. In this case, it’s possible to define pairs of ’source > destination’ names for mapping. This is done at the converter level by overriding the ‘customConverterFieldMappings()’ method. This method should return a Set of ConverterFieldMappings.

Configuration Validation

It’s easy to mistype a property name so you’ll want some checking to make sure your property names actually exist. Due to the way converters are registered, this can’t be done at startup time yet (hopefully it will soon). It can be done on first execution though so it’s easy to pick this up as part of your test suite. Any fields marked to ignore or fields mapped that don’t exist will result in an exception with a clear indication as to the source of the problem.

Constructing your own Destination Object

The default behaviour is for the converter to attempt to construct a destination object based on it’s destination type. This requires your destination object to have a default no-arg constructor. If you want to be able to construct your own object you can do this by overriding the createDestinationObject(SourceObject sourceObject) method. Because the sourceObject is passed into this method it’s entirely possible to manually do some conversion in here but it’s not the intended place and it’s possible that your values will be overridden during the actual conversion which happens next so it’s not advised. There is a method for this which i’ll come to. This is however a good place to do things like retrieve an object from the database based on the id of the source object. This is certainly the most common case.

Example of a Converter with the createDestinationObject method being used.

@Component
public class UserDtoToUserConverter extends AbstractObjectConverter<UserDto, User> {

private UserDao userDao;

@Autowired
public UserDtoToUserConverter(UserDao userDao) {
super();
this.userDao = userDao;
}

@Override
public User createDestinationObject(UserDto userDto) {
if (userDto.getId() == null) {
return new User();
} else {
return userDao.findById(userDto.getId());
}
}

public Class<UserDto> getSourceObjectClass() {
return UserDto.class;
}

public Class<User> getDestinationObjectClass() {
return User.class;
}

}


Custom Conversion Logic

There are cases where you need to perform some custom conversion logic because it’s not simple enough to just map one field to another. In this case you can override the convert(SourceObject sourceObject, DestinationObject destinationObject) method. This is called after all auto conversion has been performed and enables any custom conversion to be done. If you wanted to perform a full custom conversion for a converter you simply override disableAutoMapping() to return true and write your custom logic here.

Conclusion

This is not a perfect solution and it certainly won’t make sense in all situations. Some people, justifiably will take issue with the idea of passing strings of property fields to ignore / exclude into the assembler. I find this a bit awkward myself however i’m not sure that it’s really all that different to putting it outside in an xml file. I feel this line is starting to be crossed with some implementations of annotations vs their xml configuration approaches. Sure, it’s compiled code, but it’s also a lot more visible at the point at which it matters so there are some clarity benefits there. It would also be possible to externalise this configuration as an option but the more that’s done, the closer we get to Dozer which undeniably has a much deeper feature set and is almost certainly much ’smarter’ under the hood with the benefit of years in the wild. The intention for this was a simple solution to a simple mapping problem, sitting halfway between dozer and a fully handwritten approach. I came across an interesting post the other day by Gavin King, talking about the new typesafe Criteria API for JPA 2.0. I’ve been pondering whether one of the features they are using from the Java 6 compiler plugin architecture might be useful here although introducing yet another annotation could become a bit of a bore!

Another potential problem comes about when new properties are introduced to objects that are already mapped. It’s possible that an introduced relationship with another large part of the object graph could go unnoticed and result in conversion of much larger sets of objects than originally intended. I guess this is a trade off of taking blacklist vs whitelist approach for property mapping.

Get the Code

I’ve published the code on google code. At this point it’s not packaged up so you’ll have to check it out and build it from the source.  It’s a maven project though so this will be trivial as long as you’re familiar with maven.


Feb 25 2009

Integrating Spring Security with BlazeDS and Flex RIAs

adam

I have found a couple of tutorials on this lying around the web, however they all take slightly different approaches, and although the information was useful, I think there is a cleaner way to do the integration. Keeping in mind of course that now that the spring guys have released the spring-flex module there will hopefully be complete integration with Spring Security soon without the need to even wire it up the way I describe here.

What I am going to describe here uses:

  • Spring 2.5.5
  • Spring-Security 2.0.4 (core & tiger)
  • BlazeDS 3.2
  • Flex3

My approach is not to protect end-points using BlazeDs’s security. The reason is that I often expose my services as web services as well as AMF endpoints and I don’t want to create my security mappings twice. Instead I use method invocation based security and protect the services directly. All that BlazeDS needs to do is get the users credentials out of the request and delegate to SpingSecurity to create a SecureContext, authenticate and put the authentication object in the SecureContext (effectively thread local). After that normal Spring Security applies and secure methods will be protected in the normal way.

A typical security scenario in one of my applications goes something like this: Either none of the application or a small part of the application is available anonymously as is the login service. Users access them without credentials, usually the User doesn’t even have menu options to navigate to UI areas with secure functions until they have logged in. After a successful login I will cache the user’s credentials on the client and re-log them in on each service request. This keeps the server completely stateless, all state is stored on the client. I configure a lightweight cache on the server since if someone logs in once they will likely make many more login requests (one for every service they are going to use). This reduces database hits. I implement a service registry on the client which stores the credentials and automatically adds them to all RemoteObjects and HttpServices.

I’m going to work this assuming that you already have a Flex/BlazeDS/Spring application going. It can be as simple as hello world, there is an excellent article on how to do this using the new spring-flex solution here . The way that i am applying security means that it is largely irrelevent whether you are using the Adobe SpringFactory or the spring-flex MessageBrokerHandlerAdapter.

Step1. Add spring-security to your web application’s lib my pom entry looks like this:

<dependency>

   <groupId>org.springframework.security</groupId>

   <artifactId>spring-security-core</artifactId>

   <version>2.0.4</version>

   </dependency>

<dependency>

<groupId>org.springframework.security</groupId>

<artifactId>spring-security-core-tiger</artifactId>

<version>2.0.4</version>

</dependency>

   </dependencies>

Step2. Add the spring security filter to your web.xml

<filter>

<filter-name>springSecurityFilterChain</filter-name>

<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>

</filter>

<filter-mapping>

<filter-name>springSecurityFilterChain</filter-name>

<url-pattern>/data/messagebroker/*</url-pattern>

</filter-mapping>

This will secure everything and is mostly necessary if you are going to use other transports than just AMF via BlazeDS.
Step3. Configure Spring Security. I am just going to put a very basic config here. For details on configuring spring security you can look at the spring security documentation here

<security:http auto-config=“true”>

<security:intercept-url pattern=“/**” filters=“none”/>

</security:http>

<security:global-method-security>

<security:protect-pointcut

expression=“execution(* net.oneadam.app.services.*Manager.*(..))”

access=“ROLE_ADMIN”/>

</security:global-method-security>

<authentication-provider>

   <user-service>

<user name=”adam” password=”adamspassword” authorities=”ROLE_USER, ROLE_ADMIN” />

   <user name=”bob” password=”bobspassword” authorities=”ROLE_USER” />

   </user-service>

  </authentication-provider>

This configuration passes everything through at the URL level and relies on method level security. I have used pointcuts here since it doesn’t require me to cut and paste classes and methods in order to demonstrate how annotations work. The above pointcut requires the user for all methods in any class ending in the word Manager in the services package to have the role ROLE_ADMIN.
Step4. Implement the flex.messaging.security.LoginCommand Interface so that the doAuthentication creates a UsernamePasswordAuthenticationToken and authenticates using Spring Security, if it is successful it should put the authentication object into the SecureContext where it will be accessible to your application and the Spring Security annotations or security pointcuts. here is my implementation:

package net.oneadam.web.security;

import java.security.Principal;

import java.util.List;

import java.util.Map;

import javax.servlet.ServletConfig;

import javax.servlet.http.HttpServletRequest;

import org.apache.commons.logging.Log;

import org.apache.commons.logging.LogFactory;

import org.springframework.context.ApplicationContext;

import org.springframework.security.AbstractAuthenticationManager;

import org.springframework.security.Authentication;

import org.springframework.security.context.SecurityContextHolder;

import org.springframework.security.providers.AbstractAuthenticationToken;

import org.springframework.security.providers.UsernamePasswordAuthenticationToken;

import org.springframework.web.context.support.WebApplicationContextUtils;

import flex.messaging.FlexContext;

import flex.messaging.io.MessageIOConstants;

import flex.messaging.security.LoginCommand;

public class SpringSecurityLoginCommand implements LoginCommand {

   private static final Log LOG = LogFactory.getLog(SpringSecurityLoginCommand.class);

   private AbstractAuthenticationManager authenticationManager;

   public Principal doAuthentication(String username, Object credentials) {

String password = extractPassword(credentials);

if (password == null) {

   return null;

}

  

if(authenticationManager == null) {

   init();

}

Authentication auth = new UsernamePasswordAuthenticationToken(username, password);

try {

   SecurityContextHolder.getContext().setAuthentication(authenticationManager.authenticate(auth));

   LOG.info(“User [" + username + "] logged in.”);

   return (AbstractAuthenticationToken) SecurityContextHolder.getContext().getAuthentication();

}

catch (RuntimeException e) {

   LOG.info(“User [" + username + "] failed authentication.”);

   throw e;

}

   }

   /**

* We are not going to perform Authorization at this level since we would like SpringSecurity

* to manage Authorization at the method level.

*/

   @SuppressWarnings(“unchecked”)

   public boolean doAuthorization(Principal principal, List roles) {

return true;

   }

   public boolean logout(Principal principal) {

HttpServletRequest request = FlexContext.getHttpRequest();

if (request != null && request.getSession(false) != null) {

   try {

request.getSession().invalidate();

   }

   catch (IllegalStateException e) {

// Expected.

   }

}

request.getSession(true); // Session re-created to avoid Flex error when

// it also attempts to invalidate the session.

LOG.info(“User [" + principal.getName() + "] logged out.”);

return true;

   }

   public void start(ServletConfig config) {

//My tests show this never gets called

   }

   public void stop() {

authenticationManager = null;

   }

   @SuppressWarnings(“unchecked”)

   protected String extractPassword(Object credentials)

   {

   String password = null;

   if (credentials instanceof String)

   {

   password = (String)credentials;

   }

   else if (credentials instanceof Map)

   {

   password = (String)((Map)credentials).get(MessageIOConstants.SECURITY_CREDENTIALS);

   }

   return password;

   }

   private void init() {

HttpServletRequest request = FlexContext.getHttpRequest();

ApplicationContext ctx =

   WebApplicationContextUtils.getWebApplicationContext(request.getSession().getServletContext());

authenticationManager = (AbstractAuthenticationManager) ctx.getBean(“_authenticationManager”);

   }

}

You will notice that the doAuthentication method just returns true. That is because I am not interested in securing BlazeDS destinations. I prefer to secure the service facade methods themselves, that way if I expose them using CXF or some other Web Service transport my security does not have to be redone.
Step5. Wire up security in the services-config.xml file to use your SpringSecurityLoginCommand it will look something like this:

<security>

<login-command class=“com.renewtek.cmf.web.security.SpringSecurityLoginCommand” server=“Tomcat”>

   <per-client-authentication>true</per-client-authentication>

</login-command>

<security-constraint id=“roleuser”>

   <auth-method>Custom</auth-method>

   <roles>

<role>ROLE_USER</role>

<role>ROLE_ADMIN</role>

   </roles>

</security-constraint>

   </security>

The roles are actually unnecessary since I return true from all authorization requests at this level. I have just left them in for completeness. If you wanted to reject a request at this level that is where you would put the roles and if you are using the Adobe style of defining destinations in your remoting-config.xml file then you could say what destinations are allowed for what roles. What is important to the strategy I described above is the per-client-authentication entry. it needs to be set to true since we don’t want to use server based sessions. it is false by default.


Jan 29 2009

javascript closures are fun

Jonathan

I really like closures in javascript. I really miss them when I am doing work in Java,  but sometimes when I use them I get a little messed up. Take the following example:

var i;
var objects=[1,2];
for (i=0;i < objects.length;i++) {
    var callback=function() {
        console.log(objects[i]);
    };
    doSomethingAsynchronous(callback);
}

Then you would might expect “1″ and “2″ to be logged when the callbacks come back. This is wrong, instead “2″ and “2″ are logged.

Due to the nature of closures, “i” is one of variables that fall into the scope of the closure by reference, not by value. So, when the value of “i” is updated in the for loop, the current (latest) value is then referenced later on by the closures. So the last item in the list is the item that is accessed.

The way to get around this is to modify the above code slightly, to make the item that you want an argument of a function, rather than accessed through closure scope. Eg:

var i;
var objects=[1,2];
function doSomethingAsynchronousAndLogIt(value) {
    var callback=function() {
        console.log(value);
    };
    doSomethingAsynchronous(callback)
}
for (i=0;i < objects.length;i++) {
    doSomethingAsynchronousAndLogIt(objects[i]);
}

Jan 24 2009

a new version of mooleer is available

Jonathan

A new version of mooleer is available.

If you know others that would be interested in using mooleer, please send them along to register their interest. I will be slowly increasing the number of users and will send invitations in order of when they register.

I have listened to your feedback and have implemented some of it, have prioritised some of it to be done later and would like feedback on some more (I ignored very little :) ). The items that have been done, and prioritised for later are not listed below, only the items that I am not sure of are listed.

I see merit in the following items, but am not sure about how important they are to people actually using mooleer. Can you please respond with a score next to each item (from 0 to 10, with 10 being the most important), indicating how important you think each item is. If you don’t understand an item, please don’t score it. If you think something is dumb, and absolutely shouldn’t be done, then give it a 0.

  • have more help on the transaction form
  • the frequency slider needs to better show when monthly/yearly values start
  • Recurring transactions by default start from “today” and go forever if the “to” date field is left blank. Is this clear enough? or could it be made clearer by adding “today” and “forever” options to dates for recurring transactions.
  • User input should be autosaved (ie get rid of the Save and Cancel buttons). To me it feels more natural that way. The app is very interactive and I as user was lulled into thinking that the app autosaves but it doesn’t. I forgot to save and simply hit “Add Expense” to add another entry and I ended up losing my unsaved input :-)
  • I know you have tried to make it as minimalist as possible but personally I find all the grey a bit drab, it could do with a bit of polish and some subtle colours.
  • Only (Add Income) button should appear on [in] tab, only (Add expense) button should appear on [Out] tab

Please keep up the feedback if there is something that is bothering you (or that you love).


Jan 24 2009

Currying in javascript

Jonathan

I read an example chapter from Professional JavaScript for Web Developers, 2nd Edition: Chapter 18, “Advanced Techniques” last week and the discussion about currying functions finally made sense to me as in “oh, I see how I would use that”. If you want to understand it better look at the chapter linked above.

I have been using it for callback functions that require extra arguments from the local scope, it is a lot less wordy than the method that I had been using, and I think it better conveys the meaning of what I am trying to do.

Previously I would put the following:

var someValue;
$("#someElement").click(function(e){
    clickHandler(someValue);
});

And now I put this:

var someValue;
$("#someElement").click(clickHandler.curry(someValue));

I implemented this using a method that I placed on the Function.prototype. I think that is a nicer syntax than is recommended in the book.

Function.prototype.curry = function(){
      var args = Array.prototype.slice.call(arguments);
      var fn = this;
      return function(){
          var innerArgs = Array.prototype.slice.call(arguments);
          var finalArgs = args.concat(innerArgs);
          return fn.apply(null, finalArgs);
     };
}

Jan 9 2009

Optimistic Locking with JPA, Flex & BlazeDS

adam

Optimistic locking in JPA relies on a version field which can be a number or a date of some type. Using date objects can be problematic if they are not detailed enough. For example a date which does not persist at least milliseconds is likely not to be accurate enough to do versioning. I generally use a Long since it is going to survive a very long time indeed, even in a high transaction system. The version filed is identified using the @Version annotation and when an object containing a version field is updated JPA will read up the version number in the database before attempting to do the update and if the version numbers do not match then it will throw an OptimisticLockException. It is a good practice to make the version field private and not to provide getters and setters. it is critical that the field not be altered except by the JPA implementation.

Ok, so far so good, we implement this strategy on systems where we have a greater proportion of reads to writes and we would like data to be highly available. Basically a user can always get a read, no matter what, however if they want to do a write we will check that the object they are modifying has not been written to since they read it. Very many web based application use this strategy today and as I described above it is supported out of the box with JPA. Of course there are endless arguments about how you manage the OptimisticLockException, but that is a separate issue.

When your web application is using DTOs or some other representation of the system data which is not your actual domain another level of complexity enters the frame. If the DTOs don’t carry the version field with them and re-present it for the update then the whole optimistic lock strategy is dead in the water. If the web tier represents an object without keeping the version field then when it the user requests to update the domain, JPA must retrieve it again, over-write the fields provided and then perform the update. Of course if someone had changed the data between the user’s read and write, that would be over-written.

So we have established that maintaining the version field into the web tier is critical. We already established that the version field should not be user modifiable so it would be good to make the version field in the DTOs private as well. If you are hand mapping between DTOs and your domain then you will need to use reflection to map this field across. I generally user dozer and it allows you to set is-accessible=”true” in a field description which tells it to access this field directly without using the getter and setter.

When you add Flex and BlazeDS to the picture (and of course that means an ActionScript domain) you add a whole new level of complexity and at this point a real problem arises. Of course BlazeDS will auto-magically transform your Java DTOs into your ActionScript domain and perform all transport in AMF3. Thats peachy, but unfortunately it does not transport private fields without getters or setters. That means that although your version field gets mapped onto the DTO when it arrives on the Flex client, it is gone.

Well that just won’t do, we already established that without the version field we have no locking strategy at all. Currently my only work around is to provide getters and setters on the DTOs. This ensures that they make the trip to the client and back but it risks the client accidentally altering them and inadvertently causing an OptimisticLockException. I’m a little unhappy with this and intend to spend a little bit of time with the BlazeDS source code to see if there is something that can be done to allow private field mapping. If you are interested stay tuned or feel free to post your ideas as comments here.


Jan 8 2009

M2Eclipse and WTP

adam

WTP and M2Eclipse do not play very nicely together. We have identified 2 main problems:

  1. Converting Maven projects to WTP projects so that they can be auto-deployed to the servlet container.
  2. Multi-modules projects where the web project has dependencies on one or more of the other modules and you want to be able to debug freely into any module. In this case if you allow a project per module, the other modules never seem to get deployed to the web project.

I will deal with issue 1 first. Most of this solution came from a posting on the eclipse.webtools newsgroup, however it is quite incomplete with respect to Maven projects:

  1. Open .project file for the project to be converted to web project.
  2. Insert the following to natures element:
    <nature>org.eclipse.wst.common.project.facet.core.nature</nature>
    <nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
  3. Open the properties for the project and go to the section for Project Facets
  4. Add Java and Dynamic Web Module facets to the project. (I forgot the Java facet first time around and had a lot of confusion until I worked it out)

The above will work for a non-maven project the rest you will need if you are using m2eclipse:

Open the .classpath file and add the following:

<classpathentry exported=”true” kind=”con” path=”org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER”>
<attributes>
<attribute name=”org.eclipse.jst.component.dependency” value=”/WEB-INF/lib”/>
</attributes>
</classpathentry>

Open the org.eclipse.wst.common.component file in the .settings folder of your project and add this line inside the wb-resource block:<wb-resource deploy-path=”/” source-path=”<nested module name if you have one>/src/main/webapp”/>

Issue 2 is really annoying to me since most of our applications use multiple modules to decouple the services from the way they are exposed, ie. via a Java MVC framework, Web Services or via BlazeDs to a Flex RIA. Having this limitation forces us to have a single eclipse project for the services and the web tier or transport tier. This can have the effect of hiding coupling between your services and the web or transport tier.
Nevertheless it is a reality that has to be dealt with right now. You can manage it very easily in IntelliJ, however, even there I can, as yet, find no way to tell the editor that the service tier jar source code is actually in the editor so that I can set break points. Probably this could be dealt with but I was reluctant to spend time on it when I know our management would flip if I suggested paying for all developers to have IntelliJ  licenses :-D
Okay, so the way to solve this problem with m2eclipse is to have the service or core application and the web server application as a single project with multiple maven modules. This sucks for a couple of reasons. The first is that if you have decomposed your application into more that 2 modules it is very hard to manage all the source folders in eclipse. The second reason I mentioned above, this approach will actually have eclipse compiling all classes into the one class folder and deploying that to your web server once you set WTP up. I have seen a number of instances where this effectively makes decomposing your application into multiple modules a waste of time or worse since it gives you the impression that you are enforcing a decoupling when in fact you are not.
If you use this approach then the instructions above still apply in terms of setting up WTP once you have created your multi-module project. In the last step you will need to prepend the web server module name to src/main/webapp (the angle brackets in the description above show exaclty where this goes).
I hope this helps someone, at the very least it will help me the next time I have to deal with this.