xJAML

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 is Ruby library for imperative generation/programming of HTML pages.

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 tranformations 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” ;)

Examples

A proverbial “hello world”. Deliberately not the most minimal version :

<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>

Tranformed into xJAML:

{ 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 */

Discussion

Not a very convincing example for xml 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 afficionado knows straight away how impossibly easy is to use this in JavaScript. And in the case of existence and usage od server-side JavaScript how efficient this becomes. But this is not the end of usability (superiority?) of xJAML. Add to the server-end of xJAML solution, something like Couch DB, and the whole solution becomes (I think) really superior. CouchDB front is JavaScript+JSON so xJAML will be naturally flowing in and out of database like CouchDB.

In this scenario we have xJAML (aka JSON) all the way from the data back end to the browser based front end. And back. 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 an very nice multilayered cake.
Classical solution from back to front: Browser HostXPATH+JavaScriptTransform SQL to XMLSQL DB
AJAX classical solution from front to back: Submit HTML formJS transform to XMLTransform XML to SQLSQL DB
Please note that above, both server side tranformations required are by no means trivial, neither in complexity or time required. Client side transformations are taking time too, and are slightly less complex just because JavaScript is used. Major complexiti factor here comes form paradigm shitifing between different data format 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 sie and (for example) C# on the server side.

And now for something completely different:

xJAML solution from back to front: Browser HostServerSide JSJSON DB
AJAX xJAML solution from front to back: Submit HTML formJS transform to JSONPass to JSON DBJSON DB

Here the server side code is done in JavaScript and does not involve any transformations form/to different message/data structures. If the JSON DB, would be “Couch DB” (for example) this server side code will be an Couch DB API usage, which aggain is JavaScript. So no complex paradigm shitfting between languages and/or data formats. Vs classical example here we have ONE langage and ONE data format.

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 DOM+JavaScript. Here JavaScript library will be used to do client side transofrmation from xJAML to DOM, and all the other AJAX 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 exisitng efforts of JAML and simillar JavaScript libraries.

Summary

And this is all for today. XAML is today natively supported by IE, sam as XUL is supported by FireFox. Although XAML goes far beyond that. XAML is Microsofts UI of the future. The whole future Windows front end will 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” developing “xJAML host” which will be capable of interpeting and displaying whatever is in the xjaml file?

Just double click on the first.xjaml on you desktop ;)

–DBJ

This entry was posted in Filosofia, IT. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>