I am using superset 2.0 and have couple of dashboards with charts. I need to cater this to international audience. (French/spanish etc)
I also have separate custom translation module which enables Translation. (Key code, input word, output translated word)
Goal is to make use of Custom Translation module API's within superset and enable the translation.
Approach would be,
Expose dashboard/chart through superset rest API's
Wrap this using Python code and take a better control (is this possible)
Call the custom translation module within superset and enable translation. (Can we call customer API's through superset?)
Use external dashboard tool/library which can consume superset rest response.
Would like to know if I can still use superset dashboard by following step 1,2 and 3 ?
Does this look feasible? Is there a better approach? Is there any other open-source dashboard tool that supports custom API's integration (in house modules).
Related
I have a requirement in which i get two json file in request and I need to copare two json files.
Is there a way within ODM where can show customers the UI for text comparision of json ?
Lets say, json 1 file has a field name which is different from json2 name. I need to show with any report /Ui that this is the difference between two files.
Any help would be appreciated.
Thanks in advance
The ODM user interfaces, either Eclipse-base Rule Designer or web-based Decision Center, allow extensive customization, but these UI's are for authoring the rules, not applying them to input data.
ODM rules are generally run within a server environment, so at execution time there is no user or user interface. It is possible (and feasible and reasonable) to embed ODM execution into any Java program (for example, one with a UI to show or compare differences between JSON document), but ODM does not provide any kind of UI framework for building such a program.
I faced the same problem and used JsonAssert library to compare Jsons in Java.
Best
Emmanuel
I am starting to write my first web app with Node.js and Express. I have two approaches in mind.
Create two sets of routes. One that sends JSON, one that renders the page using a templating engine
Create a static website that makes API calls to the backend using AJAX, and have only routes for the API.
I understand that approach #2 depends on AJAX support in the browser, but if this was your project, based on the advantages and disadvantages of each approach, which would you choose and why?
If I am reading it right, both options #1 and #2 first set of routes is an API that returns JSON rather than sends it.
Assuming that in #2 you wouldn't create static pages with JavaScript doing AJAX calls, but rather still use express static routing like app.use('/', express.static(path.join(__dirname, 'dist'))); the difference between 2 approaches isn't that big.
Unless you already know some supported template language, such as mustache the cons are that you have to learn one and before that pick one (which isn't always an easy task from my experience!).
If you don't know one, depending on your application, you might still benefit from learning and using one. As an example you can think of a very generic UI where a single template could be reused very many times - like a generic database UI similar to, say well known phpmyadmin.
In case of static routing, you can achieve similar results by using a JavaScript framework which has components or templates, such as angular. If you aren't planning to use one, that could result in a lot of code duplication of otherwise re-usable widgets. And even when using one I can imagine a case when template engine would result in less code (or less files in your project at the very least). Not sure though if it's going to be easier to navigate and moreover to cover with tests when the project grows.
Without knowing more about your project it is hard to give more advice.
If the product you're developing is primarily static content with some dynamic pieces here and there, I'd recommend serving HTML from your backend via a templating system. A good example of this would be a blog. You'll end up with better SEO and there are less moving pieces to grok in this approach.
However, if you want to develop a single page application, I recommend using your backend entirely as an api, and writing your client side logic entirely in React/Vue/Angular/whatever. Single page applications have their front ends written entirely in javascript, and are best suited to highly dynamic, "app like" experiences online. Think gmail or facebook.
In my current project we use both approaches. Many views are static and data is obtained from API calls (we just use angular) or bootstrapped values (we load some objects with template, like user roles etc.)
However, some views are rendered on server site, because it easily allow us to dynamically inject values, tokens or other supporting data without making extra requests.
So, I vote for flexibility
I really like the way Algolia has approached their multi-programming language API documentation, e.g. https://www.algolia.com/doc/javascript .
Does some know by chance what technologies do they use to generate it?
The documentation generator we're using is currently an internal tool. We might open-source it at some point, but it would require some extra work time which we don't currently have.
It's basically a markdown file with some extra syntax to:
handle multiple languages code blocks (it then automatically selects the good one)
handle conditions depending on the current language
handle callouts
handle buttons
The rendering is then hand-made with the help of bootstrap.
How are people managing multiple API versions with API Blueprint?
It doesn't seem that the format supports version sections within a single file, so I'm left thinking that multiple files with indicators in the filename are the best option.
We want to leverage the tools to create a central mock-server and doc commons, and will need to handle evolving multiple versions of each API.
Managing multiple versions via branches seems inconvenient for us, so we render the entire document with multiple versions of APIs in one page. Our users need to be able to read both versions by just prepending v1 or v2 in front of the URL. So, we have a node app that handles the documentation requests and renders the doc via aglio node module.
The following is how we organize the docs.
Users can request /docs/en/spec.
The en part determines the language of the document as we support different languages.
Because the entire document is pretty huge we split it into files based on the Blueprint Group (the thing that starts with # Group GroupName)
When a request comes in, we first look if we have previously compiled the doc and have a cached version, so we don't recompile every time (it's pretty intensive work especially when the doc is large).
If we have no cached version, we read all *.md files in the docs/en directory.
Sort the filenames alphabetically, concat their contents, and pass to aglio which produces a nice html content. We cache this content into a file and later pipe it to the client on each request.
The UI provides the table of contents (side menu on the left) which has, for instance, the following format.
Auth
Projects
Project Users
...
Groups
Groups v2
Now each Group of APIs has a distinct URL which is prepended with /v1 by default. When we introduce a new version of a specific API, we create a new # Group Groups v2 which is prepended with /v2. This way our users can see and choose multiple versions of the APIs in one page.
The nice things about the aglio node module is that it provide multiple themes for the UI which provides a nice navigation so that our users don't feel the page is too overloaded. Among the themes you can choose either single-page UI or multi-page UI where on selection of the API the page with the corresponding API is loaded and the URL is changed.
Implementing this logic is very simple. Hope this helps.
There is another idea which we are considering right now but haven't started just yet. It is to avoid splitting APIs into different # Groups and instead modify the Jade template used by aglio and make sure it supports multiple versions out of the box.
It might be best to version the blueprint file in a versioning repository and treat different branches as different API versions. You can even have the blueprint in the same repo/branch as the API server implementation.
If you're versioning using GitHub, Apiary can connect to GitHub and you can setup different branches to be picked up by different documentations in Apiary.
I searched on web but I didn't find anything related to i18n and Go.
I wish to use Go for develop web sites. What is the best way to handle internationalization?
go-i18n has some nice features:
Implements CLDR plural rules.
Uses text/template for strings with variables.
Translation files are simple JSON.
Packages roadmap
Comprehensive support for international text.
Support for international dates, times, etc.
Support for multilingual messages.
As you can see from the Go Roadmap, Go doesn't provide full i18n support yet.
The new template package allows you to at add a function to template's function map, that would transform the given string to a localized version. What's going on underneath would be up to you for now, as the language choice could be based on headers sent by the browser.
That's a very basic use case for adding localized messages in a web app, for one.
Can't wait for the proper support for internationalization, local date and time formats.