redredred

It is a very rare event when I am asked to code an application which doesn’t have some security constraints. Most Java MVC frameworks provide some type of role based security for the UI out of the box. No such thing exists in Flex. I decided, after casting about for an existing solution, to write an authorize tag for myself. This component has the following properties which need to be set:

1. roles – one or more roles (strings) which are to be evaluated against.
2. userRoles – one or more roles(strings) which the user has
3. components – one or more components which will be effected if evaluation of roles against userRoles fails.
4. type – type of evaluation to be performed one of:
   • ‘hasAny’ – evaluates true if userRole exists in any of the roles
   • ‘hasAll,’ – evaluates to true only if userRoles contains all roles
   • ‘hasNone’ – evaluates to true if userRoles does not contain any of the roles.
5. behaviour – the behviour to be applied to the specified components:
   • Disable – disables the components if evaluation fails
   • Vanish – causes the components visible property to be set to false if evaluation fails
   • Collapse – causes the components visible and includeInLayout properties to be set to false if evaluation fails

Here is the code, please feel free to copy it and use it. Any feedback would be appreciated:

package com.express.security {
import flash.events.Event;
import flash.events.EventDispatcher;
 
import mx.collections.ArrayCollection;
import mx.collections.ICollectionView;
import mx.collections.IList;
import mx.collections.ListCollectionView;
import mx.collections.XMLListCollection;
import mx.core.UIComponent;
import mx.events.CollectionEvent;
import mx.events.FlexEvent;
 
public class Authorize extends EventDispatcher{
 
   public static const HAS_ANY : String = "hasAny";
   public static const HAS_ALL : String = "hasAll";
   public static const HAS_NONE : String = "hasNone";
 
   public static const DISABLE : String = "disable";
   public static const VANISH : String = "vanish";
   public static const COLLAPSE : String = "collapse";
   private static const BEHAVIOUR_ENUM : String = DISABLE + "," + VANISH + "," + COLLAPSE;
 
   /**
    * Roles which will be evaluated against the type rules and user's roles.
    */
   private var _roles : ICollectionView;
 
   /**
    * Roles which the current user has. These will be evauated aginst the type rules and roles.
    */
   private var _userRoles : ICollectionView;
 
   /**
    * Components which will have behaviour applied to them based on the evaluation outcome.
    */
   private var _components : ICollectionView;
 
   /**
    * Specifies the type of evaluation which will be applied to the roles
    */
   [Inspectable(enumeration="hasAny,hasAll,hasNone")]
   public var type : String;
 
   /**
    * Specifies the type of evaluation which will be applied to the roles
    */
   [Inspectable(enumeration="disable,vanish,collapse")]
   public var behaviour : String;
 
   public function Authorize() {
      super();
      addEventListener(FlexEvent.CREATION_COMPLETE, handleCreationComplete);
   }
 
   private function handleCreationComplete(event : FlexEvent) : void {
      evaluate();
   }
 
   public function evaluate() : void {
      var result : Boolean = false;
      if (_roles != null && _userRoles != null && type != null) {
         if (type == HAS_ANY) {
            result = evaluateAny();
         }
         else if (type == HAS_ALL) {
            result = evaluateAll();
         }
         else if (type == HAS_NONE) {
            result = evaluateNone();
         }
      }
      applyResult(result);
   }
 
   protected function evaluateAny() : Boolean {
      for each(var userRole : String in _userRoles) {
         if (containsRole(_roles, userRole)) {
            return true;
         }
      }
      return false;
   }
 
   protected function evaluateAll() : Boolean {
      for each(var userRole : String in _userRoles) {
         if (!containsRole(_roles, userRole)) {
            return false;
         }
      }
      return true;
   }
 
   protected function evaluateNone() : Boolean {
      for each(var userRole : String in _userRoles) {
         if (containsRole(_roles, userRole)) {
            return false;
         }
      }
      return true;
   }
 
   protected function containsRole(roles : ICollectionView, role : String) : Boolean {
      for each(var userRole : String in roles) {
         if (role == userRole) {
            return true;
         }
      }
      return false;
   }
 
   protected function applyResult(result : Boolean) : void {
      for each(var comp : UIComponent in _components) {
         switch(behaviour) {
            case DISABLE :
               comp.enabled = result;
               break;
            case VANISH :
               comp.visible = result;
               break;
            case COLLAPSE :
               comp.visible = result;
               comp.includeInLayout = result;
         }
      }
   }
 
   public function get roles():Object {
      return _roles;
   }
 
   public function set roles(val:Object):void {
      _roles = convertToCollection(val);
      evaluate();
   }
 
   public function get userRoles():Object {
      return _userRoles;
   }
 
   public function set userRoles(val:Object):void {
      _userRoles = convertToCollection(val);
      _userRoles.addEventListener(CollectionEvent.COLLECTION_CHANGE, handleCollectionChange, false, 0, true);
      evaluate();
   }
 
   public function get components():Object {
      return _components;
   }
 
   public function set components(val:Object):void {
      _components = convertToCollection(val);
      _components.addEventListener(CollectionEvent.COLLECTION_CHANGE, handleCollectionChange, false, 0, true);
      evaluate();
   }
 
   private function handleCollectionChange(event : Event) : void {
      evaluate();
   }
 
   public function convertToCollection(value : Object) : ICollectionView {
      if (value is Array) {
         return new ArrayCollection(value as Array);
      }
      else if (value is ICollectionView) {
         return ICollectionView(value);
      }
      else if (value is IList) {
         return new ListCollectionView(IList(value));
      }
      else if (value is XMLList) {
         return new XMLListCollection(value as XMLList);
      }
      else {
         // convert it to an array containing this one item
         var tmp:Array = [value];
         return new ArrayCollection(tmp);
      }
   }
}
}

There have been a couple of releases of the Simple Object Assembler in quick succession over the last week. These changes are all in aid of simplifying it’s use and can dramatically reduce the number of converters required in some projects due to enhancements to the auto-mapping capabilities.  One project i’m using it on saw the converters drop from 34 to 14!

A summary of the release notes from the last week are below:

0.4.1

This is a small api change release that simplifies a couple of commonly used methods. It will require changes to any existing converters. Please see upgrade notes below.

• Changed the return type of the alwaysIgnoreFields() method on a converter from a HashSet<String> to an internally defined IgnoreSet which has a string varargs constructor and is chainable. This makes for simpler implementation as you can simply do this… return new IgnoreSet("field1", "field2", "fieldN").
• Removed the return type on the overridable convert(...) method of a converter as it was unnecessary. This method is now void.

Upgrade notes:

1. Change all converters that implement the convert(...) method to return void instead of the destination object.
2. Change all converters that implement the alwaysIgnoreProperties() method to return an IgnoreSet.

0.4.0

• You no longer need to implement the methods getSourceObjectClass() and getDestinationObjectClass() as these are inferred via generics.
• You can now set the object assembler to attempt to convert objects automatically if no converter is explicitly registered for the source / destination classes. This is very convenient for basic situations where there are no special rules for the conversion as no converter needs to be written.
• As an extension to the auto-mapping described above, you can also inject an EntityDao? for looking up JPA / Hibernate mapped entities by id when converting to an entity mapped using the javax.persistence.Entity annotation. Basic Hibernate and JPA implementations have been provided but you can plug-in your own as required. While I haven’t tested it with anything other than Hibernate, it’s highly likely that this will work with any JPA implementation but you’ll need to inject your own. One caveat with this however is that in order to look up the entity using the supplied EntityDao, SimpleObjectAssembler needs to know what field in your dto holds the id of the entity to fetch. To achieve this, annotate your dto with the EntityDto annotation supplying the field to get the entity id from. Eg. @EntityDto(id = “id”)
• Fixed problem where source objects must have a property for every method prefixed with ‘get’. This meant that methods that did things like combine other properties or perform calculations would cause the assembler to fail. These ‘computed’ getters can now be mapped directly to destination objects.
• Added default converters for mapping strings and numbers.

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

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

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!!