Development

Generally speaking most of the starter kit shouldn't need to be modified; in fact essentially everything in the com.client.core package is meant to be used as-is. Most of these things are abstract classes meant to be extended, or just service/tool classes you can @Autowired in via Spring. In exceptional cases, where a large amount of code focused on one area is required or when particularly modularized code is desired, separate 'top-level' packages can be added next to the standard com.client.custom, com.client.core packages (a good example would be an integration to a third-party API). In most cases however, all custom JAVA code can and should be added to the standard com.client.custom package. A standard package structure under either com.client.custom, or under any 'top-level' packages would looks like this

config
controller
dao
exceptions
model
service
tools
util
workflow

Usage of these folders should be roughly as such (these examples are for the standard com.client.custom package, any other 'top-level' package would swap the word custom for the module name, i.e. 'integration')

• config - properties files or xml files used for configuration. Typically consists of custom-config.xml, custom-servlet.xml, messages_custom.properties, queries_custom.properties, custom-scheduledtasks.xml
  • Any file named messages_*.properties will get loaded into the default @Autowired-able Spring MessageSource
  • Any file named queries_*.properties will get loaded into the default @Autowired-able QueryHelper class, which simply obfuscates a Spring MessageSource so as to separate SQL query syntax from JAVA code.
  • custom-*.xml should be modeled after the standard files with similar names: src/main/webapp/WEB-INF/main-servlet.xml, src/main/resources/applicationContext.xml (for *-config.xml files), and src/main/resources/main-scheduledtasks.xml (optional, only needed if you have a significant number of custom scheduled tasks)
• controller - consists of all controllers. Typically will have a sub-package named 'formscripts' for controllers exposed for AJAX calls from form scripts, 'datatables' if we have any DataTables controllers, and potentially other custom endpoints. This is the only package where we should expose any endpoints to the outside world.
• dao - only needed if a separate datasource from the main one in applicationContext.xml is required. If required, typically only consists of a DAO implementation class which @Autowired's the separate Hibernate entityManager and entityManagerFactory
• exceptions - only needed if custom exceptions are required
• model - consists of all domain classes, typically POJOs. Any custom table (Hibernate/JPA) entities should live in a sub-package called 'jpa'; any other POJOs should live under appropriately named sub-packages (i.e. 'wrapper', 'view', 'enumeration')
• service - consists of most actual business logic, i.e. all service classes. Typically may have a sub packages 'formtrigger', 'scheduledtasks', 'formscript', 'datatables', 'resttrigger', or 'trigger', depending on required functionality (each package name describes roughly what the functionality would be)
• tools - consists of any 'tool' classes that logically don't belong in service because they aren't truly 'services'.
• util - consists of any 'utility' classes that aren't tools or services. Typically would be things like String manipulation, calculations, or simple null check utilities that aren't directly related to client code.
• workflow - consists of all Task/Conditional classes that make up any workflow. Typically has three subpackages, 'formtrigger', 'resttrigger', 'scheduledtasks' (for the corresponding kinds of workflows), and then more subpackages under those for the corresponding entity (i.e. 'candidate', 'placement', 'joborder').

As far as front-end code goes, all of it lives somewhere under src/main/webapp. All JSP files (i.e. views that are hosted within the starter-kit itself) live under src/main/webapp/WEB-INF/jsp. All 'top-level' folders should also have a corresponding jsp folder here; by default it contains 'main' and 'custom' (which corresponds to the default main-servlet.xml and custom-servlet.xml. You can see the jsp mapping going on in there). All other front-end code lives under src/main/webapp/static, and essentially consists of a Grunt project with ES6 transpiling and LESS compilation. More details on the build and framework itself can be found on the starter-kit documentation page; key points are that we use RequireJS to load javascript modules, and that the starter-kit outputs a build artifact called formscripts-deploy.zip that contains all of the HTML snippets you configure in BULLHORN for Form Scripts.