Archive for the 'Declarative Programming' Category
IronRuby aka Ruby.NET Pre-Alpha Release 
July 29th, 2007
About a week ago Scott G over a MS blogged about the pre-alpha release of IronRuby. Very cool stuff.
For those that don’t know, IronRuby and friends (IronPython, JavaScript, Dynamic VB) is a project that is, like JRuby for Java, enabling Ruby to run on top of the .NET Framework. This means that your dynamic Ruby script can also have access to all the underlying .NET goodness (and badness). It will be very interesting to see how the performance is.
It is also really cool that they are doing Python and JavaScript as well. It’s like Phobos and JRuby all in one neat little package with a dash of python for good measure. Oh have I forgotten one of the languages? I can’t help but laugh when I see Dynamic VB.
Here is a code snippet from Scott’s post with some Ruby script using WPF - pretty cool stuff!
Posted in Uncategorized, Declarative Programming, Components | No Comments »
Declarative Ajax and Flex Interop
July 3rd, 2007
This is some code that I wrote about a year ago at the Flex Component Developers Summit (and more recently presented at XTech) to show how declarative Ajax and Flex can work together to create dynamic, rich and compelling Internet applications.
The idea is simple. Take a single declaration - in this case XHTML - of some user-interface component and then use it to build a UI using either Ajax or Flex. All this from just one declaration.
What happens is that we take a single declarative data grid and converts it using XSLT on the client (so it only works Firefox, IE and soon Safari) into a declarative Nitobi Ajax Grid and to a Flex declarative MXML DataGrid. I use the FABridge to get the string of MXML generated from the XSL transformation into a stub Flex application where a Flex DataGrid is instantiated (deserialized) from the MXML declaration. It can an be seen live here (note: create the Flex grid first then the Ajax one - something funny that I can’t be bothered to fix 
) and the code can be downloaded from here.
So by using a declarative approach and a little XSLT on the client we were able to quickly choose between using a Flex DataGrid or a Nitobi Ajax Grid to display our tabular data in!
Really the most interesting part is the MXML deserialization stuff. The only contents of the Flex application are two functions for performing the deserialization. I have listed the main part of the code that takes an XML document of an MXML DataGrid declaration and actually instantiates a DataGrid according to that declaration. It’s pretty quick and dirty but at least gets the right thing out! Essentially it just looks at each XML element and creates an Object out of it and sets all the properties on it from the XML element attributes and then recurses through the child elements doing the same. There are some special attributes though like datasources that need a little more care.
public function initGrid(html) {
// setup a tagname to datatype hash - maybe this already exists somewhere
controls['DataGrid'] = 'mx.controls.DataGrid';
controls['ArrayCollection'] = 'mx.collections.ArrayCollection';
controls['Object'] = 'Object';
controls['columns'] = 'Array';
controls['DataGridColumn'] = 'mx.controls.dataGridClasses.DataGridColumn';
// load the HTML into XML DOM
var mxml:XML = new XML('<root>'+html+'</root>');
parseXml(AjaxBox, mxml);
}
public function parseXml(parent, mxml) {
var item:String;
// get all the elements in our XML doc - this should of course walk the xml tree recursively
var itemList:XMLList = mxml.elements('*');
for (item in itemList) {
// get the tag name of the XML node
var tagName:String = itemList[item].localName();
// get the class by using getDefinitionByName() method
var ClassReference:Class = Class(getDefinitionByName(controls[tagName]));
// create an instance of the class
var myObject:Object = new ClassReference();
// get all the attributes and set the properties
var attrList:XMLList = XML(itemList[item]).attributes();
for (var attr:String in attrList) {
myObject[attrList[attr].localName()] = attrList[attr].toString();
}
// now parse the children of this node
parseXml(myObject, itemList[item]);
if (parent.hasOwnProperty(tagName)) {
parent[tagName] = myObject;
} else if (parent.hasOwnProperty("length")) {
if (parent.hasOwnProperty("source")) {
parent.source.push(myObject);
} else {
parent.push(myObject);
}
} else if (parent.hasOwnProperty("dataProvider") && tagName == "ArrayCollection") {
// This means we need to create a datasource for the Grid
parent.dataProvider = myObject;
} else {
parent.addChild(DisplayObject(myObject));
}
}
}
Posted in Web2.0, AJAX, XSLT, Flash, Flex, Declarative Programming, Components, Grid, RIA, FABridge | 1 Comment »
Declarative Google Maps
April 7th, 2007
We are pretty big fans of the declarative approach to Ajax. Our up and coming Complete UI Ajax component product line is firmly based around declarative programming. The idea behind this is that the developer can use HTML like markup to define the majority of the component functionality while still being able to write a little bit of JavaScript to get the extra 20% of custom functionality that they need.
As an example of this I have put together a declarative Google Map. Currently it only supports a few declarative tags but it at least serves to give you an idea of how a regular JavaScript component could be wrapped declaratively. It could also be simplified quite a bit by building a JavaScript component from the ground up with declarative programming in mind - as the Nitobi framework enables of course 
If you went about putting a Google Map into a web page imperatively, it would look something like this:
var map = new GMap2(document.getElementById("map"));
map.setCenter(new GLatLng(49.290327, -123.11348), 12);
var polyline = new GPolyline([
new GLatLng(49.265788, -123.069877),
new GLatLng(49.276988, -123.069534),
new GLatLng(49.276988, -123.099746),
new GLatLng(49.278108, -123.112106),
new GLatLng(49.2949043, -123.136825),
new GLatLng(49.3029641, -123.145065)
], "#ff0000", 10);
map.addOverlay(polyline);
The result of this is a nice Google Map that shows part of my daily bike ride to work. If you view the source of the web page you will see just that same code.
On the other hand, we could make that same web page declaratively meaning that we don’t have any extra JavaScript code to write but instead define our Google Map through custom HTML markup. This has the advantage, on top of the many advantages (and disadvantages) of declarative programming in general, that most web developers are familiar with HTML markup though might not be as comfortable with writing JavaScript code. So the equivalent declarative Google Map might look like this:
<g:map id="map" width="370px" height="380px" smallmapcontrol="true" maptypecontrol="true">
<g:center zoom="12">
<g:point lat="49.2853" lng="-123.11348"></g:point>
</g:center>
<g:polyline color="#FF0000" size="10">
<g:point lat="49.265788" lng="-123.069877"></g:point>
<g:point lat="49.276988" lng="-123.069534"></g:point>
<g:point lat="49.276988" lng="-123.099746"></g:point>
<g:point lat="49.278108" lng="-123.112106"></g:point>
<g:point lat="49.294904" lng="-123.136825"></g:point>
</g:polyline>
</g:map>
All the same elements are there as the imperative JavaScript version but there is no code to worry about. And, of course, the result is also the same. Here is a direct link to the source code - the top 1/3 of the code is the only interesting stuff, the rest is just helper functions that poached from the Nitobi Ajax Toolkit.
Take a look at the source code if you are interested in the details. Btw it currently has only been tested in Firefox 1.5 and IE 6/7.
This will be some of what I talk about in my session at XTech.
Posted in Web2.0, AJAX, XML, Declarative Programming, Components, Google, Map | 3 Comments »
Complete UI JSP Taglib
April 5th, 2007
We’ve had a number of customers request a JSP Taglib for our components and we can finally say here it is in all its fabulous glory - thanks to the great work of Mike. A nice thing with the taglib is you don’t have to worry about including the required javascript and stylesheet files, which I hope will be a boon for those using templates. The tag will automatically add the needed scripts and styles to your page (but you can use the toolkitjsurl, componentjsurl, and componentcssurl attributes to change where to find them). Plus, you don’t have to worry about forgetting the namespace declaration - shock horror! And of course, in Eclipse (and no doubt other IDEs) you get good ol’ code completion for free. Huzzah.
Like any other taglib, just put the jar file in your WEB-INF/lib and include it in your web.xml file, like so:
<jsp-config>
<taglib>
<taglib-uri>http://www.nitobi.com</taglib-uri>
<taglib-location>/WEB-INF/lib/nitobi-cui-taglib.jar</taglib-location>
</taglib>
</jsp-config>
Suggestions are, of course, very welcome. So pipe up if you’ve got some in the comments below or on the forum! We’d love any sort of feedback about the taglib and more generally how you think we can improve our components for use in a Java EE environment.
Next in the pipeline is integration with Eclipse and Netbeans and we’ll also have some tutorials detailing how to use our components in Struts and Spring real soon.
Posted in Web, AJAX, Declarative Programming, Components, completeui, jsp | 5 Comments »
XTech 2007 - Declarative Progamming
March 11th, 2007
It looks like I will be in Paris to give a presentation at XTech 2007 (May 15-18).
I will be talking about declarative approaches to Ajax and looking at some of the important cross browser issues that may be encountered. I will also give a quick high level overview of some of the important declarative languages that we can use for guidance and inspiration.
Ping me if you will be in Paris during that time - I will also be spending a little time in London around then as well.
Posted in Web2.0, AJAX, Declarative Programming, Nitobi, Conference, xtech | 1 Comment »
XML vs JSON: A Second Sober Look
January 8th, 2007
There has been a recent fleury of discussion about XML vs JSON. What a great topic for the holidays.
Although I have been talking about this topic for some time, some XML bloggers have recently started to discuss the topic (Tim Bray, Don Box, David Megginson, Dare Obsanjo and all the comments). For the most part the discussion is pretty tame and nothing really new.
Tim brings up the good points about extensibility and encoding. He also importantly acknowledges the fact that JSON is applicable in certain cases. To his points I would add the fact that one is able to use XPath with XML making it very powerful for quickly finding data. XPath is one XML technology that many ignore, particularly in the JavaScript sandbox.
The other important points are really in direct response to Dare Obsanjo’s posts from last week: Browser Security Model and Browser Programming Model. First of all, Dare suggests that one reason for JSON being so popular is due to cross-domain JSON (also called JSONP or JSON with Padding). Ignoring the data format, this pattern is applicable to any kind of data, including XML (XML with Padding is equally valid). There is no reason that Yahoo! could not provide a cross-domain XML API along side a cross-domain JSON API. In fact, I urge people to email everyone they know over at Yahoo! to do so for all their properties such as del.icio.us.
There are also a few points I have in response to the second post about the difference between the programming models of JSON and XML. The main thing that I noticed is that the example presents is not a realistic use case. What is most commonly done with data in an Ajax application is that the data is rendered to HTML. The fastest way to render data to HTML is using XML and XSLT. The other thing that he does not look at is cases where the data needs to be sorted or filtered, in which case XML and either XSLT or XPath provide a very nice solution. Of less importance, Dare also states that one should use a JSON parser in case of security concerns, however, the JavaScript based JSON parsers that I have used have had very extremely poor performance - even worse than plain eval().
The other interesting thing was a comment made by Kevin Hackman from TIBCO in the Ajaxian post. Kevin mentioned the fact that TIBCO uses XML to maintain the JavaScript state - i.e. each JavaScript object has a related XML document where the the object properties are stored and accessed using standard JavaScript accessor methods - which helps in terms of application memory usage. This is something that the soon to be released Nitobi Complete UI Framework also does, although for slightly different reasons like the fact that objects can then be easily serialized for use with server frameworks like JSF or ASP.NET.
At any rate, I am happy to see that some others are joining in on the discussion and if nothing else I hope that people start to talk more about using XSLT and XPath in the browser.
Posted in AJAX, XML, XSLT, Declarative Programming, Performance, markup | 7 Comments »
Flex Ajax Dashboard
October 17th, 2006
We have just made a quick Flex/Ajax dashboard to show how Flex and Ajax can work together to make a very compelling user-interface for something like a corporate information dashboard. You can check it out the demo here and an article about the demo here.
Using the FABridge along with the Nitobi Ajax Grid and Adobe Flex Charting, we have created a scenario where one can view monthly sales data and then see the sales details for the month in both a tabular format in a grid and visually represented in a Flex chart.
Under the hood we have used PHP and MySQL to provide the data to both the data grids and the chart. When a user clicks on a record in the sales data grouped by month, the details grid makes a request to the server for all the sales data for that month - this ends up being between 200 to 1000 records or so. To ensure that the details grid is still fast, we only render the part of the dataset that the user is looking at rather than rendering all 1000 records say, which can take a long time when you use the DOM
innerHTML
property. The other thing that happens when a month is selected in the master grid is that the Flex chart is also updated with information about the sales for that month, except that the sales data is then grouped by day. Grouping of the sales data could either be done on the client or the server, however, since we have already retreived all the sales data for the month and displayed it in the detail grid we simply take that same data and group it very quickly using an XSL transformation (yes currently only IE and Moz but the latest Safari build also has it - finally!). The grouped data we output from the XSL transformation is actually formatted as JSON which is then evaluated into a JavaScript object and passed to the Flex chart for rendering. The grouping XSLT is pretty simple and uses the
Muenchian method:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:ntb="http://www.nitobi.com">
<xsl:output method="text" encoding="utf-8"/>
<xsl:key name="sales-by-day" match="ntb:e" use="@h" />
<xsl:template match="/">
[<xsl:apply-templates select="//ntb:data" />{}]
</xsl:template>
<xsl:template match="ntb:data">
<xsl:for-each select="ntb:e[count(. | key('sales-by-day', @h)[1]) = 1]">
{'totalSales': <xsl:value-of select="sum(key('sales-by-day', @h)/@i)"/>,
'day': <xsl:value-of select="@h" />,
'month': <xsl:value-of select="@f" />,
'year': <xsl:value-of select="@g" />},
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
We have also hooked up a few other events so that the chart will be updated when changes to the data in the detail grid are made.
All in all, by using the FABridge to move data to and from a Flex chart we can create very compelling and ultimately very useful dashboard type of application by merrying the Flex and Ajax technologies.
Posted in Web2.0, AJAX, Flex, Declarative Programming, Components, Nitobi, RIA | 11 Comments »
Declarative AJAX Components and XML Namespaces
October 16th, 2006
Being on the OpenAjax committee has been pretty interesting so far despite the fact that I have only managed to be in on one call - luckily all the minutes are on the wiki and I have been following that pretty intently.
The declarative markup comittee is looking at how to standardize the definition and instantiation of declarative AJAX components or widgets. A good example of a complex component is the Nitobi Ajax Grid component while the Dojo framework has several smaller widgets like the very cool fisheye menu. To create an Ajax widget in a web page declaratively one might have some markup like this:
<ntb:grid ... />
Similarly, one could use something like this:
<div oatype="ntb:grid" ... />
This is very similar to the idea of microformats - and even makes them more expressive. In either case the OpenAjax bootstrapper would start using something like the
onload
event on the
window
object and it would search through the DOM and find all elements with a custom namespace or an
oatype
attribute. Once the bootstrapper finds a component declaration it refers to a registry to find the toolkit that is responsible for parsing and loading that specific component from the declaration. Personally, I like the former with the custom tag that is properly namespaced.
Unfortunately, IMHO, people generally opt for the later declaration that uses the build in HTML elements and simply adds custom attributes. While both are nearly identical, the use of namespace prefixes on the tags is possibly more “standard” and ensures that one doesn’t get a Grid component mixed up with a regular DIV element. For the most part, I think the gravitation towards the later declaration is due to the general contempt people hold for Internet Explorer - and indeed most of the people on the declarative markup committee feel this way. Having been building declarative components for Internet Explorer for over six years now we are pretty well versed in the problems with Internet Explorer, and I can assure you that the support for XML namespaces and custom tags in Internet Explorer is perfectly fine. I would argue, as you will see in a moment, that the support is even better in Internet Explorer than in Mozilla. Some Ajax frameworks, such as Dojo, support XML namespaces in Mozilla but not in IE due to perceived deficiencies.
From our experience, Firefox and not Internet Explorer has been the browser that breaks when custom namespaced tags are used. The biggest hurdle is that, as noted in the Dojo manual page that, one “must” (emphasis on the part of the author of the Dojo manual) define the xmlns:mynamespace on the page. Usually that is done on the HTML tag. Anyone that has worked with XML will surely know that if you want to have some elements in a different namespace then declaring that namespace is a fact of life. On the other hand, Firefox works in a quirky way if you define custom XML namespaced tags - forgetting the fact that it doesn’t even care if you define the namespace or not, which seems very bizarre to anyone familiar with XML. For the straight dope on custom tags in IE everyone should check out the relevant MSDN article (it is amazing all the good stuff on MSDN that many people ignore). The jist of the article is that you just need to specify your XML namespace on the HTML element like this:
<html xmlns:mynamespace>
How completely unexpected! However, it can also be specified on any other element that is a parent of an element that uses the namespace. The article describes the fact that support for custom tags was introduced for enabling behaviours - ie defining custom HTML elements that behave in some custom way - which were a great idea. Admitedly, the one drawback of the IE model is that it does not support the
document.getElementsByTagNameNS()
method, which can select tags with a namespace in Firefox. Instead one has to use the regular
getElementsByTagName
method and look at the namespace value. This is easily wrapped of course.
Having said all this, one should also remember that XHTML is not really there yet.
At any rate, we still want to use XML namespaced tags and there are a few problems we have found with Firefox regarding support for custom XML namespaced elements. The two main problems we have observed are:
Styles are not applied correctly
DOM methods do not work correctly
Self closing tags do not work
To illustrate this, I have made a simple example with some sample markup that might be used in some sort of windowing or panelling situation. I defined some buttons, panels and a title with some interspersed native HTML elements.
<div id="div1">
<ntb:button id="button1">button 1</ntb:button>
<ntb:button id="button2">button 2</ntb:button>
<ntb:panel id="panel1">
<ntb:title id="title1">
<div id="div2">panel title 1</div>
</ntb:title>
<ntb:contents id="contents1">
<div id="div3">Contents div3</div>
<div id="div4">Contents div4</div>
</ntb:contents>
</ntb:panel>
</div>
One common thing to do is define some custom styles for these elements such as this:
ntb\:panel {border:1px solid red;display:block;}
ntb\:contents {color:red;display:block;}
ntb\:title {border:1px solid black;background-color:#3366FF;display:block;}
ntb\:button {border:1px solid black;background-color:#CCCCCC;}
The results are fairly good in IE:
and pretty poor in Mozilla:
Granted that is quite contrived and the likelyhood of specifying styles for the custom elements is pretty low.
This brings us to the second point which is a bit more important. The native DOM methods in Mozilla don’t actually recognize the custom elements; or rather, to be more precise, DOM methods don’t reflect the true DOM hierarchy as it appears in your HTML. As an example, we will try and access the parent node of each of the nodes in our sample custom namespaced HTML. The results were as follows:
IE parentNode()
| Target Node ID |
Expected Parent ID |
Actual Parent ID |
| title1 |
title1 |
title1 |
| contents1 |
contents1 |
contents1 |
| … |
… |
… |
| ok you get the idea |
Mozilla parentNode()
| Target Node ID |
Expected Parent ID |
Actual Parent ID |
| div2 |
title1 |
div1 |
| div3 |
contents1 |
div1 |
| div4 |
contents1 |
div1 |
| button1 |
div1 |
div1 |
| button2 |
div1 |
div1 |
| panel1 |
div1 |
div1 |
| title1 |
panel1 |
panel1 |
| contents1 |
panel1 |
div1 |
Internet Explorer gets the parentNode as one would expect but Mozilla seems to have some difficulty. There are similar difficulties with many other of the DOM methods in Mozilla.
The big problem we have found is that Mozilla does not support self closing tags. One would expect that the following would be equivalent:
<ntb:grid />
<ntb:grid></ntb:grid>
Not so in Mozilla. The later syntax is ok, whereas the self closing tag does not get parsed correctly when you look at the innerHTML of an element and it is even worse once you have self closing tags in conjunction with DOM methods.
Mozilla has to get its act together with custom namespaced tags for declarative AJAX components to ever get anywhere. If anyone wants to compare war stories then please leave some comments.
Technorati tags:ajax, microformat, declarative, components, xml
Posted in Web2.0, AJAX, XML, Microformat, Declarative Programming, Components | 14 Comments »
Nitobi Grid Launch Date
September 7th, 2006
Ok so we have set a date of Sept 14 for launching the latest version of our Grid control. Given some quality control issues in the last release we are trying to tighten her down and get her ready to work nicely with our framework. Best of all the docs will be kick ass
Once we launch then I can get my GMaps mashup online too!
Posted in AJAX, Business, Declarative Programming, Grid | No Comments »
JavaStudio Creator Webinar Online
August 28th, 2006
A few weeks ago we did a short webinar with Sun to show off our Ajax Grid component in JavaStudio Creator (JSC). It lets a developer use all the nice visual aspects of JSC with the power of Ajax!
Check it out.
Posted in AJAX, Declarative Programming, JSF, NetBeans | No Comments »
Entries (RSS)
and