m|dsl is a new kind of programming language, a solution programming language (SPL). It focuses on describing a solution in a technology and architecture independent way.
At Canappi we believe that information system construction should be simple. Developers and architects should be allowed to spend more time with domain experts to understand their requirements and deliver the best solution possible, as fast as possible.
m|dsl does not aim at making problem domain experts "developers". Some domain experts may be also be able to build some parts of the solution, but in general they prefer focusing on their domain. Hence m|dsl is above and beyond a programming language.
However, it is very different from a general purpose programming language in the sense that it offers solution concepts, at the language level. With m|dsl, developers and architects don't have to reinvent the wheel or rely on a large number of low level patterns such as MVC or delegate pattern which are core to the iOS programming model.
You can create a mobile application in five easy steps:

An m|dsl application descriptor starts with a main statement. The example below indicates that the application has a navigation bar, it will start on the homeView and displays a menu containing a couple of views.
main wikityo {
navigationBar ;
start homeView ;
menu {homeView, settingsView}
}
A view represents the unit of interaction. The view below is using user defaults parameters which are dynamically bound to its controls. Controls are generally defined in a layout, which is a unit of reuse of a group of controls. A layout can be bound to a data "connection" with the bindings element. A bindings element is usually complemented with a mapping element that defines how the data connection parameters are bound to the layout controls.
view homeView 'Wikityo' uses user defaults {
color groupTableViewBackground ;
controls {
layout wikityoHome
bindings myHomework
mapping homeMapping;
}
}
A layout is a simple definition of a group of controls. Some controls may be assigned an action (which would require some custom code) or use a standard action such as "navigate to" another view. The frame of a control is defined by a tuple (x,y,width,height). When parameters are unchanged from a frame definition to another, they don't need to be repeated: (100, 50 , 100 , 30) defines the first control frame, the second definition is (, 130 , , ) which is equivalent to (100, 130 , 100 , 30 ). That way, groups of controls can easily be repositioned by changing a single value.
layout wikityoHome {
image studentImage (10,10,70,70) {
'defaultStudentImage.png';
action changeImage navigate to settingsView ;
}
text nickName (100, 50 , 100 , 30) {
backgroundColor clear ;
Left ;
readOnly;
}
label latestAssignmentLabel 'Your homework: ' (30, 100, 250 , 28) {
Left ;
}
text latestAssgignment1 (, 130 , , ) {
Left ;
border bezel ;
}
text latestAssgignment2 (, 160 , , ) {
Left ;
border bezel;
}
label statsLabel 'Assignements completed this month: ' ( , 200, , ) {
Left ;
}
text stats (, 230 , , ) {
Left ; readOnly ;
border bezel ;
}
text average (, 260 , , ) {
Left ;
readOnly ;
border bezel;
}
}
Last, but not least, views are bound to "connections". Connections are a series of HTTP based operations which may accept a series of parameters and return a JSON or XML based response (default is XML). Connection's parameters and response elements can be mapped to the controls using a mapping element.
connection {
operation init getMyHomework GET 'http://www.mydatasources.com/homework.php' email
}
mapping homeMapping {
{ 'latestAssgignment1' : 'tag2' },
{ 'latestAssgignment2' : 'tag2' }
} ;
That's pretty much it, assuming that your data services are already available. You have just defined a fully functional application. m|dsl also includes a set of constructs to generate the PHP code and MySQL schema based on "entity" definitions.
Simply upload your mdsl file here