nifi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Gilman (JIRA)" <>
Subject [jira] [Commented] (NIFI-353) Create a Data Viewer
Date Fri, 20 Mar 2015 23:57:39 GMT


Matt Gilman commented on NIFI-353:

I've added labels to the filename and content type. I agree that just showing the filename
is only obvious when it's something meaningful. Showing the content type seems to be appropriate
so the user can see what was detected. 

These are the only pieces of information that are available currently. The input to the endpoint
that retrieves the content is a provenance event id and whether we want the input or the output
to that event. I do not know what the flowfile uuid is. I only know the filename as its populated
in the Content-Disposition (attachment) response header. Then the content type is detected.
I could add additional details in NiFi specific response headers if desired.

> Create a Data Viewer
> --------------------
>                 Key: NIFI-353
>                 URL:
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Core UI
>            Reporter: Matt Gilman
>            Assignee: Matt Gilman
>         Attachments: flow_that_shows_issues_with_viewer.xml
> For use in property: 
> {code}nifi.content.viewer.url{code}
> The content viewer will be extensible in that the supported mime types will be discovered
at runtime. We will be taking an approach similar to Java SPI. During startup all war files
will be inspected looking for a META-INF/nifi-data-viewer file. This file will contain the
mime types that it can render (1 per line). Duplicate viewers will be logged and either the
first or the last will be utilized.
> Currently, the content viewer is applicable for viewing archived data through the provenance
UI. This will likely be expanded to integrate with other parts of the application where applicable
(viewing content in queues, etc). When viewing the data, the content viewer controller will
get the data stream and detect its type (Apache Tika, known mime type, file extension, etc).
Will likely need to add support for decompressing/unpacking. Once the underlying type is known
and is supported, the content viewer controller will generate the webpage and defer to the
discovered web application to generate the mark up for the data (via RequestDispatcher.include).
This means that the discovered web application does not need to generate any boilerplate HTML
and all types of content will be viewed in a similar UI.

This message was sent by Atlassian JIRA

View raw message