[Arp] Just a view thoughts

[christoph atteneder [celumSOLUTIONS]]

Hi all,

It´s a long time since I posted last =). I started on a medium sized research project using ARP as base, but ended with a bit different approach. Even if my framework would be to much overhead for small projects I´d like to share my ideas and experiences. Eeach idea and criticism is welcome, because I think that we made a few things too complicated.

my package structure:

/business
  BusinessDispatcher
  ServiceLocator
  /request RequestContainers which are executed from a BusinessDispatcher.
I use just one serverside servicemethod, where the requestobjects are passed through. Actually I´m not sure anymore if that was one of our best ideas ;-). We experienced a few not deterministic problems (FlashPlayer and whole IDE crashed when "very" similiar requests are send in one flash remoting package). Our idea was in the beginning to decouple the client and the remote services, because it was easier for us to communicate this changes through request value objects, which are automatically built through ant from the java developer. Each request needs a container for execution, in most cases a simple DefaultRequestContainer was used, but if we needed an specific action (e.g. update of cached data) before e.g. DataChangedEvents could be sent a special RequestContainer has been used.
-----------------------------
/control
  Application //references views and initializes application
  BusinessController //references instances of required ActionControllers(described later)
			     initializes Model instance(described later) and BusinessExecutor(calls the specific remote service)
  /action //contains specific controller for actions(e.g.: to create a new User), which handles the view, creates the required request and passes the request wrapped in a container to the businessController
-----------------------------
/event
	DataChangeEvent //Interface for all DataEvents (e.g.: a form creates a new user and after response all forms, which implement the specific Interface receives the e.g.: UserDataChangeEvent to react on the data update)
	ViewEvent //Interface for all ViewEvents (e.g.: Menu item "show user" was selected a UserSelectedEvent is broadcasted  and the user form, which implements the UserSelectedEventListener interfaces, loads data and displays the user data) ... specific packages and classes for all Events
-----------------------------
/loader
Just a few Formloader
-----------------------------
/managers
contains DragManager and Cursormanager for application
-----------------------------
/model
I used a centralized model in my prototype because of following requirements:
We didn´t wanted to reload the whole data each time something changes, we wanted to centralize our data because of the fact that a lot of forms share the same data. Our views itself have controller logic inside (just our popup forms have a seperate controllers), which get their data only through the model. The model decides if the current data is up-to-date or if it has to reload parts of the data and passes the data back to the view. Because we used for prototyping just on model, it grew very fast(we reached the max class file size) so we had to refactor it.
-----------------------------
/view
contains all views or forms. All views listen to data and view events and fetches their data through the model.
-----------------------------
/vo
contains all generated value objects from the backend developer. We use an ant task and a little as generator to automate VO generation and to reduce typing errors.
The ViewConfiguration, SystemConfiguration, ApplicationContext,... is passed from the server for initialization of the application
-----------------------------
Config
is actually just a temporary file which holds the out instance for debug output(old output system of as2lib) of all classes.


Conclusio:
This approach worked for us pretty well, also in another prototype, except for the plugin crash problem. It seems to be that if the flashplayer or openAMF makes mistakes in mapping the requests to the proper responses, if the request happens nearly in the same timespan(a few milli secs). Currently we prevent the crash through a requestqueue in our BusinessExecutor.

Currently I´m refactoring the framework(there is still a lot of ugly stuff ;-)) and I want to combine it with the existing ARP Framework and going to post my thoughts and ideas in the next days. And again all thoughts, ideas and critisim is welcome =).

All the best,

Christoph