MLJS Versus - adamfowleruk/mljs GitHub Wiki
This page compares MLJS against other alternatives. If you think of one I've missed, please let me know by logging an issue on GitHub.
##MLJS vs. Visualisation Widgets MarkLogic includes some built in Visualisation Widgets. These are used extensively by the Application Builder web GUI wizard to create quick start applications. They too wrap the REST API and provide common search and graphing capabilities.
The Vis Widgets are quick to build an app and don't require developer level knowledge. The Application Builder wizard is a great place to quickly configure an app and start exploring content. Once you go beyond what is provided, however, then customising applications can be tricky.
Examples include customising how things are displayed - this requires XSLT, and means you lose control over rendering in application code as it's handed off to the server. There are a few things that Vis widgets do provide that MLJS hasn't caught up with yet. This includes a configurable document preview page, bookmarking, google maps, and clickable chart widgets. MLJS does support JSON results displaying though.
Below is a full comparison between the two. I aim before November 2013 for MLJS to surpass what the Visualisation Widgets provide.
| Feature | MLJS | Visualisation Widgets |
|---|---|---|
| Core API | ... | ... |
| - Works in WebApp in a MarkLogic REST App | Yes | Yes |
| - Works in WebApp outside of MarkLogic | Not yet (Aim to support W3C CORS API, so no proxying required) | Yes, via Proxy on app server |
| - Works in NodeJS | Yes | No |
| - Wraps REST communication complexity (E.g. authentication) | Yes | No, directly invokes jQuery AJAX support for each search method in controller (not a multi layered API) |
| Widgets | ... | ... |
| - Security/Login | Relies on Roxy or wrapper app for this (browser context) | None, relies on Browser context |
| - Search Bar, Paging, Sorting, Facets, Results widgets | Yes | Yes |
| - Search Context object to link widgets to one search | Yes | Yes |
| - Suggestions as you type | Not yet | Yes in search bar, if configured |
| - Chart support for aggregations (facet values) | Yes | Yes |
| - Chart support for in document values | Yes | No |
| - Charts supported | All HighCharts, multi axes, multi series (Tested Line, Spline, Bar, Stacked Bar, Column, Stacked Column, Area, Stacked Area, Pie) | Pie, Line, Column, Bar only, single series, single axis |
| - Charts navigable? (Affects facets) | Yes | Yes (also see shadow queries, below) |
| - Co-occurence widget | Yes, navigable too | No |
| - File Upload Widget | Yes, with Security | No |
| - XHTML security markings widget | Yes, with Doc properties and triple extraction | No |
| - Tabular Widget | Yes, Google Kratu | No |
| - Mapping widget | Yes, OpenLayers based for maximum interoperability. Includes heatmaps, polygon, radius, bounding box search too | Yes, with heatmaps, point clustering and polygon creation |
| - Generic Document View page | No (Do have a generic HTML view page), achievable via REST API's GET /v1/document endpoint with XSLT or XQuery transform referenced | Yes, via XSLT |
| - Shadow Queries (Selecting a chart value updates other widgets, but not itself, thus preserving all selectable options) | No (Will instead implement a setUpdateAfterSelect(false) method, should this be asked for) | Yes |
| - OOTB Result Rendering | Yes (XHTML XML, Any XML, Any JSON, plain text, snippets) | Yes (XML only with snippeting? Treats all results like this no matter source document type.) |
| - ML 7 Semantic widgets | Yes - SPARQL query builder, entity list, entity facts, graph and document explorer | No |
| - User dashboarding widget | In development 'Workplace' widget | No, configurable by admin only in Application Builder |
| Tools | ... | ... |
| - Wizard driven app builder | In development 'Workplace' widget | Yes, the Application Builder |
| - App deploy tool | No, relies on Roxy | Yes, the Application Builder |
| - API Installation Script | Yes, downloads latest MLJS and copies to your own webapp/Roxy app folder (mljsme.sh). Soon to be built in to Roxy too. | No, manual download and install |
| Architecture | ... | ... |
| - Design Target | NodeJS and Browser apps requiring all ML functionality | Browser search applications only |
| - Technologies required to customise | HTML, CSS, JavaScript only | HTML, CSS, JavaScript, XQuery/XSLT, jQuery knowledge required |
| - Dependencies | HighCharts for charting (forces need for jQuery), OpenLayers and Heatmaps for mapping | HighCharts and jQuery 1.7.1, with jQuery UI 1.8, Heatmap.js, Mxn.js, Google Maps |
| - Optional library support | Google Kratu, 960.css layout class support | None |
| - Layout support | Yes, via Workplace (Will also support layouts within layouts soon) | Internal (define layout in Application Builder, or search context linking via parent html element), use HTML, CSS, XSLT |
| Extensibility | ... | ... |
| - Core API supported | far too many to list now. All search API, including options, semantic graph manipulation and query, some admin functions, config functions, custom REST API extensions | search, get only |
| Controllers per page | Unlimited, supporting dashboard UIs | Within specified parent container of page, configured by physical placement within parent div. Normally single controller per page (Singleton pattern) |
| - Core extensions | Yes, via do() method, wraps all communication | No, communicator object is internal only and not exposed for general use |
| - Widget extensions | Yes, just use core mljs.js file, widgets css as base | Yes, via ML.createWidget |
##MLJS Versus Angular.js
I get asked a lot why I don't support jQuery or Angular.js. Simple answer is I don't provide (or enforce) any particular page controller or widget building library. I don't want to force a dependency on you, the developer/integrator, unless I absolutely have to.
It's not that I'm anti these libraries, just that I don't want to force people to use one or the other. You can still use them to create your own widgets, or manage a page that MLJS widgets are just a part of. This provides the best of both worlds - access to rich MLJS functionality with the ability to plug in any framework you like.
Angular.js is great for data binding apps. E.g. document creation and editing I can see a really good fit for Angular. Even for overarching page controllers it makes sense. I don't personally believe it makes sense for a search interface where you don't really bind data.
I also don't think it could elegantly handle the complex interrelationships that exist in a typical MarkLogic search page - with sorting, paging, facets etc. being affected by a range of activities. This will always require a middle tier app level controller like the Context objects in MLJS.
I think use Angular.js for data binding (document creation/editing) and an overall page Controller - but when it comes to visualisation widgets or inter widget communication, or communication with MarkLogic Server itself, use MLJS.