MLJS Versus

adamfowleruk edited this page Jan 20, 2014 · 16 revisions

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

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.