The entire source code comes with the system and is convenient when debugging, however, only a few areas in the system would normally be of concern when building an application as follows.
src/main/backend/KissInit.groovyThis file is used to configure the system. See Setup and Configuration
src/main/backendAll other files under this directory represent the application back-end. All the files are used and distributed in source form. The Kiss system compiles them at runtime but does not save the compiled form. Updates to files under this directory take affect immediately on a running system.
Files under the src/main/frontend directory represent the
front-end of the application.
All files under the src/main/frontend/kiss directory are part of
the Kiss system and would normally not need to be touched.
index.html and index.js are also part of the Kiss
system and aren’t normally modified.
login.html and login.js represent the user login page
and would be modified to suit your needs.
Other directories such as page1 represent other user pages and
would be the application specific screens you create. The included
page1 directory is only an example page.
Kiss supports Microsoft SQL Server, Oracle, PostgreSQL, MySQL, and SQLite.
As shipped, Kiss comes configured with an embedded SQLite
server and database. While this is fine for a demo or small
application, a real database should be configured for real use.
The included database is located in the backend directory
and is named DB.sqlite
Although Kiss has no preferred database, PostgreSQL is strongly recommended because it is free, full featured, fast, rock solid, and portable on all major platforms.
Kiss applications are single page applications in the sense
that there is a single <body> tag and all other pages
essentially get placed into that tag on a single page. However,
Kiss is not a single page application in the sense that the
entire application gets loaded with a single GET request. This
doesn’t make sense for a large business application in which many
hundreds of pages may exist. Kiss lazy-loads pages as they are
used, and except for browser cache, eliminates them once another page
is loaded.
The user’s browser cache can be controlled from the file
src/main/frontend/index.html In that file you will see two lines
that look as follows:
SystemInfo.softwareVersion = "1"; // version of the entire system
SystemInfo.controlCache = false; // normally true but use false during
// debugging
If SystemInfo.controlCache is set to true, each time SystemInfo.softwareVersion
is incremented all users starting the application will be forced to
load new code from the server and not use their browser’s cache. Once
they download the new version, normal browser cache activity will
occur.
JavaDocs for the Kiss system will need to be created. It is created from the command line by issuing the following command:
./bld javadoc [Linux, Mac, BSD, etc.]
-or-
bld javadoc [Windows]
The JavaDoc files end up in the work/javadoc directory.
The only file needed to deploy the application is Kiss.war It
can be built by typing ./bld war at a command prompt.
Kiss.war ends up in the work directory. If you
have your IDE create the Kiss.war file, it will likely not
work. The Kiss system requires a special build process because
application files are distributed in source form. Therefore, bld
should be used to create the production WAR file.
If using tomcat, Kiss.war should be placed in the
webapps directory. When tomcat starts, it will see the
file, unpack it, and run it. The application will be available at
[HOST]/Kiss
Renaming Kiss.war to ABC.war, for example, will cause
the application path to change to [HOST]/ABC
In order to start getting a feel for how Kiss applications
function, in terms of the back-end, look at files in the
src/main/backend/services directory. With Kiss you can
develop applications in several different languages. The services
example shows the same code in all of the supported languages.
In terms of the front-end, see the example files under src/main/frontend/page1