Skip to main content
Kinetic Community

Getting Started

Overview

Bundles provide the interface needed for building out an application. Bundles wrap the forms defined in the Management Author Console and extend functionality your organization needs to build an intuitive, engaging user experience. Bundles typically include items such as theming/branding, search, alerts, portals, and other widgets.

Bundles use standard web technologies including HTML/JSP, CSS, Javascript, and can be developed using a text editor or IDE. The default bundle uses Bootstrap, but you can include any framework or library of your choosing.

Bundles often need server-side access to information about the Kinetic Application including items such as form names, paths to resources, attributes, the authenticated user, etc. This is where the Bundle/Java API comes in. Bundle authors can embed information into their pages through a simple syntax and use helpers to format and present information as needed.

Bundles are deployed to the Kinetic Core web application’s /app/bundles directory, located within a directory named for the slug of the Space where the bundle is to be used. For instance, a bundle for the the Acme space, which would normally have the slug value acme, would be located at /app/bundles/acme/{bundle-name}.

One of the fundamental changes in Kinetic Core regarding bundle development was to use the JSP Expression Language (EL)and tag libraries when possible. This results in much cleaner JSP code that is easier to read and maintain.

A quick example JSP adding a form title to the top of a page for a consistent layout across all forms:

<%@page pageEncoding="UTF-8" contentType="text/html" trimDirectiveWhitespaces="true"%>
<%@include file="bundle/initialization.jspf" %>
<bundle:layout page="layouts/layout.jsp">
    <bundle:variable name="head">
        <title>${text.escape(form.name)}</title>
    </bundle:variable>
    <div class='container'>
      <section class="page">
        <div class="page-header">
          <h1>${text.escape(form.name)}</h1>
        </div>
        <div class="errors"></div>
        <app:bodyContent/>
      </section>
    </div>
</bundle:layout>

Helpers

Helpers are classes imported or included in a JSP page that provide functionality similar to a controller or a utility file. Often helpers provide easy to use methods that perform common or complex tasks. Using helpers cleans up the main JSP logic so other developers can easily see what the intent of the page.

Included Helpers

  • Bundle Helper - a library that provides methods for dealing with resource paths.
  • JSON Helper - a library for building JSON objects without having to concatenate multiple strings.
  • Submissions Helper - a library that helps searching for submissions.
  • Text Helper - a library that has many common String functions.
  • Time Helper - a library for working with date/time objects.

Tag Libraries

Kinetic Core comes with several custom tag libraries, as well as the JSTL tag libraries and the Spring security tag library. All of these tag libraries are available for use in bundle JSP pages. Usually the tag libraries are loaded in thebundle/initialization.jspf file, or the package/initialization.jspf file depending on the location of the JSP using the tag library.

JSP Expression Language (EL) syntax cannot be used in JSP directives such as <%@page> and <%@import>. This means that the ${bundle.path}${bundle.location}, etc… EL variables cannot be used in these directives.

JSP Expression Language (EL) syntax also cannot be used in the <jsp:include> tag when including dynamically generated JSP partials. For this reason, it is recommended to use the JSTL core library import tag (<c:import>) instead. If files need to be imported statically, then the <%@import> directive will still need to be used, and in this case EL simply cannot be used within it.

Included Tag Libraries

Models

Presently, we are directly exposing our models. We are not sure whether we want to expose these directly or provide a lightweight facade to give us greater flexibility in changing application internals.

All models currently have the following properties:

  • createdAt
  • createdBy
  • updatedAt
  • updatedBy

Related