Extended Json Application Markup Language, aka xJAML
Idea is to implement XAML in JSON. Declarative application UI description and application programming.
Name “JAML” is already (sort-of-a) taken by Ed Spencer’s JAML . Which is a bit unfortunate since it is a very nice acronym. JAML is far less ambitious, it is “only” an javascript library. An imperative “way of doing things”. There is also “HAML” which again was originally implemented as Ruby library for imperative generation/programming of HTML pages. Today we have HAML.JS too.
xJAML is not a “library” it is protocol language. Just like JSON is. But extended for GUI declaration/definition. Just like XAML is.
xJAML = JSON + XAML
Ok, but what about XUL ?
XUL (pronounced “zool”) is Mozzila UI declaration language. Conceptually exactly the same as XAML. Therefore XUL is an application of XML. In fact, it is just XML with specific meaning defined for a few element types, and into which HTML can be scattered. FireFox is XUL host. FireFox is XUL application.
xJAML is not XML. xJAML is JSON. xJAML is declarative. Conceptual purpose of xJAML is exactly the same as XAML or XUL. One of the key requirements for xJAML is that every XAML can be re-done in xJAML. Thus yielding the same advantages as any other transformation of XML to JSON does: smaller messages and (far) simpler transformations and scripting than XSLT allows.
XML+XPATH+XSLT is far less usable than JSON+JavaScript, combination. Maybe this is why XSLT is consipiciously missing from XAML documentation and examples. I can not remember seeing any XSTL+XPATH applied to XAML or XUL? It is certainly doable but definitely a bit of a “sado-masohistic programming”, for those among us, who “like pain” ;)
Example
A proverbial “hello world”. Deliberately not the most minimal version . First the XAML syntax:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" Name="dbj" Width="400" Height="400" Background="{x:Static Brushes.Silver }" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> <TextBlock Canvas.Left="10" Canvas.Top="10" Name="TextBlock1" Width="277" Height="53" FontFamily="Verdana, Tahoma, Arial" FontStyle="Italic" FontWeight="Bold" FontSize="25" Foreground="{x:Static Brushes.Maroon }" Text="Hello World!" /> </Canvas> |
The XAML above when tranformed into xJAML, looks like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
{ Canvas : { xmlns : "http://schemas.microsoft.com/winfx/2006/xaml/presentation" , Name : "dbj" , Width : "400", Height : "400" , Background : "{x:Static Brushes.Silver }" , "xmlns:x" : "http://schemas.microsoft.com/winfx/2006/xaml" , TextBlock : { "Canvas.Left" : "10" , "Canvas.Top" : "10" , Name : "TextBlock1" , Width : "277" , Height : "53" , FontFamily : "Verdana, Tahoma, Arial" , FontStyle : "Italic" , FontWeight : "Bold" , FontSize : "25" , Foreground : "{ x:Static Brushes.Maroon }" , Text : "Hello World!" } } } |
Discussion
Not a very convincing example for x(a)ml zealots? This is because it is very simple xaml with no open/close tags. It also contains xml artifacts like namespace declarations which are not necessary in xJAML . But of course, every XSLT+XML aficionado knows straight away how impossibly easy is to use this in JavaScript.
And in the case of the existence and usage of server-side JavaScript how efficient this becomes? But this is not the end of the usability and superiority of xJAML. Add to the server-end the xJAML solution, something like Couch DB, and the whole solution becomes (I think) really superior. Couch DB front is JavaScript+JSON, so xJAML will naturally flowing in and out of a database like Couch DB.
In this scenario, we have xJAML (aka JSON) all the way from the data back end to the browser-based front end. And back again.
Compare this to the “classical” solution using SQL in the back, and XML messaging and/or XAML. And something like C# (or C++) components sprinkled on top of this. Not a very nice multi-layered software cake.
Thus the classical solution from back to front transformation chain is :
|
1 |
Browser ← T1(JS to HTML) ← T2(SQL to XML) ← SQL DB |
And the classical solution transformation chain from front to back:
|
1 |
HTML form→ T3(JS to XML)→ T4(XML to SQL) →SQL DB |
Please note that above, both server-side transformations, T2 and T4, are by no means trivial, neither in complexity nor time. Client-side transformations are taking a time too, and are slightly less complex just because JavaScript is used.
The major complexity factor here comes from paradigm-shifting between different data formats and different languages. Actually, there are no less than three (!) different data formats in action here: SQL, XML, and JSON. And two languages: JavaScript on the client side and (for example) C# on the server side.
And now for something completely different. xJAML solution, transformations chain, from back to front:
|
1 |
Browser ←ServerSide T1(JS to HTML)←JSON DB |
And the same solution from front to back:
|
1 |
HTML form→Server side: T2(JS to JSON)→JSON DB |
Here the server-side T2 is done in JavaScript and does not involve any transformations from/to different message/data structures. If the JSON DB would be “Couch DB” (for example) this server-side code will be a Couch DB standard API usage, which again is JavaScript. So no complex paradigm shifting between languages and/or data formats.
The biggest win is that unlike the classical example here we have ONE language and ONE data format.
Perhaps you might have noticed. The two diagrams/examples above actually do not use xJAML. They are showing JSON vs XML advantages. Still, they are very valid here because xJAML is nothing but a form of JSON (to be) used for browser host UI declarations and programming. Which boils down to the standard DOM+JavaScript combination.
Here JavaScript library will be used to do the client-side transformation from xJAML to DOM, and all the other browser side App parts. Where only the xJAML to DOM part of this activity is a new concept. Although not that “new” at all, if we (re)consider already existing efforts of JAML and similar JavaScript libraries.
Summary
XAML is today natively supported by IE browser, the same as XUL is supported by Firefox. Although XAML goes far beyond that. XAML is the Microsofts UI of the future. The whole future Windows front end might be XAML. Double-click on XAML file on your Windows desktop and OS will pass it to the “Windows Foundation Presentation Host” registered. Which (today) by default is IE. XAML “decoding” is actually mostly implemented in C# inside .NET, which is using DirectX in turn.
xJAML is not supported by anything today. So why not “just” develop “xJAML browser” which will be capable of interpreting and displaying whatever is in the xjaml file?
Just double-click on the first.xjaml on your desktop and boom, it is displayed in your xjaml browser ;)