Tracing the evolution of the Cairngorm framework reveals a great effort to isolate business logic. A coup of the framework has been to shift event flow from exclusively the display list towards a simple, efficient non-UIComponent propagation within an application architecture.
Specifically, the native event flow in Flex works hierarchically within the display list. Since display objects are by definition hierarchical, events flow through them from impetus to the bottom node and, if so configured, back again. This ensures full propagation of the event. A reasonable supposition on behalf of Cairngorm engineers is the difficulty of performing business logic apropos of a display hierarchy. Business logic requires a unique non-display set of delegates, services and model managers. The Cairngorm framework places events at the behest of these classes.
How then to bridge the new events and the old? This is where flexcairngorm takes the reins.
There is a very handy explanation of this, supplemental graphics and all, by Thomas Burleson on Gridlinked.info. He describes the process by which notification returns to the view following the propagation to business logic and the response back. It involves IResponders and a callback parameter. Browse gridlinked.info to learn all about it.
Once you've read it, the next step is coordinating flexcairngorm with Mate dependency injectors, using Mate EventMaps.
Tuesday, December 22, 2009
Flex MVC options
The set of instructions in rich applications tends to get quite complex. Thus, RIA code needs to be divided up into smaller components to manage complexity. Design patterns such as MVC are loose methodologies for doing this, with limitless implementations in practice. In Flex, MVC are often referred to as microarchitectures. They manage business logic for a client application, allowing decoupling between logic and UI.
The prominent first generation of mature MVC framework for Flash and Flex is called Cairngorm. It is now up to 2.2 with version 3 hovering indefinitely in beta. Cairngorm introduces a new system of event management called the CairngormEvent. It is more analog than extension of a Flex Event, since it has unique dispatch and propagation attributes.
The pros and cons of isolated event management, MVC and FlexEvent, have been largely considered in the developer community, resulting in some rethinking of Cairngorm event methodology. A prominent advance is UniversalMind's UM Cairngorm Extensions. This represents first and foremost an enrichment of the Cairngorm framework. If you plan on going down this path, UM Extensions may allow you to do more with it.
Otherwise, Flex is reaching the second iteration of third party frameworks, as Cairngorm gets more competitors. Mate and Swiz lead the pack, with retooled and reconsidered architectures for events and business logic structures. In some cases, microarchitectures are fully MXML in the second iteration.
By no means is the solution one-sided, as many groups have invested heavily in their extant codebase. In any case, all the options deserve a thorough look see. Some orientation will allow you to consider the best for your project.
The prominent first generation of mature MVC framework for Flash and Flex is called Cairngorm. It is now up to 2.2 with version 3 hovering indefinitely in beta. Cairngorm introduces a new system of event management called the CairngormEvent. It is more analog than extension of a Flex Event, since it has unique dispatch and propagation attributes.
The pros and cons of isolated event management, MVC and FlexEvent, have been largely considered in the developer community, resulting in some rethinking of Cairngorm event methodology. A prominent advance is UniversalMind's UM Cairngorm Extensions. This represents first and foremost an enrichment of the Cairngorm framework. If you plan on going down this path, UM Extensions may allow you to do more with it.
Otherwise, Flex is reaching the second iteration of third party frameworks, as Cairngorm gets more competitors. Mate and Swiz lead the pack, with retooled and reconsidered architectures for events and business logic structures. In some cases, microarchitectures are fully MXML in the second iteration.
By no means is the solution one-sided, as many groups have invested heavily in their extant codebase. In any case, all the options deserve a thorough look see. Some orientation will allow you to consider the best for your project.
Thursday, December 3, 2009
Multiple AMF Django apps share a common gateway
A while back I wrote about a library called django-flashpolicies for providing a flexible remoting environment. Essentially, it frees up the root of your django project for whatever content you like while providing a crossdomain policy file there for remoting applications.
That is still one way to go, but as an advance on that, have a look at the Django-amf-gateway library.
The PyAMF team offers info on it as a way to structure a django project such that you can heap on all the apps you want and allow them to share a common http gateway. By simplifying gateway addresses on the server side django-amf-gateway simplifies resource management on the client side.
Works great in applicable cases.
That is still one way to go, but as an advance on that, have a look at the Django-amf-gateway library.
The PyAMF team offers info on it as a way to structure a django project such that you can heap on all the apps you want and allow them to share a common http gateway. By simplifying gateway addresses on the server side django-amf-gateway simplifies resource management on the client side.
Works great in applicable cases.
Tuesday, December 1, 2009
More on mod_wsgi issues
When you add wsgi to Apache it is so you can run Python on Apache. Thus you need, at a minimum, Python and Apache.
Python
If you use a utility such as virtualenv to compartmentalize several domain development environments on one server account, installing mod_wsgi may not and probably will not be associated with the correct Python library. Will not, that is, unless you explicitly point it out in the installation process. Be sure to plan in advance which Python install you are developing for, and be sure to flag it when installing mod_wsgi:
./configure --with-python=/home/django/domains/mydomain.com/bin/python2.5* ***
*** UPDATE (1/31/10): Please read the helpful comment and link from Graham Dumpleton, author of mod_wsgi, below. Per his direction, it is best to install mod_wsgi against the complete base Python installation and add references to the virtual environments from your Apache config or from the WSGI script file. Thanks for taking the time to clarify, and for making mod_wsgi available for general use.
That said, there are many ways to install mod_wsgi, from manual to managed by aptitude, get-apt or the like. The downside to using a managed install is the dependency on the vintage of their managed version. At last check, the aptitude repository of mod_wsgi is still at 1.3 while the current stable version on googlecode is 2.8. Thus, you may want to look into another method, perhaps a manual installation.
Apache
When manually installing mod_wsgi, be sure you have the appropriate development library for apache, in the case of ubuntu hardy heron, apache2_threaded_dev will allow you to install mod_wsgi. Furthermore, if you are using aptitude to install apache2_threaded_dev, go ahead and update the distro as a whole first by running sudo aptitude update. If you do not, you may find the install doesn't work, and there will be no indication as to what went wrong.
Finally, with these measures in place, try ./configure with the appropriate flags and see if you can get the correct library in place. Good luck.
*your location will be different from this example
Python
If you use a utility such as virtualenv to compartmentalize several domain development environments on one server account, installing mod_wsgi may not and probably will not be associated with the correct Python library. Will not, that is, unless you explicitly point it out in the installation process. Be sure to plan in advance which Python install you are developing for, and be sure to flag it when installing mod_wsgi:
./configure --with-python=/home/django/domains/mydomain.com/bin/python2.5* ***
*** UPDATE (1/31/10): Please read the helpful comment and link from Graham Dumpleton, author of mod_wsgi, below. Per his direction, it is best to install mod_wsgi against the complete base Python installation and add references to the virtual environments from your Apache config or from the WSGI script file. Thanks for taking the time to clarify, and for making mod_wsgi available for general use.
That said, there are many ways to install mod_wsgi, from manual to managed by aptitude, get-apt or the like. The downside to using a managed install is the dependency on the vintage of their managed version. At last check, the aptitude repository of mod_wsgi is still at 1.3 while the current stable version on googlecode is 2.8. Thus, you may want to look into another method, perhaps a manual installation.
Apache
When manually installing mod_wsgi, be sure you have the appropriate development library for apache, in the case of ubuntu hardy heron, apache2_threaded_dev will allow you to install mod_wsgi. Furthermore, if you are using aptitude to install apache2_threaded_dev, go ahead and update the distro as a whole first by running sudo aptitude update. If you do not, you may find the install doesn't work, and there will be no indication as to what went wrong.
Finally, with these measures in place, try ./configure with the appropriate flags and see if you can get the correct library in place. Good luck.
*your location will be different from this example
Subscribe to:
Posts (Atom)
