This is interesting, but far too tightly coupled for general use. I don't really like referencing the top level Application.application for state info.

This would have been much better if each Template/Component dispatched and listened to events when states change.

Tanuvan, your feedback is greatly appreciated. This is one of the reasons why we decided to make this open source. Are you interested in helping to improve the framework? How would you implement the individual state changes?

Just at first glance, I would probably try and take an MVC approach. Because you have several different components that are related (i.e. dependencies), I would use more than one controller to prevent things from getting confusing.

For example, I'd have a customer controller that would respond to all events broadcasted associated with customer info. Inside of the event, I would pass state information as well as customer objects (using the DTO pattern)

So for a Customer Master Grid, when clicked, I would broadcast an event that contained that particular record inside of a data transfer object (we need the primary key), as well as any state information, and how to deal with the event (i.e. insert,update,delete or retrieve relational records).

The controller would be responsible for changing the view stack as well as moving data to the Model (Database). I'd make use of data binding, so I would likely use data binding on array collections etc. in the controller so that when data is updated, all dependency forms are updated as well. No need for broadcasting an event on return data.

To insure that only one customer controller is running, I would use a Singleton & Registry Pattern. Other constants specific to the customer components could be stored in the customer controller as well, instead of 1 large constant file. This makes it easier at least for me to find where specific constants are located.

This would allow code from anywhere in the app to call Registry.getCustomerController.custID;
Registry.getCustomerController.selectedState;

State changes could be managed here to prevent one component/template from having to reference another directly.
etc.

I wrote an actionscript version of the Active Record Pattern, and I use that to take the data transfer object and build the appropriate SQL.

I am rewriting your templates to follow a lightweight MVC pattern. I will leave out the complex regular expressions because at least for me, they are not needed, but good to have if your project calls for it.

Finally I use AMFPHP. I have a service locator class which handles the communication between actionscript and PHP. This class is called by the customer controller and handles the returned data.

The goal would be to have all component forms independent of each other and only broadcasting and listening to events. You could extend the Event Dispatcher to create a global listener for these different events. Each controller would then register with it. No hardcoded dependencies. A lightweight MVC approach makes it easier to grasp what is happening without having extensive documentation.

Sorry if this was too lengthy :) I really like your concept!

Sounds great! I'm looking forward to seeing your modifications.
One more question: Would you modify the server for each project or is that always the same - similar as described in my previous post?: http://www.insideria.com/2009/04/simple-server-backends-for-fle.html

The sql is generated within the client and sent as AMF binary to PHP. Session management is done with PHP session as well as authentication/user privilege management. There is only 1 PHP server class. This class communicates with AMFPHP and accepts the SQL code and queries the data using PDO.

PDO prepare statements eliminate the risk of SQL injection.

PDO also allows you to connect to any database that PHP supports.

Any backend language can be used as long as it can accept a SQL string, and manage server sessions. Sessions can also be stored within the database encrypted for more security.

So I suspect it is inline with having "Simple Server Backends" per your article. No server modifications would be required for each project, and it only sends SQL. It could be as simlpe or complex as you need.

With the active record pattern, all that is needed is a DTO class in actionscript. The rest is all handled by the active record code. The DTO class should mimic the structure of the database table with the primary key being the first property.

//DTO example class
package vo
{
import controller.services.ActiveRecordDTO;

[Bindable]
public class Demo extends ActiveRecordDTO
{
public var demo_id:String;
public var demo_name:String;
public var demo_description:String;

public function Demo()
{
super("demo_id","String",true)
}

}
}

An example of the event to manage a DTO looks like this:

package com.events
{
import vo.Demo;

import flash.events.Event;

public class DemoEvent extends Event
{
public static const DEMO_EVENT:String = "demoEvent";
public static const SAVE_DEMO_DATA:String = "saveDemoData";
public static const DELETE_CURRENT_DEMO:String = "deleteCurrentDemo";
public static const SELECT_CURRENT_DEMO:String = "selectCurrentDemo";
public static const SELECT_DEMO_BY_ID:String = "selectDemoByID";

public var demo:Demo;
public var action:String;

//Here, DTO is passed in when the event is created
public function DemoEvent(demo:Demo, action:String = "No Action")
{
super(Demo_EVENT, true);//(type,bubbles)
this.demo = demo;
this.action = action;
}

}
}

The event is dispatched via button click or whichever...
Within mxml view component:

var testDemo:Demo = new Demo();
testDemo.demo_id = '1';
testDemo.demo_name ='MyTestDemo';
testDemo.demo_description ='TestingDemoEvents';

or it can be an object from a selected grid i.e.

testDemo = ActiveRecord.constructFromObject(myDatagrid.selecteditem);

Then broadcasted :

Broadcaster.instance.dispatchEvent(new DemoEvent(testDemo, DemoEvent.SAVE_DEMO_DATA));

The controller then listens for this event, and has all the information it needs to process
the event without knowing which component created the event. This makes for a very loosely coupled application. One that doesn't necessarily require the use of each component.

This prevents these kinds of calls:

Application.application.Main_FormView.closeFormView();
Application.application.Main_ViewStack.selectedChild = Application.application.Main_FormView;

Which can be hard to understand if you are not familiar with how this is coded. I'd love to do more, but I only program as a hobby :) I am a DBA in real life ;)

This was just my initial impression...I'm not sure where you are trying to go with the project...it does have great potential though.

We use our framework for quite a few projects in industrial applications along with surveys, contact management, order/invoice management, quality control, etc. - so, basically anything that accesses a database and directly manipulates its data.
The main goal was to have a framework that allows anybody to implement new RIA database projects in a matter of one or two days.

Regarding events vs. states I'm quoting one of the developers directly:

One of reasons that we are not using events too much is to reduce implementation time. The basic templates for login, welcome screen, workspace, lists, relations and dependency views, which are non-static classes, are rarely modified in new projects. On the other hand, all template forms (such as customers, users, group forms) are static classes and will be frequently changed based on the project's needs. As a result of using both static and non-static classes together, binding each UI object with events will be expensive because modifying a class might cause other classes' modifications. This is even against MVC design. Furthermore, catching an event is less efficient than using a static implementation because an event can be propagated all the way down to the bottom class. Especially in very large projects with hundreds of lists and forms that would make the system very slow to respond.

In terms of server connections and security we are not using prepared statements to be able to change the sort order or add filters to all kinds of queries on the fly (e.g. via search box). Also, queries across multiple databases with multiple, nested queries are much easier to implement this way. The increased risk of SQL injections is met by having the server filter and parse any and all queries. Things like semicolon within queries or drop statements are not permitted with a few additional filters.

Security is also one of the topics I'd like to cover in one of the next posts. This can almost be a totally separate project in itself. The current framework allows to send SQL directly to the server but there is no security on a record-level yet. We do have a server for that in development which also allows to access non-database data sources like MS Excel files like a regular database and link its data to standard databases like MS SQL, Oracle, etc. within the same query.
The main question is always how secure does the application have to be - Intranet vs. Internet, limited access vs. open access, user groups, etc.

Let me know if you want to send me your modifications and/or samples. I'm very interested to see how this would work in your project and if we can combine this.

One more thing I forgot to mention: The current server is literally just click and run and is supporting SQLite to be able to use an embedded database without any installation or configuration. The public Open Source version is using that as well.
However, an enhanced PHP server backend is definitely on the list to be able to run this on more platforms.

Thanks for the detailed response!

{quote}binding each UI object with events will be expensive because modifying a class might cause other classes' modifications. This is even against MVC design.{quote/}

I think you misunderstood. The point of having your class (i.e. a view or form) dispatch events is precisely to eliminate the impact of modifying other classes. Other classes do not need to know anything about its dependency. It only responds to events if it is registered as a listener. I am not talking about each little button click event. But the events related to data and state management. The binding I am referring to is binding of datagrid dataprovider to an arraycollection in the controller. There absolutely should be dependency between the controller and the view, and the controller and the model. But not in the way you design with dependency between views themselves.

As it is, your framework is statically coded. This trades clarity of code for speed which I have yet to see any performance issues. (MVC approach is how most of adobe consulting sets up projects with some form of MVC framework)

{quote}
Furthermore, catching an event is less efficient than using a static implementation because an event can be propagated all the way down to the bottom class. {/quote}

This really isn't against MVC as the ActionsScript event propagation system is really an Observer pattern. Event propagation can be limited to the parent form and below...which would solve the issue of propagating through hundreds of classes. And in practicality, most database applications do not have that many forms...they are mostly minor versions of the same type of form...i.e. datagrids, combo boxes .etc. Data binding is also recommended by Adobe. A database application really should not have View classes that are hundreds of levels deep.

{quote}In terms of server connections and security we are not using prepared statements to be able to change the sort order or add filters to all kinds of queries on the fly (e.g. via search box). Also, queries across multiple databases with multiple, nested queries are much easier to implement this way.

We do have a server for that in development which also allows to access non-database data sources like MS Excel files like a regular database and link its data to standard databases like MS SQL, Oracle, etc. within the same query. {/quote}

I work for a fortune 100 company, and we have many different systems from old Informix to Oracle 11G linux grid clusters...PHP with PDO allows you to query across platforms/database with the same sql with no problems (Provided you are using ANSI SQL). Even MS ACCESS,CSV Files etc. are accessible all in PDO.

{quote}The increased risk of SQL injections is met by having the server filter and parse any and all queries. Things like semicolon within queries or drop statements are not permitted with a few additional filters.{/quote}

Why do this with custom code on the server? It is already available in most programming languages including PHP. It is more work than needs to be. That is one of the reasons why the prepare statement exists. Also, if you are using AMF and serializing the queries, SQL injections are that much more difficult. Someone would have to sniff the packets, and then de-serialize and decode the AMF binary...inject their code, and re-serialize and send to AMF again. Here again I am assuming that the SQL is already created in the FLEX application before it is sent across the wire.

{quote}The current framework allows to send SQL directly to the server but there is no security on a record-level yet. {/quote}

Implementing record-level security is going to be a very difficult endeavor at the server level.
Row/Record locking & Row level security support is determined by the PDO driver and database API. Particularly the latter. With Oracle PDO drivers for example, row locking and commit is supported...as is rollback, and roles/permissions. Obviously SQLite lacks this, and attempting to implement it is really going beyond what SQLite was designed for.

What I proposed initially was a more accepted framework. There is a reason why pureMVC, Cairngorm, MATE, etc are all popularly used by Adobe consulting. I have no doubt that your framework works well for your company. However, I don't see it being readily adopted because it is designed too specific and too tightly coupled. Your static implementation works for you, but it is not familiar to someone who might want to pick this framework up and use it outside of your company.

Any framework based on a loosely coupled architecture with a MVC approach will be easily accepted and understood. Flex itself is based on an MVC architecture. Static implementations were very common in the days of visual basic, but have definitely fallen out of favor. I do wish you the best of luck with the project!

Tanuvan

Tanuvan, this is a lot of excellent feedback. Our framework is certainly still in an early stage and there are lots of things to be improved. Your feedback definitely helps with that quite a bit.
I think, all different approaches have pros and cons and some benefits like small-footprint, zero configuration and fast implementation are paid for with a few downsides. We are absolutely on the same page for creating a generally more accepted framework without creating just another one among thousands of others. I hope the Open Source approach contributes to that goal.
The fact that we were able to get new developers without previous Flex or PHP experience up to speed in a matter of hours and have them create new, working applications within a day or less was crucial for us. We haven't found any other framework out there that was able to solve that problem.
Would you be able to post one of your sample projects here so that we could maybe compare on an implementation level?

Unfortunately I can't post the projects I am working on now. However, I gathered this method from the ideas in the first link below, as well as an excellent treatment of the subject by Maxim Porges who is very active in Flex/Actionscript coding.

http://clockobj.co.uk/2007/10/17/simplified-cairngorm-easy-mvc-for-adobe-flex/

And

http://groups.google.com/group/adogo/browse_thread/thread/b7e276284101bb3a

Second message down has a link to Maxim's pdf. It explains it much better.

I do a few things different; for instance I use more than one controller...(I suppose they could be called front controllers) and I use an actionscript class for the webservices calls and a service locator rather than tags.

I also do not register events on the System Manager as in that first link example. I use a global listener for small projects.

I completely agree that with an Open Source approach, as more eyes look at the source code, more ideas will flow.

There are two different perspective here and neither is more correct per se, it all depends on what you are willing to trade off. I find lightweight MVC more flexible and elegant, while the statically coded method is more direct and less intuitive. At the end of the day, both choices will work.

Cairngorm in my opinion was far too complicated and was essentially a port of the Java based patterns. This led me to the lighter MVC frameworks such as mate, swiz, and finally just no framework at all with the MVC design pattern suggested by Maxim.

After an attempt at writing a rather large project for use with Oracle using the statically coded method, I found it difficult to communicate my ideas to other developers, and reuse of the components suffered as a result of tight coupling.