Posts in Category "Flex"

Open Source Flex 2 Calendar Component

A regular discussion on Flex forums such as FlexCoders is the availability, or otherwise, of a good Calendar component for Flex 2.

So, it is with great pleasure that I can announce that the Adobe Consulting team in EMEA will be releasing an open source Calendar framework to the community within the coming weeks.

This is a framework the team here have been working on for a while and Alex Uhlmann is putting the finishing touches to.

Below is a screenshot of a simple Calendar built on top of the framework, which uses the default renderers for the calendar entries and timeline.


Don’t be deceived by the basic look of this example calendar and its surrounding controls – the calendar is built on top of an extremely powerful framework which can be used to build very complicated scheduling components and we’ve spending the majority of our time working on that rather than this example. However, we do plan to ship some better examples with the framework.

Some of the features of the Calendar framework are:

  • Display and manipulate 1000s of calendar entries without losing performance.
  • Define how entries are laid out using the predefined layout manager or by providing your own customized layout manager.
  • Assign custom renderers that can dictate the complete look and feel of your calendar entries.
  • Provide renderers in MXML or ActionScript.
  • “Live” zoom support using zoom API.
  • Use framework effects such as Zoom and Move to make best use of the expressiveness of a Flex RIA in order to achieve the best user experience possible while navigating the component.
  • Efficiently add, remove and update entries at runtime.
  • Assign customized background areas to show office hours, lunch time etc
  • Fully stylable
  • Ability to select calendar entries with visual highlighting
  • Consistent in usage with the Flex Framework, eg. dataProvider driven
  • Broadcasts events to help interaction development
  • Can be used in MXML or Actionscript
  • And more…

To give a glimpse of the API of the calendar, here’s the MXML used to create the above example. However, please note that we are still defining the API, so it may change in the final version.

width="600" height="400"
dataProvider="{ appointments }"
startDate="{ new Date() }"
duration="{ DateUtil.DAY_IN_MILLISECONDS }"
zoom="{ zoom }"
itemLayoutManager="com.adobe.calendarClasses.BestFitLayoutManager" />

We’re very excited about this contribution to the Flex community and, in time, look forward to seeing it used within your Flex applications.

Finally, in expectation of the being asked the obvious question, and following in the footsteps of all good delivery teams, the answer is “It’ll be ready when its ready” 😉

Cairngorm 2 Stateless Commands

You may have seen over on Steven Webster’s blog that Cairngorm 2 for Flex 2 Beta 3 has been released.

The main change in this release, compared with previous releases, is how commands are instantiated and used. I’d like to touch on the motivation behind this change.

In Cairngorm for Flex 1.x, a single instance of each command was instantiated by the controller and that one instance is used for each and every invocation of the command.

There are reasons why the original implementation was done in such a manner, mainly historical due to Cairngorm originally being developed for Flash applications, but since the advent of Flex, we’ve wanted to change it. With the API scrub taking place between Flex 1.5 and Flex 2, we see now is a good time to make this change.

Steven explains on his blog the single change you’ll have to make to your concrete front controller because of this API change.

So now, rather than the single instance of the command being used for each command invocation, the front controller now instantiates a new instance of the command on each invocation. There are a couple of implications here:

1) If, in your existing Cairngorm applications, you rely on the same command being used for each command invocation, (eg, if you store state in the command, and reuse that state on the next invocation), you will have to change your implementation. What we’d recommend here is that you store your state in your model, possibly via the ModelLocator pattern.

2) Because a new instance of the command is instantiated on each command invocation, you can now store local state in that command for the duration of its invocation. This is particularly useful for cases where you make server side calls (eg, via RemoteObject). Previously, you’d have to use a pattern such as the Asynchronous Completion Token, but now, you can store your state in a command’s instance variable in the execute() method (for example, you may store the event object), and then retrieve it again in your result or fault handler. We find this useful for cases where you want to update different parts of the model in the result handler, depending on the context of the initial command execution.

So, go get Cairngorm 2 for Flex 2 Beta 3 and let us know what you think.