Recent Blog Entries
Open Source Project: Athena Framework for Flex v2.0.0 Released
Entry posted on Mar 24 by
Jack_L
Athena Framework is a full fledged enterprise object-relational mapping (ORM) framework that employs metadata as mapping configuration. It greatly simplifies Flex/Flash RIA application development by providing transparent object remoting - i.e., you can manipulate objects on the client side using Flex just like on the server side using Java with Hibernate/JPA thanks to the unified object model provided by Athena.
Further more, Athena Framework removes the requirement of manual ORM mapping and manual database schema updating. In addition to features like object relational persistence, powerful EJBQL querying execution and comprehensive code generation, Athena has built-in support for multi-tenancy which enables developers to build cloud applications easily.
Manipulating Objects on the Client Side
For many rich Internet applications, objects needs to be loaded and manipulated on the client side. Consider a very common CRUD scenario: the UI loads and displays a list of Departments objects and let the user view employees under a selected department, create and edit Department/Employees; once the user finishes the editing, he or she clicks a button to save the changes. Without a decent object manager on the client side, such kind of operation is hard to implement.
Athena offers a UnitOfWork on the client side for Flex which implements the Unit of Work pattern (plays the same role as an EntityManager in JPA context). With Athena, you can implement the CRUD scenario with code shown below:
var uow:UnitOfWork = ...;
var depts:ArrayCollection = ...;
Department(depts.getItemAt(0)).nameFull = "New Dept Name";
var dept:Department = Department.createNewInstance();
dept.nameFull = "R & D";
var emp:Employee = Employee.createNewInstance();
emp.firstName = "Alan";
emp.lastName = "Turing";
emp.department = dept;
depts.addItem(dept);
eoService.invokeService("persistenceService", "save", [depts], onSaveSuccess, onSaveError, null);
|
Implementing Change at the Speed of Your Thought
Traditionally, it is painful to make changes as it requires multiple manual updates. For example, to change Employee.deliveryAddress from CHAR(100) to NVARCHAR(256), you need: 1. change column Employee.deliveryAddress to NVARCHAR(256) in the database; 2. update XML mapping configuration; 3. update Java code; 4. update Flex code; 5. update validation code of the user interface. Such manual synchronization process is time consuming and error prone, and a simple change like that could easily take 30 mins or more. There must be a simpler way to do it.
Athena makes performing changes a breeze. For the above example, you only need to do one thing: use the free GUI tool Athena Console to find the attribute Employee.address and change its type. Behind the scene, Athena Framework does the following for you:
- automatically change column
Employee.deliveryAddress to NVARCHAR(256) in the database;
- automatically updates metadata;
- generate source code (both Java and ActionScript) when you press 'Generate source code' button.
You do not need to change the validation code as you can access the metadata at runtime to validate against the actual definition of the attribute Employee.address.
Create Your Own Salesforce.com! Developing Cloud SaaS Applications Easily
With simple configuration, you can easily enable your application to serve multiple client organizations using just one instance. Multi-tenancy is one of the key enabling technologies for cloud computing, and it enables the fundamental economic benefits of a shared resource and is a much faster way to deploy improvements.
Athena has built-in support for multi-tenancy. By setting the multitenancy flag, your application becomes cloud ready instantly! When EJBQLs get executed, Athena will generate SQLs that enable multi-tenancy. Any Athena based application can be turned into a multi-tenancy application instantly.
For more details, please visit http://www.athenasource.org/flex/index.php
Coding Conventions for Actionscript 3.0 v1.1 - Actionscript代ç ?规范
Entry posted on Nov 10 by
Jack_L
Note: this is not the official Adobe coding convention spec. In fact, it is our own version.
Download the file in PDF format:
English edition | ä¸æ–‡ç‰ˆ
Table of Contents
1 Introduction
1.1 Convention
1.2 Recommendation importance
1.3 Major differences with traditional code conventions
1.4 Major difference with Adobe conventions
2 Naming Conventions
2.1 General naming guidelines
2.2 Package names
2.3 Class names
2.4 Interface names
2.5 Variable/property names
2.6 Function names
2.7 Event names
2.8 Namespace names
3 File Format
3.1 File name
3.2 File content
4 Statements
4.1 Packages and imports
4.2 Declarations
4.3 Control Flows
4.4 Literals
4.5 White spaces
5 Documentation & Commenting
5.1 General rules
5.2 ASDoc
6 ActionScript Best Practices
6.1 General Programming
6.2 Logging
6.3 Testing with FlexUnit
6.4 Updating Flex SDK Regularly
Appendices
ASDoc tag reference
Coding Conventions for Actionscript 3.0 v1.1 - Actionscript代ç ?规范
Entry posted on Nov 10 by
Jack_L
Note: this is not the official Adobe coding convention spec. In fact, it is our own version.
Download the file in PDF format:
English edition | ä¸æ–‡ç‰ˆ
Table of Contents
1 Introduction
1.1 Convention
1.2 Recommendation importance
1.3 Major differences with traditional code conventions
1.4 Major difference with Adobe conventions
2 Naming Conventions
2.1 General naming guidelines
2.2 Package names
2.3 Class names
2.4 Interface names
2.5 Variable/property names
2.6 Function names
2.7 Event names
2.8 Namespace names
3 File Format
3.1 File name
3.2 File content
4 Statements
4.1 Packages and imports
4.2 Declarations
4.3 Control Flows
4.4 Literals
4.5 White spaces
5 Documentation & Commenting
5.1 General rules
5.2 ASDoc
6 ActionScript Best Practices
6.1 General Programming
6.2 Logging
6.3 Testing with FlexUnit
6.4 Updating Flex SDK Regularly
Appendices
ASDoc tag reference
Coding Conventions for Actionscript 3.0 v1.1 - Actionscript????
Entry posted on Nov 10 by
Jack_L
Note: this is not the official Adobe coding convention spec. In fact, it is our own version.
Download the file in PDF format:
English edition | 中文版
Table of Contents
1 Introduction
1.1 Convention
1.2 Recommendation importance
1.3 Major differences with traditional code conventions
1.4 Major difference with Adobe conventions
2 Naming Conventions
2.1 General naming guidelines
2.2 Package names
2.3 Class names
2.4 Interface names
2.5 Variable/property names
2.6 Function names
2.7 Event names
2.8 Namespace names
3 File Format
3.1 File name
3.2 File content
4 Statements
4.1 Packages and imports
4.2 Declarations
4.3 Control Flows
4.4 Literals
4.5 White spaces
5 Documentation & Commenting
5.1 General rules
5.2 ASDoc
6 ActionScript Best Practices
6.1 General Programming
6.2 Logging
6.3 Testing with FlexUnit
6.4 Updating Flex SDK Regularly
Appendices
ASDoc tag reference
|
