Just thinking out loud and sharing some ideas. The reason i'm doing so is to get feedback on twitter or through comments. I have no clue yet how powerfull existing widgets out there currently are so i'd like to get more insight from people who do. And i think the high level ideas from below widget definition speak more then words.
Wednesday, November 30, 2011
Tuesday, November 29, 2011
Higher order declarative XML and dynamic XSLT
I've been playing with the idea that when you hook a few advanced technologies together you could build some nice stuff. The things that came to my mind are:
The idea I had in mind was to create reusable widgets and I've been reminded today that such things are already in the market. However, it's hard for me to compare ease of use, performance and usability for commercial businesses. In the meantime I started experimenting a bit and came up with the following widget which basically generates the same output (table containing tweets for particular person) as in my previous article. However, in the previous article no higher order XML declarations were used. I think you will see that with some XSLT magic you get a lot done with a few lines. It took some time to get it working properly but the table widget now takes an @data-source which you can bind to any table:component.
By the way, with higher order declarative XML i am referring to the analogue higher order functions like e.g. MAP / REDUCE, FOREACH. As you can see from the sample below, a single table:row instruction can actually be seen as a function which maps a sequence (of nodes selected with the @bind) to table:rows.
The complexity about getting the widget below to work was thinking out-of-the-box: Generate a XSLT on the fly using XSLT which would do all the heavy lifting.
- playframework 2.0
- Scala
- Apache Cocoon 3.0
- latest version of saxon
- a Database to store application resources (XSLT, templates, images, ...)
The idea I had in mind was to create reusable widgets and I've been reminded today that such things are already in the market. However, it's hard for me to compare ease of use, performance and usability for commercial businesses. In the meantime I started experimenting a bit and came up with the following widget which basically generates the same output (table containing tweets for particular person) as in my previous article. However, in the previous article no higher order XML declarations were used. I think you will see that with some XSLT magic you get a lot done with a few lines. It took some time to get it working properly but the table widget now takes an @data-source which you can bind to any table:component.
By the way, with higher order declarative XML i am referring to the analogue higher order functions like e.g. MAP / REDUCE, FOREACH. As you can see from the sample below, a single table:row instruction can actually be seen as a function which maps a sequence (of nodes selected with the @bind) to table:rows.
The complexity about getting the widget below to work was thinking out-of-the-box: Generate a XSLT on the fly using XSLT which would do all the heavy lifting.
Using client side XSLT with Saxon-CE
Yesterday I decided to have a go with Saxon-CE as I definitely can see benefits from doing client side transformations. Saxon-CE is still in alpha state so it is not recommended to use it in production yet.
I wanted to really come up with a nice demo so decided to check if I could build a webpage using live Twitter Search data. I did face my first issue as the @data-source attribute is not working cross-domain and it does not even seem to be working in chrome or IE. I had to manually download the XML results from a Twitter search for Michael Kays tweets. They are included in this downloadable zip but to get an idea of what the data looks like you can open following url: Michael Kay's tweets
The final result can be seen in screenshot below:
I wanted to really come up with a nice demo so decided to check if I could build a webpage using live Twitter Search data. I did face my first issue as the @data-source attribute is not working cross-domain and it does not even seem to be working in chrome or IE. I had to manually download the XML results from a Twitter search for Michael Kays tweets. They are included in this downloadable zip but to get an idea of what the data looks like you can open following url: Michael Kay's tweets
The final result can be seen in screenshot below:
Friday, November 25, 2011
Introduction into functional programming with Javascript
Some people underestimate the powerfull concepts of Javascript. It is the ideal language to start understanding 'functional programming'. To better get a grip on different ways to accomplish the same task I wrote some basic and more advanced code from which I hope some people can benefit.
To see what the actual scripts do, just save each script and name it e.g. script1.js, script2.js and include them like below in the html page. Just load the page in your browser and you will see output printed to the console.
To see what the actual scripts do, just save each script and name it e.g. script1.js, script2.js and include them like below in the html page. Just load the page in your browser and you will see output printed to the console.
Friday, November 18, 2011
Apache Cocoon: From XML to JSON as datasource for client or server side Javascript
In a Cocoon project I am working currently working on we are using Sedna XMLDB. All the information we use is stored as XML and I just wanted to share some insight in several use cases we
are handling. Just as a side note, we are using a custom XQueryGenerator to fetch all data but the use cases below also match for a file repository.
Use case 1: publish content from a single XML source (HTML/ PDF/ ...)
---------------------------------------------------------------------
As we only need 1 single source file it is often easier to use XSLT to generate the final HTML as XSLT offers more advanced features then XQuery as we speak. To name a few
examples, XQuery lacks good out-of-the-box support for:
- grouping
- formatting
Also you have to use another mindset when programming with XSLT. In XSLT you basically declaratively tell WHAT to do when the XSLT processor matches a specific
node or attribute. So you don't have to take into account all possible combinations that might occur. Whereas in XQuery you have to state explicitly what you want to produce.
Use case 2: publish content from multiple XML sources (HTML/ PDF/ ...)
---------------------------------------------------------------------
While Cocoon does allow you to get the job done using e.g. the cinclude transformer or the aggrate generator it becomes rather messy very quickly.
And there are many ways to accomplish the same result. You might choose to write several pipelines, each one generating and extracting (xslt) the data needed and aggregating those results.
Or you could just aggregate all sources in 1 go and write a single xslt to extract the data.
For this use case however it is much more convenient to just write 1 single XQuery which is able to generate whatever your needs are.
Use case 3: perform some conditional logic based upon the source XML before processing it
-----------------------------------------------------------------------------------------
Let's say the XML source either describes a Male or Female and you can find out by fetching the content of Gender tag.
Again there are multiple ways to Rome and to just name a few. Write a Java Component which extracts the data you need and include it in your flowscript. But how easy is this generalizable? what methods should the interface contain? Different use cases might call for different interfaces and you don't want to end up creating new java classes all the time.
Use case 4: you want to use some fancy Javascript widget which needs a JSON datasource
-----------------------------------------------------------------------------------------
If all your data would be coming straight from a relational database, your entities could be easily mapped to JSON. There are plenty of libraries out there. But how do we generate JSON from XML in particular?
To be able to solve use cases 3 and 4 I decided to come up with a XML dialect which could represent JSON and also do some formatting if needed.
Below a sample representation of the JSON-XML dialect.
Generic transformer (XSLT2.0) which generates a JSON string from the input
A sitemap example generating JSON from XML
Now we can invoke the uri 'data2json/employees/1234' and the corresponding JSON will be generated which can be used on the server and client side.
An example of how we can use this from flowscript:
are handling. Just as a side note, we are using a custom XQueryGenerator to fetch all data but the use cases below also match for a file repository.
Use case 1: publish content from a single XML source (HTML/ PDF/ ...)
---------------------------------------------------------------------
As we only need 1 single source file it is often easier to use XSLT to generate the final HTML as XSLT offers more advanced features then XQuery as we speak. To name a few
examples, XQuery lacks good out-of-the-box support for:
- grouping
- formatting
Also you have to use another mindset when programming with XSLT. In XSLT you basically declaratively tell WHAT to do when the XSLT processor matches a specific
node or attribute. So you don't have to take into account all possible combinations that might occur. Whereas in XQuery you have to state explicitly what you want to produce.
Use case 2: publish content from multiple XML sources (HTML/ PDF/ ...)
---------------------------------------------------------------------
While Cocoon does allow you to get the job done using e.g. the cinclude transformer or the aggrate generator it becomes rather messy very quickly.
And there are many ways to accomplish the same result. You might choose to write several pipelines, each one generating and extracting (xslt) the data needed and aggregating those results.
Or you could just aggregate all sources in 1 go and write a single xslt to extract the data.
For this use case however it is much more convenient to just write 1 single XQuery which is able to generate whatever your needs are.
Use case 3: perform some conditional logic based upon the source XML before processing it
-----------------------------------------------------------------------------------------
Let's say the XML source either describes a Male or Female and you can find out by fetching the content of Gender tag.
Again there are multiple ways to Rome and to just name a few. Write a Java Component which extracts the data you need and include it in your flowscript. But how easy is this generalizable? what methods should the interface contain? Different use cases might call for different interfaces and you don't want to end up creating new java classes all the time.
Use case 4: you want to use some fancy Javascript widget which needs a JSON datasource
-----------------------------------------------------------------------------------------
If all your data would be coming straight from a relational database, your entities could be easily mapped to JSON. There are plenty of libraries out there. But how do we generate JSON from XML in particular?
To be able to solve use cases 3 and 4 I decided to come up with a XML dialect which could represent JSON and also do some formatting if needed.
Below a sample representation of the JSON-XML dialect.
Generic transformer (XSLT2.0) which generates a JSON string from the input
A sitemap example generating JSON from XML
Now we can invoke the uri 'data2json/employees/1234' and the corresponding JSON will be generated which can be used on the server and client side.
An example of how we can use this from flowscript:
Subscribe to:
Posts (Atom)