onaio / zebra-lite

A lite Zebra (i.e. a baby Zebra)

zebra-lite

Overview

This is a light version of Zebra that allows users to log into their accounts, view their forms, and view the data in their forms. It uses the Clojure(Script) Ona client milia to connect to the Ona API. It connections to Ona Production by default but can be configured to connect to any server running Ona or an Ona-compatible API.

Component Architecture

• Login
• Forms View
• Submission View (using hatti)
  • table-page
  • map-page
  • chart-page
  • details-page

Configuration

Remote host configuration is handled by milia using environ. Set the keys :ona-api-server-host and :ona-api-server-protocol to specify the host and protocol, respectively.

Dependencies and Installation

Building and running require java and leiningen, the install instructions for leiningen are here.

Running

Run the development server with:

lein up

Build a deployable production JAR with:

lein uberjar

Then run that JAR with:

java -jar target/zebra-lite-SNAPSHOT-standalone.jar

NB: your JAR path may differ if you have altered the configuration.

License

zebra-lite is copyright 2015 Ona Systems Inc. and is released under the AGPL License.

zebra-lite's Issues

Form Submissions View

Ability to visualise form submissions using:
* table-page
* map-page
* chart-page
* details-page

Form List View

Lists all user forms within their account

Need to add license file before releasing

Need to decide if we do this as AGPL or Apache

add generated docs in a public place

https://github.com/weavejester/codox

use travis instead of drone for tests

Because it's a public repo

Use url helpers

Use url helpers from urls namespace instead of hard-coded urls.

User login using Ona Account

I18n the lite

Use the established convention from Zebra to i18n the lite

Add Ona Community logo

@rowo can make an Ona Community logo for this?

We might also want to change the font and color scheme a bit. Right now it resembles almost exactly beta. Not sure if want that or not.

What is the deployment plan for Zebra-Lite

Clean up

This issue is for listing clean up tasks (feel free to add more is necessary):

• Set up tests
• Enable/remove links non-working links
• Enable avatars

Prototype app to experiment with new SPA architecture

From @myguidingstar

After some research, here's my perspective on current situation:

• Om Next is very near and its recommended architecture is not single
  app state but highly independent components. We shouldn't invest on
  single app state.
• the transition to a new architecture is quite unclear b/c 1. the
  target architecture: despite its simplicity, the Om next's
  architecture is totally new in the industry 2. the origin
  architecture (aka current implementation): it's not obvious to
  semantically split into pieces to migrate to the new (unclear :) )
  architecture to work gradually.

disciplines: We need to keep these in mind

• don't be confident of pre-defined the architecture. Instead, things
  need putting together and the pattern will emerge.
• separation between data transformation and HTML representation
• security. Note: should have a dedicated section in architecture doc
• (Clojure/Clojurescript) portability. Use Bidi for routing

Goals:

• wait for the architecture that fits our app to emerge :)

More details of the strategy:

• don't start by looking at the code base. Look at the working app in
  a browser and and decide how to mimic it
• Hatti is subject to mimic, too. It should have overlap with the app
• For the speed of development (to see the architecture emerge soon),
  the prototype app will purely client side with mock data. That would
  result live coding
• Functionality first. HTML representation remains plain dumb. Real HTML structure and CSS stuff will be replaced in later stages.
• After that, as patterns emerge, we create ad-hoc server side
  endpoints ("data bundlers for server response") for optimal purpose
  (hence cljc portability)