Page tree
Skip to end of metadata
Go to start of metadata
TitleIntegrating with Kerve
GoalDetermine how to provide Kerve with everything they need to work; and how to integrate their deliverables into our processes
Pivotal story 



Deliverables from Kerve

We expect that Kerve will need to deliver to us:

  • ERB templates for each content type, building Typecase fields into HTML content
  • SCSS files to be built alongside Lens, providing the necessary CSS for their templates
  • JS files as needed
  • Images as needed

These will be integrated by us as follows:

  • ERB templates to be added to CMS Publisher and chosen / built based on the organisation field specified on the Publish message
  • SCSS, JS and Images to use our Grunt process to produce a counterpart to Lens for School of Management pages
    • We have not produced a firm technical plan for how this will work. We will need to consult with our designers for technical details of how this will work
  • Additionally, changes will need to be made to our Hugo layouts to allow us to import the correct stylesheets and javascript in headers and footers
    • This can be triggered with appropriate frontmatter added by Publisher, based on organisation again.

We will need to agree a means of receiving these deliverables. A dedicated git repository may be a sensible solution.

Information to supply to Kerve

In order for Kerve to make functioning templates, we will need to provide them:

  • Details of the fields in each template

We have a number of options here. We could simply supply them with all of our existing templates; but we may not wish to do so for confidentiality / IP reasons.

Alternatively, we could supply them with the member variable names (and data types / expected formats of each) used by each template. This will take some work to collate from Publisher.

In both cases, there is more information on the Redis publish message that could be used. It is unlikely that any of this information will be needed, as it is mostly metadata (organisation, self-URL, user story etc)

  • Details of our Lens build process

We will need to provide Kerve with enough information that they can write SCSS files that integrate with our existing Lens files and build system. It is not currently clear exactly what that entails (we will need to consult with our designers)

  • A test environment

Kerve will need a means of testing their work. The exact form this will take may depend on how familiar they are with Ruby / Rails / ERB.

One possible solution would be for us to build a Ruby script containing preset JSON messages chosen to be representative of our various content types. This script would take as input a set of ERB templates, and output the static HTML content files as Publisher would. Ideally these would then be run through Hugo to add on the common header and footer.

We will likely have some time to decide on the best approach here, as we expect early versions from Kerve to be static pages. We don't currently expect to receive ERB until the designs have been mostly approved.