Organic Programming

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.