Organic Programming

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.

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 ?