[xwiki-devs] [DISCUSSION] XWiki Chart Api & Chart Macro
Hello Devs, I have been examining Dan Miron's patches for http://jira.xwiki.org/jira/browse/XWIKI-3313 & http://jira.xwiki.org/jira/browse/XWIKI-2883 and they are working fine. However I think there are few improvements / refactorings that should be done before comitting the code. Most importantly, I would like us to agree upon the xwiki-chart api and xwiki-chart-macro format. xwiki-chart module ============== In dan's implementation, the chart module is actually called xwiki-jfreechart because it is dependant on the jfreechart api. However I think we can extract a generic chart api from dan's implementation without much of a trouble. In his implementation there are three interfaces: * ChartGenerator * DataSource * DataSourceFactory * PlotFactory Out of these interfaces only PlotFactory is dependant on jfreechart. IMO we can construct a generic chart api by making ChartGenerator & DataSource interfaces component roles, hiding PlotFactory in an internal package and getting rid of DataSourceFactory. So the final API would be something like: interface ChartGenerator { File buildChart(DataSource dataSource, Map<String, Object> parameters, File outputDirectory) throws ChartGeneratorException; } And interface DataSource { // Usual tablemodel like api (from dan's implementation) void init (params) // Initializes this datasource from the parameters passed in, no need of a separate factory. } We can also go to a api / implementation approach with multiple modules as in: /platform/core/trunk/xwiki-chart | |-> xwiki-chart-api | |-> xwiki-chart-jfree But I don't know if this is worth the trouble. xwiki-chart-macro ============= Currently the chart macro has a format like: {{chart chartType="line" source="type:XDOM; table_number:1;range:A1-C3;series:rows" title="line (xy_line_and_shape, default)" width="640" height="480"/}} I think we should change the "chartType" parameter to just "type" and the source parameter would be changed like: source="<id>|<params>" here we will use the <id> part as the component hint for the corresponding DataSource... and the <params> string can be anything specific for that DataSource (so we don't put any restrictions). For an example, we could have a datasource named "xdom" like: source="xdom|document=Main.WebHome;table=someTableId;series=rows;hasHeaderRow=true;hasHeaderColumn=true" We load the DataSource corresponding to "xdom" and let it initialize with the parameters string.... (that's why i put a init() method inside DataSource component role). The rest of the parameters would be standard : title, height, width etc. As a start we will have two types of DataSources: XDom and Inline (Already there). This is a quite big discussion and I don't know If I have explained myself correctly. Please let me know what you think about this and how it can be improved. Thanks a lot. - Asiri
Hi, On Jun 10, 2009, at 8:39 AM, Asiri Rathnayake wrote:
Hello Devs,
I have been examining Dan Miron's patches for http://jira.xwiki.org/jira/browse/XWIKI-3313 & http://jira.xwiki.org/jira/browse/XWIKI-2883 and they are working fine.
However I think there are few improvements / refactorings that should be done before comitting the code. Most importantly, I would like us to agree upon the xwiki-chart api and xwiki-chart-macro format.
xwiki-chart module ==============
In dan's implementation, the chart module is actually called xwiki-jfreechart because it is dependant on the jfreechart api. However I think we can extract a generic chart api from dan's implementation without much of a trouble. In his implementation there are three interfaces:
* ChartGenerator * DataSource * DataSourceFactory * PlotFactory
Out of these interfaces only PlotFactory is dependant on jfreechart.
IMO we can construct a generic chart api by making ChartGenerator & DataSource interfaces component roles, hiding PlotFactory in an internal package and getting rid of DataSourceFactory. So the final API would be something like:
interface ChartGenerator { File buildChart(DataSource dataSource, Map<String, Object> parameters, File outputDirectory) throws ChartGeneratorException; }
It should not return a File but an OutputStream instead. I'd call it generate rather than build. And remove outputDirectory. And mention it's generating an image. so: ChartImageGenerator.OutputStream generate(DataSource, Map);
And
interface DataSource { // Usual tablemodel like api (from dan's implementation) void init (params) // Initializes this datasource from the parameters passed in, no need of a separate factory. }
I don't understand why it doesn't have any method. init() doesn't seem a good method to have. A source needs to return something. Something like a Chart definition.
We can also go to a api / implementation approach with multiple modules as in:
/platform/core/trunk/xwiki-chart | |-> xwiki-chart-api | |-> xwiki-chart-jfree
But I don't know if this is worth the trouble.
It can be put in the same module for now. The jfreechart implementation will be in the internal package as component implementation.
xwiki-chart-macro =============
Need more time to think about this one. Thanks -Vincent
Currently the chart macro has a format like:
{{chart chartType="line" source="type:XDOM; table_number:1;range:A1-C3;series:rows" title="line (xy_line_and_shape, default)" width="640" height="480"/}}
I think we should change the "chartType" parameter to just "type" and the source parameter would be changed like:
source="<id>|<params>"
here we will use the <id> part as the component hint for the corresponding DataSource... and the <params> string can be anything specific for that DataSource (so we don't put any restrictions).
For an example, we could have a datasource named "xdom" like:
source="xdom| document = Main .WebHome ;table=someTableId;series=rows;hasHeaderRow=true;hasHeaderColumn=true"
We load the DataSource corresponding to "xdom" and let it initialize with the parameters string.... (that's why i put a init() method inside DataSource component role).
The rest of the parameters would be standard : title, height, width etc.
As a start we will have two types of DataSources: XDom and Inline (Already there).
This is a quite big discussion and I don't know If I have explained myself correctly. Please let me know what you think about this and how it can be improved.
Thanks a lot.
- Asiri
Hi vincent, On Wed, Jun 10, 2009 at 10:46 PM, Vincent Massol <[email protected]> wrote:
It should not return a File but an OutputStream instead. I'd call it generate rather than build. And remove outputDirectory. And mention it's generating an image.
so:
ChartImageGenerator.OutputStream generate(DataSource, Map);
Sounds good.
And
interface DataSource { // Usual tablemodel like api (from dan's implementation) void init (params) // Initializes this datasource from the parameters passed in, no need of a separate factory. }
I don't understand why it doesn't have any method.
It has a lot of methods (in dan's implementation). I put a comment just to explain. Following is a complete listing of methods: public interface DataSource { int getRowCount(); int getColumnCount(); Number getCell(int rowIndex, int colIndex) throws ChartGeneratorException; Number[] getRow(int rowIndex) throws ChartGeneratorException; Number[] getColumn(int colIndex) throws ChartGeneratorException; Number[][] getAllCells(); boolean hasHeaderRow(); boolean hasHeaderColumn(); String getHeaderRowValue(int columnIndex) throws ChartGeneratorException; String[] getHeaderRow() throws ChartGeneratorException; String getHeaderColumnValue(int rowIndex) throws ChartGeneratorException; String[] getHeaderColumn() throws ChartGeneratorException; } The purpose of the init(String param) method would be to initialize this DataSource so that above methods will return actual data. Thanks. - Asiri
Given how easy it is to integrate Exhibit into Xwiki, I think it would be a good idea to not "reinvent the wheel" for significant further development on the chart/plot features, but of course, commit the improvements that are here now if they don't break anything :-). Of course, this is somewhat "apples and oranges" since the existing xwiki implementation renders plain HTML; Exhibit is an Ajax monster that renders via a very abstract data model, what could best be described as "template-rule based programming meets web templates" ( http://people.csail.mit.edu/dfhuynh/research/papers/www2007-exhibit.pdf ). One of the reasons for saying this is that I've "seen the light" (much like using Xwiki in the first place) and it is a javascript framework called "Exhibit": http://simile-widgets.org/exhibit/ http://simile.mit.edu/wiki/Exhibit/Getting_Started_Tutorial ... I've been making extensive use of it alongside Xwiki, and it is amazing: - Core features: - database: graph-based model, rich expression language, importers for many formats, exporters to many formats - browsing: sort, filter, filter by numeric ranges, text search - user interface: - html-base UI configuration - flexible layout - style-ability - css-like format language - visual coding - Visualizations: map, timeline, scatter plot, bar chart, pivot table http://simile.mit.edu/exhibit/examples/factbook/factbook-people.html is one example I've come across that demonstrates charting.... http://ryanlee.org/2008/03/rsy/rivalry.html demonstrates the timeplot etc. Of course, most of the examples focus on the more sexy features: Dipity<http://www.dipity.com/> ( http://www.dipity.com/premium ) for example, is a site that appears to fully reskin a customized Exhibit for that authentic "touched by a web designer" look .... Another interesting use is to display results from Solr/Flare: http://code4lib.org/node/154 http://wiki.apache.org/solr/Flare Regarding using Exhibit for Xwiki: I've updated my integration demo http://nielsmayer.com/xwiki/bin/view/Exhibit/Presidents4 ; I've also updated the sources ( http://nielsmayer.com/xwiki/bin/download/Exhibit/Presidents4/Presidents4Pkg.... ) If you install the Xar, unless you register with google<http://code.google.com/apis/maps/signup.html>(for optional use of google maps) your map-based exhibits will have an annoying dialog you need to click away. Put your google-maps registration in XWiki.JavaScriptExtension[0] in the object editor on document Exhibit.Presidents4: (var exhibit_gmapkey="";). FYI, the Presidents4Pkg.xar also provides the "macro documents" Macros.jQuery and Macros.Exhibit that allow you to easily use Exhibit in your Xwiki-based documents via the following preamble ( see http://nielsmayer.com/xwiki/bin/view/Exhibit/Presidents4?viewer=code ) ## ## Presidents example JSON data in XWiki.JavaScriptExtension[1] ## Note XWiki.JavaScriptExtension[0] defines JS vars exhibit_views and ## exhibit_gmapkey needed by "Macros.Exhibit" ## $xwiki.jsx.use("$doc.fullName")## ## ## Load and initialize jQuery, before Exhibit ## #includeMacros("Macros.jQuery")## #jquery_xwiki_init()## ## ## Load and initialize Exhibit Javascript and CSS ## #includeMacros("Macros.Exhibit")## #exhibit_xwiki_init()## ## ## Presidents example Stylesheet in XWiki.StyleSheetExtension[0] ## $xwiki.ssx.use("$doc.fullName")## ... ((create DOM in wikimarkup and HTML here)) ... ############################################################################## ## Fire Up Exhibit to process all ex:* markup and Json data into a UI. ############################################################################## #exhibit_create()## Niels http://nielsmayer.com On Tue, Jun 9, 2009 at 11:39 PM, Asiri Rathnayake < [email protected]> wrote:
Hello Devs,
I have been examining Dan Miron's patches for http://jira.xwiki.org/jira/browse/XWIKI-3313 & http://jira.xwiki.org/jira/browse/XWIKI-2883 and they are working fine.
However I think there are few improvements / refactorings that should be done before comitting the code. Most importantly, I would like us to agree upon the xwiki-chart api and xwiki-chart-macro format
...
Another interesting advanced JS data-visualization toolkit that would be useful to integrate in Xwiki. http://vis.stanford.edu/protovis/ http://www.technologyreview.com/computing/22927/?nlid=2130 http://flare.prefuse.org/launch/apps/job_voyager Thursday, June 25, 2009
Simpler Data Visualization Protovis aims to bridge the gap between computer scientists and visual artists. By Kate Greene
There are many ways to slice and dice data to better understand what it means. Software like Microsoft's Excel offers a simple way to create charts and graphs, while more complex applications, such as IBM's Many Eyes<http://manyeyes.alphaworks.ibm.com/manyeyes/>, provide more interesting ways to visualize more complex data<http://technologyreview.com/communications/18516/>. Specialized programming languages can do more by tweaking the design of visualizations. But these languages tend to be difficult for non-experts to use.
Now researchers at Stanford are offering a suite of tools called Protovis<http://vis.stanford.edu/protovis/>that streamline the process of building data visualizations. The tools still require knowledge of programming but are designed to be easier to implement for someone without programming experience, says creator Jeff Heer<http://jheer.org/>, a professor of computer science at Stanford.
Heer says that the level of programming required to use and modify the tools is slightly above that of HTML but easier than JavaScript, a common Web scripting language. One of the main benefits of Protovis, according to Heer, is that it is structured in such a way that a person who thinks first in terms of visualizations and then in terms of data should be able to find it easy enough to use.
Instead of having to focus on how to structure code for the program, Protovis lets a user create simple building blocks, such as the colors and shapes needed for the visualization, then piece the blocks together to define the complete picture. "With Protovis, you think first and foremost in visual marks on a page," Heer says. "It is our belief that this would make visualizations easier to learn and easier to modify."
One example of the type of visualizations that are made easier with Protovis is called Job Voyager <http://flare.prefuse.org/apps/job_voyager>. It was created by Heer to display changing trends in employment in U.S. census data over the past century. Different types of jobs are shown in shaded areas in two different colors corresponding to male and female workers. Throughout most of the U.S. census data (from 1850 to 2000), farming was the most popular profession by far. Compared to other visualization tools, such as Prefuse or Flare, Heer says that Protovis allowed Job Voyager to be created in a fraction of the time and using a fifth of the amount of code.
Heer notes that modern-data visualizations are often designed for the Web and tend to be dynamic. In the case of Job Voyager, a user can, for instance, click on a filter to see only how women's professions have changed over time. Or she can examine the ebb and flow of machinist jobs over the years.
Martin Wattenberg <http://www.bewitched.com/>, who developed Many Eyes with his IBM colleague Fernanda Viegas <http://fernandaviegas.com/>, thinks that visualization is becoming an essential medium of expression, especially online. "It may be the photojournalism of the 21st century," he says. Wattenberg adds that "a system like Protovis, which lets developers easily customize Web-based visualizations, has the potential to play an important role in the adoption of this technology."
Protovis is currently in an alpha release but has already been picked up by the Mozilla Foundation, and it will appear in an upcoming version of its Thunderbird e-mail client as a way to visualize e-mail data, Heer says.
Copyright Technology Review 2009.
Niels http://nielsmayer.com
Hi, On Thu, Jun 25, 2009 at 11:53 PM, Niels Mayer <[email protected]> wrote:
Another interesting advanced JS data-visualization toolkit that would be useful to integrate in Xwiki.
http://vis.stanford.edu/protovis/ http://www.technologyreview.com/computing/22927/?nlid=2130 http://flare.prefuse.org/launch/apps/job_voyager
Protovis sounds cool, but the way xwiki macros work will make it difficult (or messy) to implement a macro that will have to depend on a JS library. What we can do is this: * Implement the wiki-macro bridge: http://jira.xwiki.org/jira/browse/XWIKI-3213 (Basically this will allow you to convert any wiki content into your personal macro) - I'll finish this in a week or so. * We use a JSX (?) to get protovis support. * Neils can implement a js charting wiki-macro using protovis ;) I want to ask other developers, Is this possible? (I have a confusion about macros + js working together) Thanks. - Asiri
participants (3)
-
Asiri Rathnayake -
Niels Mayer -
Vincent Massol