We have pushed a new maintenance release which fixes 2 critical issues found after the 2.0.1 release was made available.

The main issue was related to IE and charting and the new calendar widget.

The release notes for this release are available at: http://www.appcelerator.org/release_notes_2.0.1.1.html

You can also follow the development of appcelerator by joining the Appcelerator Google Groups at http://groups.google.com/group/appcelerator-platform-sdk.

Also, if you’re a friend of Appcelerator and use Facebook, please join our Facebook group at http://www.facebook.com/group.php?gid=7886952159

Popularity: 6% [?]

The 2.0.1 maintenance release is now available at http://www.appcelerator.org/download.html.

You can find the full release notes for changes at
http://www.appcelerator.org/release_notes_2.0.1.html

The main summary of new features are:

- .NET service support
- Python service support
- PHP service support expanded to support PHP4
- New widgets: calendar and pagination
- Reimplemented modules to better utilizes direct function calling vs. building via strings

We also have fixed numerous bugs and made of improvements.

With this release, we will begin working on 2.0.2 with a target release date of 12/14/2007. I will post more information about what we are targeting for this release in the next week. If you would like to see any specific items addressed or features considered, please let us know. You can also directly open issues or feature requests by visiting http://jira.appcelerator.org.

Popularity: 4% [?]

In my last post, I talked about Service-Oriented User Interfaces (or SOUIs). In this post, I want to get more specific about what that means from a development perspective. In practical terms, a SOUI is nothing more than a composition of Service-Oriented Components.

A Service-Oriented Component is a component whose behavior and visual appearance is driven by a message and optionally some data in that message. In Appcelerator, we turn standard HTML elements into Service-Oriented Components. Let’s look at some examples:

Example 1: Progress indicator

1
2
3
4

<div on="r:login.request then show or r:login.response then hide" 
     style="display:none">
        <img src="images/progress.gif"/> Processing Login....
</div>

In Example 1, the display of a standard HTML <div> is controlled by two separate messages. The login.request message triggers the <div> to show and the login.response message will trigger the <div> to hide.

Note: Appcelerator Client messages are always prefixed with either an l: or an r:. The former tells Appcelerator that the message should only be sent locally (i.e., within the browser). The latter will result in the message being sent both locally and to a service.

Example 2: Submitting a form

1
2
3
4
5
6

<div>Username:</div>
<input type="text" id="username" fieldset="login"/>
<div>Password:</div>
<input type="password" id="password" fieldset="login"/>
<input type="button" value="Login" fieldset="login" 
     on="click then r:login.request"/>

In Example 2, when the user clicks the “Login” button, a request will be sent to a service that subscribes to the login.request message. The message’s data payload will contain two name/value pairs: ‘username’ with the value of the username input field and ‘password’ with the value of the password input field.

These two simple examples demonstrate both the power and simplicity of Service-Oriented Components. In Appcelerator, Service-Oriented Components are possible because of Appcelerator’s integrated Message-Oriented Architecture. This architecture binds user interface elements to services via a lightweight message contract. Appcelerator Message Contracts have two parts:

• message name (e.g., “login.request”)
• message data payload (i.e., one or more name/value pairs)

In Example 2, the “Login” form and the “Login” service share a message-based contract. This contract has a message name: login.request and two name/value pairs: username and password.

Service-Oriented Components can also take action based on the combination of a message and its data payload. Let’s look at some examples:

Example 3: Show an element based on message data

1
2
3
4

<div on="r:user.registration.response[success=true] then show"
   style="display:none">
   Your registration was successful as far as you know...
</div>

In Example 3, the registration message will only be shown if the r:user.registration.response message contains the name/value pair ’success’=true.

Example 4: Set styles and element values based on message data

1
2
3
4

<div on="r:login.response[gender=male] then set[border='1px solid blue'] 
     else set[border='1px solid pink']"  style="display:none" >
     Welcome back, <span on="r:login.response then value[name]"></span>
</div>

In Example 4, several user interface actions occur based on the message login.response and its data payload:

• The border of the <div> is set to blue if ‘gender’ is ‘male’, otherwise its set to pink
• The value of the <span> is set to the user’s name in order to complete the “welcome” message

These examples provide just a glimpse of the power of Service-Oriented Components. I’ve been developing applications this way for over a year, and I believe the benefits are enormous. Here are just a few:

• You get more functionality with significantly less code, or as we like to say: “More App. Less Code.”
• You can easily Ajax and DHTML-enable standard HTML elements without writing any Javascript
• You can create mock service handlers on the client - the result is a fully functional client prototype that is 100% resusable
• You get a very clean separation between the client and its services.

Now that I’ve set a new world record for using the phrase “Service-Oriented Component” in a blog post, my work here is done, plus you need to get back to work - your boss is standing right behind you.

Popularity: 8% [?]