Organic Programming

Even if asynchronous programming can get tricky, it enables a beneficial declarative  coding style.  I will present a few use cases for which  benefits outweighs the risks (risks that could come from bad/stupid programmers mainly):

• Form validation.  Data validation is a natural part of the model (remember the fat model idea) and it is not part of view for sure. With triggers in quark, it is possible to easily set metadata about invalidity of fields/objects and the view  will just reflect changes in metadata.
• Loose coupling in MVC and support for View States (quark terminology). The idea is that a type of data (an object) should be  differently viewed by the user depending on internal values.  In quark, asynchronous triggers will watch member values, set  a ViewState metadata and the view is switching to a proper view. Imagine doing this in a pure procedural way… This solution offers  the best possible loose coupling in Quark’s MVC  (only one way loop communication between V-> C ->M->V in this order)  .
• Implementation of the business rules layer.  A way to  enforce specific business rules on the quark models is by using triggers that  will watch values and as result will create new objects,change values.

I was always passioned on how to make programming a easier task. A direction that looked promising to me when I was a student was about programming techniques based on asynchronous behaviors. Asynchronism allows a declarative style that can simplify(minimize) the code,at the expense of  some complexity in behavior.  In many cases that is the right thing to do (such asynchronous code could be expressing business rules (what) and not how you do low level variable management => usually a very good practice ) but you have to simulate it in pure synchronous programming languages.

Many years after school, when I discovered Action Script and his events model based on observer design pattern, I instantly liked it.  I know that many programmers have serious problem dealing with asynchronism in their code and for good reasons (and others are abusing it when simple function calls should be used ). The usual solution is to create synchronous layers  inside of an asynchronous environment and hope for the best

In Quark’s model description language, we have the idea of “trigger”  that is basically a function/observer that is automatically called when other objects get changed. While this is a very natural way for describing model’s behavior, a naive implementation of the triggers can become very tricky to understand. The cause looks to be the intuition of atomicity of changes in a function.

class example
{
 var a:int; //should never take a value greater then 10
 var b:int; //should be always 10 * a, or 0

 [trigger on a changes]
 function trigger1()
 {
   if(a >= 10)
   {
    b = 100;
    a = 10;
   }
   else
    {
     b = a * 10;
    }
 }

 [trigger on b changes]
 function trigger2()
 {
   if(b != a * 10)
   {
    b = 0;
   }
 }
}
 var e:example;
 e.a = 11;

Above code (in a hypothetical action script dialect) should result in e.b having value 100.
Still, a naive implementation of triggers, could lead b having value 0 if trigger2 get called immediate after b = 100. This is just a simple example that reveals how evil the asynchronism can get.
We will take the risk in Quark Framework to implement asynchronous programming but we try to prevent things like unintuitive/unexpected behaviors or infinite loops caused by asynchronous events.
The syntax of Quark Schema language is a mix of XML and Action Script (but not really like MXML) and we will publish/document later (before the first release of quark 2 planed in October).
The way of preserving atomicity intuition about functions/triggers, it is also a good way to minimize the number of function calls (especially calls on intermediate results).

One question that sooner or later  the architects of a MVC framework should ask is how the system will be dealing with creation of error messages and pop-ups.  In Quark,we are trying to be consistent with our philosophy of strict separation and one single sense communication between model,view and controller.  Given that, a simple solution like calling PopUpManager.Show from view,model or controller it is not possible or  a good thing.  Other framework have the luxe of using Facades and Mediators to put code like PopUpManager.Show and do there the dirty work but we want to keep things simple and editable from UI.

Our solution is a bit abstract but it is using the MVC as it should do: there should be always a special place in  model where a controller can add a message or an object instance and that cause automatically the view to show a popup! Basically, we just create a convention and we expect quark’s view components to follow. That special place can be for example a special metadata member for the current data object.

Conclusion: in quark, pop-ups get displayed when they are requested by model or controller by stetting values in metadata and they are never directly displayed using direct calls.

What benefits do we see here?

• the code needed to create an application is shorter,cleaner and easier to write and maintain
• the code  for quark based applications have very few dependencies on platform’s APIs,the code is focused on  user’s problems and just follows a few standard conventions to achieve its goals. That will make easy in future to write quark like platforms in Java Script,Silverlight  or any other  technology and having the final application still working perfectly.
• this is a practical approach for having MDA’s advantages without UML or other abstract and esoteric technologies. We try to minimize even the design patterns we use inside of the framework but should not be a concern for the final user of the framework.

As a MVC framework, quark have a nice solution to the control of views using data from  model.

Firstly, we have a convention that every component we display in a quark based application has a model object instance that keeps the status and current configuration of that component. We call those object instances: shadows and we call the shadow classes,those quark classes that describe shadow objects.  That magic of quark is that it automatically creates UI for editing quark classes and in this way we have cheap UI to configure everything in current and future quark components.

The View is responsible for reflecting changes in model and for simplicity and loose coupling we don’t allow direct access of controller to the view . But if there is no direct connection how we control the UI?

Te answer stays in something we call metadata . A meta-data is like a member of an object,except that it is not a member that get persistence or UI. Meta-data can be attached to any quark object or to object members.  We identified a set of standard meta-data but any view component can need a different set of meta-data:

• ViewState metadata type ( not a very intuitive name,we are still looking for one) is probably the most important type of metadata.  This metadata give a hint to  quark about what shadow clone to use for UI configuration when a class instance  should be  displayed.  It simpler than it looks, basically every class instance in  model should have a ViewState metadata that is a name of a configuration used   to display/edit that object.
• ReadOnly metadata – an object with this meta-data set is obviously a read only objects
• Invisible metadata (for fields or objects)
• Label  metadata – what label get displayed when an object is displayed in a list,etc
• Icon metadata

We will show how it works  in some demos,soon.

One day I came across a task which involved using some sort of collection that was bindable
and could store and retrieve data like a dictionary does. And soon I got a new task : to build
such a data type.

Practically I needed a mix between Dictionary and ArrayCollection, so my first idea was to
extend Proxy, in order to access and retrieve data using square brackets, and after that to
create similar methods to ArrayCollection. But after looking over the source code of ArrayCollection,
I’ve noticed it inherits Proxy, due to ListCollectionView inheritance, which saved me from the classic
‘reinventing the wheel’ and led me to improving the wheel instead.

My plan was to modify the methods of ArrayCollection so it adds/removes links to the added/removed
objects and this way they could be retrieved later.It was pretty straightforward to override the methods
and add/remove references to items,which were stored in a Dictionary. It was also easy because I didn’t have to override each method as some of them are reused. For example, addItem  just calls addItemAt.

Besides this basic functionality, I thought it would be useful to add one more feature : adding and
removing references to items based on given properties. Let’s say you add objects with
quantity, price and label properties, using the plain addItem method and you still want to retrieve
them using square brackets. You can do this, but first you have to decide which properties should be
the keys that references to the object. Below is an example for more clarity.

// here I declare an empty DictionaryCollection and set the label property as a key field
var a:DictionaryCollection = new DictionaryCollection(null,"label");
a.addItem({label: "Bread", price: "2", quantity: "1"});
a.addItem({label: "Butter", price: "3", quantity: "2"});
a.addItem({label: "Tea bags", price: "1", quantity: "4"});
a["Jam"] = {label: "Jam", price: "4", quantity: "1"};
// now I can retrieve each object based on its label
trace(a.getItemByKey("Butter").price);   // 3
trace(a["Tea bags"].quantity);             // 4
trace(a["Jam"].label); 			     //	Jam

I hope this code snippet explains pretty well how a DictionaryCollection can be used and you can download it following the link below. I also included the test class for unit testing.

DictionaryCollection

As a conclusion, I’m happy that reading the source code of Flex saved me hours of work and helped me to build a custom data type that should blend seamlessly with the framework.

The  model is the central part of any MVC application.  But what exactly the models are? Simplistically,one can see the model as  database schemas plus some data structures that reflect data from databases at runtime.

I have tried this “simple” approach in the past frameworks (even in Quark 1.0) and we used classes that mimics the usual OOP classes that languages as Java or Action Script provides by default.  In Quark 2.0 we have created a new XML based, OOP language that we call Quark Schema that is providing support for nice and useful models:

• declaratively describe the persistence and the life of the objects
• declaratively describe the constraints, validation and relations between model’s objects
• describe class behavior
• is fully editable using GUI tools that we are currently building

We found that we can discern 6 categories of objects (they are not orthogonal categories ):

• transient objects – objects that exists only at runtime in one instance of the application and should not be saved in a persistent storage
• globally persistent objects: objects with global identity (even for different users )
• locally persistent objects : objects that have no global identity but have a local identity inside of a global or transient object
• relational objects – objects that mimic the structure of relational tables
• document objects – graph of objects that contain other objects
• shadow objects -objects that doesn’t contain user data but inner information of the system.  Example of shadow objects : configurations and the structure of the view. Shadows get automatically generated and one  is doing customization by using visual tools organically embedded in the application but it doesn’t care much about shadow’s structure.
  
  Observations:
• Global objects that contains other local objects (or are persistence roots for graph of objects as we call it ) should be seen as complex documents structured as graphs that can be used as configurations or data structures. Quark Framework allows you to describe models in the form of normal “relational” objects or in form of  ”document” objects.
• Document objects can be seen as relational objects with fields that are root for trees containing local objects  serialized as XML strings.
• Shadow documents are usually document objects.
• Transient objects can be global or local
• Members of classes can be declared  transient and will not be present in the database schema but their values get serialized depending of their declaration as  local,global( or created as transient objects or no)
• We have discovered that local objects have an interesting property: when they are assigned to a member of a class member from a different persistence root (different persistence global root object) they should be automatically cloned.   Quark Schema is automatically doing just that and we discovered that is nice and useful in real cases.

Apparently all these rules and observations are a bit complex, fortunately the business user will use a simple UI to create such classes (models) and should not worry much about persistence aspects.  It will just communicate his intentions and the system will do “the magic”. Local objects are usually shadow objects and will be a concern for component creators and rarely for the business users (customers or consultants).

This article is long enough so I will not present  any syntax but I want to mention only that for Quark 2.0 we have got all these aspects working and well tested with unit testing.  Drop me an email for any questions.

At the end, take a look at this picture that is saying: “the model should be fat but it should be constructed with skinny,elegant and nicely shaped classes”:

Creating  above picture piece by piece is  a laborious process. For me, it took 1 minute to create using Google search for images and a screenshot. Similarly, our goal is to create a tool that  will allow  creation of a working business application in minutes and we believe that we are not far from it! A new direction I’m contemplating now is to have  Quark Framework  as a tool for creation of mashup applications [1] with data from multiple business applications. It is a logical use of Quark and fortunately it results from our design,without much supplementary programming work.

References:

[1] http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

We are happy to make a public release of Quark Framework 1.0.

For the last couple of  months we have been working on Quark 2.0 and we’ve decided to have Quark Framework 1.0 released under LGPL license.

Quark RAD Framework comprises two key components – a core library written in Java  (which provides the basic server side persistence and authentication  services that are required by most applications) and a set of flex classes so developers can easily use to rapidly engineer UI of the applications.

As we are working for 2.0, we discontinued support for 1.0 (except fixing things required for applications we build with 1.0) On the other hand, if you are a good Java and Flex hacker you could find good piece of code to reuse in your applications.

Documentation for 1.0 is scarce as we focus on explaining and documenting 2.0.

Download Source |  Binary

In the quest for eliminating all unnecessary barriers in having ultra rapid application development we realized that the save button is sometimes quite Evil. For web applications the Save button is somehow inefficient and could lead to confusion and loose of data because of browser crushes,network errors,user mistakes. The save button is also increasing the complexity of the system. Many hardcore programmers will say that it is not much but our framework wants to allow even non-programmers to create working applications with an effort equivalent with that of creating a spreadsheet.  We think that the approach of periodic auto-saving is the way to go in Quark for  almost all cases.

If the framework provides cheap (or free)  undo,redo operations for all operations that users can do,naturally that we can have nice applications without the “save button”.

What “save button” provides and “workarounds” could be required:

• the biggest issue: workflow and integration with process management capabilities. If a user is just playing with data in UI,could trigger workflow changes unintentionally. Business application that have workflows are normally used by serios people that will not just click randomly and press keys,but still, this could be a problem.
• protection for “cat” operations – if a user is just playing with his keyboard or a cat is walking on it,bad data could find a way to the database
• implementation of atomic changes:provide consistent persistent storage.  In some cases,changes in a part of an object without changing other parts will lead to an invalid states of the object. This problem will be avoided with a validation, Quark Framework will not auto-save invalid objects.
• implementing transactional operation for graph of objects will require additional,a bit more complex validation

I think that cases that will require a higher level of validation,could have a standard “validate change” button or “apply” button in the UI and the “auto-save” will not save those objects that are not manually validated.

Quark framework 2.0  provides for free (almost) undo,redo and auto-save. These features were not present in Quark 1.0.   So,what do you think?  Do you really need to put users pressing the “save button” after each important change ?