Great Crafter CMS Webinars

Check out these free pre-recorded online events! Learn more about how Crafter CMS is built and where and how to apply it to your projects!

 

Planning a Smart Mobile App Development Strategy

Why Developers Should Care About CMS

As developers, we’ve got a strong handle on how to manage and deploy our code assets.  Yet every one of us, at some point in our application build has said, “What about this text? What about these images? Where do these belong?”  That’s pretty universal.  Nearly every single application today has content in it.  Be it a web app or a native app; it’s full of strings, images, icons, media and other classes of content.

This content doesn’t really belong in our code base — because it’s not code.  These non-code assets make us as developers pretty uneasy.  We know that at some point a business user is going to ask us to make a change to one of those strings and we’re going to spend hours of build and deploy cycles to handle a 30-second code change.  We know that at some point we’re going to need to translate that content.  We know at some point we’re going to replace this UI with another one.   We know all these things  — and we know leaving that content, even if it’s abstracted into a string table or a resource bundle is going to come back to haunt us; no matter the abstraction: it’s part of the build, developers need to update it.  Developers and Systems folks need to deploy it.  

Smart developers separate code from content.  They make sure that the content in the application is completely independent of the build and deploy cycle of the application itself.  Where appropriate they make sure non-technical business users and have access to the externalized content and can update it and publish changes at any time.

Consider the following scenario:  Your application is for an insurance company.  Along comes major regulation change.  Now your (and every other application) needs to change its language accordingly.  If the content was separate from the application the response time and cost to make changes is minimal.  It’s business as usual.  If the content is not separate you are looking at months of builds, testing and deployment that costs time, opportunity and a tremendous amount of money,

What we’re really talking about is application architecture.  Making the right decisions has significant impacts on our development teams and process and as we’ve illustrated, our organization’s responsiveness and bottom lines.

Solving the Content Problem Through Application Architecture

This problem is very similar to another problem:  Websites.  Waaaaaaaaaaaaay back in the 1990’s people built and maintained entire websites in HTML by hand.  You had to be a programmer who understood the markup and how to update it and ultimately deploy it to a server once complete.  This model didn’t work. Once business started using the web to communicate to the masses marketing departments started getting involved.  Marketers wanted constant updates. Developers wanted to write code, not update copy.  They needed a solution.  The Web Content Management System (WCM for short) was born.  WCM offered a new architectural solution to manage websites. WCM allowed the developers to put the code into templates that contained placeholders for the content and gave authors a user interface to manage and edit the content at any time.  The content is managed separately from the code (the templates) and the two are brought together to create the final product. Everyone wins.

We need the same capabilities that WCM provides but for our applications.

Why Not Use a Traditional CMS?!

Simple.  Traditional CMS platforms have the wrong underlying design. Most CMS platforms were built or are based on the same design as CMS’s that were built 20 years ago.

  • They were built to manage pages:  Most CMSs do not have a generic concept of what content is.   These systems were built to manage pages.  You might be able to contort the system to get what you want from it but it will be a hack. You need a CMS that is agnostic to the kind or type of content you need to manage.
  • They rely on the wrong type of data tier: RDBMS/SQL databases were the primary backends for data regardless of the problem and open source options like MySQL were readily available.  You need a CMS that leverages a data tier that is more distributed and flexible.
  • They are built on the wrong technology: Many CMS platforms are built in PHP.  That’s fine for certain use cases. But frankly, Java has a larger community, more library support and a lot of powerful platforms like Solr, Elastic Search, Hadoop (and many others) that plug into a Java CMS perfectly.  Why run multiple tech stacks to accomplish a single goal?
  • They aren’t secure: Most CMS platforms couple authoring and delivery together in a single database.  That means work in progress (like pending policy updates) is available in the delivery runtime to anyone who finds a way into the database.  That can spell disaster in the event of a hack. Large companies and governments have suffered expensive and dangerous leaks due to this kind of coupled, insecure architecture.
  • They don’t support multi-tenancy: Most of the CMS platforms out there are not multi-tenant.  If you’re going to back apps with a CMS you need a CMS that will let you properly segregate and secure content between apps.  No one wants to do a CMS install PER app.
  • They don’t scale:  RDBMS is hard to scale.  You either cluster or replicate.  Both have serious issues when it comes to really large, global and auto-scale type deployments.  Supporting an app with your CMS will demand scale. Design for scale from the start.
  • They don’t fit into your development tools and process: When most CMS platforms were designed the content authors were the only audience that mattered.  Today it’s different.  Developer tasks like managing templates, CSS, JavaScript, content models and other artifacts need to be just as easy — and it needs to fit in with your existing workflow.  That means Git source code management, Continous Integration (CI), Integration with your IDE, the ability to fork and support multiple teams simultaneously.

If Not Traditional CMS, Then What? A Modern CMS, That’s What!

To get different results you need a different design.  You need a modern CMS:

  1. Built with the right technologies like Java, Spring, Groovy, Solr, Git.  These are the technologies that will be easy to hire for, will fit into and integrate with any enterprise and will have the out of the box capabilities and horsepower to back any scale deployment.
  2. Decoupled architecture that cleanly separates authoring and content delivery responsibilities on to separate, independently highly securable, highly scalable infrastructures by a publishing process.  Decoupled Architectures don’t have work in progress outside the firewall.  They are much easier to scale.
  3. Built on scalable document-oriented data tiers like XML+disk/Git and Casandra and others.  Disk-based tech is much better for streaming rich content and support global distribution better because they don’t need to be clustered.  At a minimum, you want something that’s document oriented and that distributes globally better than a than a SQL backend RDBMS.
  4. Content type agnostic:  From strings to web pages, to videos and virtual reality experiences.  The CMS needs to accept any kind of content.  That comes down to how content is modeled and how it’s stored.  Does the CMS store content in a SQL database or a JCR repo?  Red flag.  Can’t provide Headless Content / APIs AND rendered content?  Another Red Flag.
  5. Is Multi-Tenant. You need to be able to support many customers/apps on a single install. Either you support it or you don’t and today it’s a must!
  6. Supports authors AS WELL AS developers and DevOps. Developers don’t want to work in some clunky CMS.  They want to work locally in an IDE, then be able to work with their team and ultimately go through the entire workflow out to production.  A modern CMS gives them this.
  7. Open Source.  Open is better than closed. The debate is over. Is it a must?  No. But you’ll get more for your money and you’ll get a lot more innovation at a faster rate if you leverage open source.

Where can I find a Modern CMS?!

Check out Crafter CMS!  Crafter CMS is a modern, 100% open source Java based CMS built on Git!  It’s easy for authors, Amazing for developers and Awesome for DevOps!  Crafter doesn’t sit on a SQL database or a JCR repo like so many CMS platforms out there.  It’s built on Git, Java/Spring, and Solr.  It brings the power Git to CMS!  Authors have true versioning.  Developers and DevOps can work they way they are used to, with the tools they are used to based on the technologies they already know.  Crafter CMS is 100% content type agnostic, highly secure, high performance and scales like nothing else.  If you’re building any kind of application or digital experience, you have content, and you NEED Crafter CMS.  Great experiences are crafted!

 

Creating and Installing Project Blueprints in Crafter CMS

What are Blueprints?

Blueprints are Crafter CMS project templates. It provides an initial structure/layout for your site containing one or more of the following: content types such as pages and components as described in Content Modeling, static assets such as images, videos, etc., and site configuration files for managing items in the blueprint such as taxonomies (categories, segments), roles, permissions, etc.

Cook Books - Blueprint AnatomyIn the blueprint that comes out of the box with Crafter CMS, Website_Editorial blueprint, it provides us with an initial structure for our site, along with the site navigation, content inheritance, taxonomies for organizing the content such as categories and segments, which was also used for targeting content, static assets such as the initial images and fonts used for the site and configuration files for managing things like the personas for targeting, the permissions for all the items in the site, the role mappings, the RTE configuration, etc. To see more of the Website Editorial blueprint, please see Your First Website where we create a site based on the Website_Editorial blueprint.

As mentioned earlier, blueprints allows us to generate sites with predefined layouts, contents and configuration. Blueprints could be a site theme or an API only site. New blueprints can be created from a site and added into Crafter CMS allowing the creation of more sites based on the new blueprint. In the section that follows, we will see how the Empty blueprint that comes out of the box from Crafter CMS and an existing site is used to create a new blueprint.

How do I make my own Blueprint?

Start by Installing and Starting Crafter CMS.

Blueprints are almost the same as a site. So, you can use a new site created from the Empty blueprint as the starting point for your blueprint. (See Your First Website but create it from the Empty blueprint).

Adapting an HTML template

If you have an existing pure HTML template (and if you don’t, you can find free ones, even with commercial friendly licenses like MIT and some flavors of Creative Commons), you can adapt it into a blueprint.

Cook Books - Template AnatomyGenerally, pure HTML templates have a file structure similar to the picture above. To start, you’ll want to copy all files except for index.html and any other .html files to your site’s static-assetslike this:

Copy folders to static-assetsHTML files will become Freemarker templates. For this cookbook, you’ll see how to adapt an index.html page, then you’ll be able to adapt other pages. Start by editing the main page’s ftl template, and replacing its contents with the index.html’s contents:

Copy index.html contents to page ftl file.You should keep <#import "/templates/system/common/cstudio-support.ftl" as studio /> at the very start, and add <@studio.toolSupport/> right before the body tag closes to have proper Studio support. Next, all resource locations are probably pointing to the wrong location. To fix this, replace every relative url that doesn’t point to a page (this would include <link rel="stylesheet" href="tags for CSS files, <script src=" for JS files, <img src=" for image files, and <source src=" for video and sound files) such that it starts with /static-assets/ and points to the corresponding file.

Modify the Rich Text Editor configuration so it uses your template’s stylesheets. See Rich Text Editor (RTE) Setup

At this point, you should have a static page that looks just how the template is supposed to look. For every other HTML page, you have to either create a new page content type and, like with index, replace its ftl template with the page’s source; or, generalize the content type, with proper content modeling, such that multiple pages share a single ftl template and vary only in the components they contain. Let’s see some tips for this.

Content Modeling

A powerful and extensible blueprint that can be used in a variety of pages and scenarios needs proper Content Modeling, so you have to be familiar with it before proceeding.

A good blueprint separates each meaningful chunk of HTML code into a component. For example, whether you implement an “Our Team” section using a repeating group or multiple “Teammate” child components, it still has to be a separate type that only contains information related to “Our Team”. Whether it is a Component or a Page, it shouldn’t contain “Product” information. Once you have identified HTML chunks with a meaning, start by moving them into their type’s template.ftl. Next, replace any information with a variable from the contentModel (and add the respective control to the Content Type). Unless they are extremely simple, most pages will contain child components, even if they are just a header and footer component provided by the Section Defaults.

There are some best practices to help you:

  • Prefix all your Content Type’s display label with either “Component – ” or “Page – ” as appropriate.

  • Make use of Section Defaults. Most sites will have a site logo that will be used all throughout the site, this is a perfect use case for Section Defaults.

    • Additionally, since Section Defaults have inheritance mechanics, a child folder that’s meant to have private pages could have it’s own Section Defaults that overrides the normal site logo with a more private looking one, signalling users that they are in the intranet.
    • You can apply this similarly for headers, footers, log in floating forms, and many more.
  • Use drag and drop but keep it to a minimum. At the moment, you can’t limit what kind of components can be dropped into a container, so this enormous amount of flexibility can make for a confusing user experience. Picture having a page with a group of sections, that each contains headers. If both sections and headers are drag and droppable, an user could accidentally drop a section inside another section without noticing instead of just reordering. It could be more comfortable that only sections are drag and droppable.

  • You can use label controls to add additional information to the content type’s form. This is useful to add tips or additional information for advanced controls.

  • Prefer repeating groups over child components. Child components are ultimately more versatile, but if you are only going to repeat text, and that text is not going to appear outside the repeating group again, it’s a better user experience to just use a repeating group.

    • Bear in mind that you can’t have nested repeating groups, so only the innermost repetition can be a repeating group.
  • You can set up folders for specific content types, and you can enforce them by using <paths> in your types’ config.xml. Use includes whenever you want to whitelist some paths, and use excludes to blacklist some paths, but do not mix them. For more examples, see Content Creation Permissions

    <paths>
        <includes> <pattern>REG_EXP_HERE</pattern> </includes>
        OR
        <excludes> <pattern>REG_EXP_HERE</pattern> </excludes>
    </paths>
    
    • You can also use this to enforce single page blueprints by using <excludes> <pattern>^/.*</pattern> </excludes> in your page type’s config.xml, effectively forbidding from creating a new page.
  • Ensure your blueprint supports In-Context Editing.

  • For most sites, you’ll have to override Studio’s default navigation menu tags. You can do this by reading Rendering navigation.

Above all, blueprints should be usable and simple.

Packaging

Suppose {CRAFTER_HOME} is the path to your Crafter installation so that it contains the startup scripts, apache-tomcat/ and data/ folders.

Blueprints reside in {CRAFTER_HOME}/data/repos/global/blueprints since Crafter 3.0. Each folder corresponds to a blueprint (You may notice the empty and website_editorial blueprint folders), you can start by copying the empty folder and renaming it to your blueprint’s name, like “my_blueprint”.

Your site exists in {CRAFTER_HOME}/data/repos/sites/your-site-name. Inside, you’ll notice 2 repos, sandbox and published. Inside of either of them, lie the site’s folders, but since sandbox contains your site as it currently exists in your Studio preview, we’ll be grabbing the files from this one. You need to move this site’s folders into an external folder named as your blueprint, but avoid copying the .git/ folder contained there, as it’s unnecessary for the final distributable package and may even contain sensitive information.

Note

Don’t merge folders, before copying any folder, delete the existing one so any renamed or deleted files don’t persist.

Copy ``scripts/``, ``site/``, ``static-assets/``, ``templates/``In the previous screenshot, we didn’t copy the config/ folder. Why? (Warnings). You can either:

  • Copy the config folder and modify permission-mappings-config.xml and site-config.xml to use {siteName} again as explained in (Warnings)
  • Keep config as is and only copy the files you’ve modified. This will likely include the whole config/studio/content-types/ folder and config/studio/preview-tools/components-config.xml for drag and drop.
  • Keep your blueprint in a VCS which will allow you to compare it against your changes and interactively see when to preserve the old version. This will also help you make any updates when blueprints get updated. You can either use git or a visual diff tool.

Now that you have merged your “site” with the Empty blueprint in the proper way, the resulting folder is ready to be distributed. To install, follow the next steps.

Installing

On Crafter 3.0

  1. Copy your blueprint folder into {CRAFTER_HOME}/data/repos/global/blueprints.

  2. Once you do, commit the change to the global repo ({CRAFTER_HOME}/data/repos/global/) by using git, and your blueprint will now start appearing when you try to create a new site.

    • Crafter 3 uses a vanilla version of Git, so regular git commands work as intended. To commit your changes so Crafter can see it, head to {CRAFTER_HOME}/data/repos/global/blueprints and git add your modified files like this

      git add <filename>
      

      for each filename. Or, to add all at once use:

      git add --all
      
    • And once you are done, commit them with the following command:

      git commit -m "<the commit’s description>"
    • No need to push, there’s no remote configured. You can also use any git client. Now, it will be available when you create a new site.

Using the Blueprint

Once you’ve installed your blueprint using it is simple!

After logging in, you’ll see the MySites screen (Below). Click on Create Site

Your First Website - Sites Screen

Give the site a friendly name for the Site Id , a description and then choose a blueprint. We’re going to be using the “Website_Editorial” blueprint. Blueprints offer you a starting point for your website. New blueprints can be created and installed in to the system. As you are entering the site id, spaces are removed and upper case letters are converted to lower case letters.

Your First Website - Create a Site

Click on Create and wait for the system to create your site based on the blueprint. It’s creating the following: configuration, site content, and permissions based on the template provided by the blueprint.

Your First Website - Creating a Site Spinner Dialog

When it’s done you will be taken to the Home Page of your site:

Your First Website - Home Page

Start an Activiti Process via Rest Script in Crafter CMS

Activiti is a powerful open source workflow engine built by Alfresco.  Incorporating a workflow engine into your customer and employee facing sites and portals is an excellent solution for automating complex workflows that cross system boundaries while providing the user with a simple to use, contextual user experience.   Working for a bank or an insurance company and need to workflow contracts with customers?  No problem. Crafter CMS (an open source Java based CMS) paired with Alfresco is a perfect solution.  It’s customer friendly, highly scalable and about as powerful as enterprise technology gets!

In this blog, I’ll demonstrate the most straightforward example of a Crafter CMS REST service being used to start an Activiti Process.

Prerequisites

  • You have Activiti (http://www.activiti.org/) installed
    NOTE:
    The authentication and process are hard coded to simplify the example

Step 1: Create a REST Controller

  • Under Scripts/rest right click and click create controller
    • Enter start-process.get as the controller name
  • Add the following code to the controller. This code assumes Activiti is deployed into the same container as Crafter Engine.
@Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.7')
@Grab('oauth.signpost:signpost-core:1.2.1.2')
@Grab('oauth.signpost:signpost-commonshttp4:1.2.1.2')

import groovyx.net.http.HTTPBuilder
import groovyx.net.http.ContentType
import groovyx.net.http.Method
import groovyx.net.http.RESTClient

def http = new HTTPBuilder("http://localhost:8080")
def user = "kermit"
def password = "kermit"
def authPair = user + ":" + password
def authEncoded = authPair.bytes.encodeBase64().toString()

http.setHeaders([Authorization: "Basic "+authEncoded])

def ret = null

http.request( Method.POST ) {
    uri.path = "/activiti-rest/service/runtime/process-instances"
    // ACTIVITI ENTERPRISE URL
    // uri.path = "/activiti-app/api/enterprise/process-instances"

    requestContentType = ContentType.JSON
    body =  [ processDefinitionKey: "vacationRequest", variables:[  [name:"employeeName", value: "Russ"], [name:"numberOfDays", value: "5"],[name:"startDate", value:"10-08-2015 11:11"],[name:"vacationMotivation", value: "rest"]    ]]

    response.success = { resp, reader ->
        ret = reader
    }
}

return ret

Step 2: Execute the Service

Step 3: Verify that a new process instance has been started

Active Cache a RESTful Response in Crafter CMS

This article will demonstrate how to create a RESTful service in Crafter Engine that has predictable performance and reliability when your service relies on an external service.

Any time your services depend on another service there is a cause for concern. You can’t control the performance or the availability of the external service. Further, if the response of the external service is not unique across calls then there may be no real need to call out to it on each request you receive.

In this case, what you want to do is cache the request from the external service and have your service attempt to get the content from the cache. Active cache is a built in Crafter CMS capability that makes building these sort of solutions much easier. You tell Active Cache what you want, how to get it and how often to refresh it in the background. From there on, you simply ask Active cache for whatever the current response is.

Step 1: Create a REST Controller

Under Scripts/rest right click and click create controller
Enter my-data.get as the controller name
Add the following code to the controller.

 import org.craftercms.core.cache.CacheLoader
 import org.craftercms.core.service.CachingOptions
 import groovy.json.JsonSlurper

 def cacheService = applicationContext["crafter.cacheService"]
 def cacheContext = siteContext.getContext()
 def myCacheKey = "aServiceCallResponse"
 def loader = new ExternalServiceLoader()

 def value = ""
 def responseItem = cacheService.get(cacheContext, myCacheKey)

 if(responseItem == null) {
    // item is not cached, get the value
    def myObject = loader.load()
    value = myObject

   // cache the value with a loader to periodically refresh its value
    def cachingOptions = CachingOptions.DEFAULT_CACHING_OPTIONS
    // def cachingOptions = new CachingOptions() // define your own options
    // cachingOptions.setRefreshFrequency(1) // set the number of ticks for refresh

    try {
        cacheService.put(cacheContext, myCacheKey, myObject, [], cachingOptions, loader)
    }
    catch(err) {
        logger.error("error adding ${myCacheKey} to cache: ${err}")
     }
 }
 else {
    value = responseItem
 }

 return value

/**
 * Define an active cache loader that will be used to prime and then
 * periodically refresh the cache with the latest data from an external
 * service.
 */
 class ExternalServiceLoader implements CacheLoader {
    Object load(Object... parameters) throws Exception {
       def externalServiceHost = "http://api.population.io/1.0"
       def externalServiceURL = "/population/United%20States/today-and-tomorrow/"

       // call the service
       def response = (externalServiceHost+externalServiceURL).toURL().getText()

       // parse service's the JSON response to an object
       def result = new JsonSlurper().parseText( response )

       return result
    }
 }

Step 2: Execute the Service

Open a browser and hit the following URL: http://localhost:8080/api/1/services/my-data.json
Note that your hostname, ports and pageId values may differ than the example
See results

Your CMS is the Walking Dead, Crafter CMS is the Antidote

Your CMS was built 20 years ago.  Think about that.  It’s true.  For the vast majority of CMS technologies out there, the core of the system and the architecture was put in place 20 years ago!

Got an RDBMS Database? How about a JCR repository?  Having trouble scaling? Can’t easily move code and content between environments?  Can’t easily go global or build at cloud scale? No?  That’s because your CMS architecture is 20 years old.  It matters.

How about development?  Do your developers love your CMS?  Can they innovate quickly?  Can you support multiple teams and workstreams?   Can you handle content that isn’t a web page? Can you quickly adapt to new kinds of channels?  No again?  20 years ago the pace of development was slower, expectations were lower.  Today the demands are much higher but CMS vendors and technologies have not kept pace.

Your CMS may still be walking but it’s already dead.  You can change from one product to another but it’s not going to solve the fundamental problem.  Traditional CMS is dead.

It’s time to breathe new life into CMS.

 

At Crafter Software we’ve been working hard for several years to completely re-invent and redefine the architecture of CMS for today’s’ needs.   We’ve let go of industry dogma and the same old design patterns.  We’ve stayed focused on the core rather than chasing the bright shiny objects, buzzwords, and technologies. We’re committed to being great on what matters most to organizations that depend on digital channels: innovation.  The speed of innovation and the ease of deploying it at scale.  We’ve built a CMS with a completely different architecture designed to support today’s demand for innovation. As a result, the world has a completely new take on CMS, built for the “crafters” and innovators, Crafter CMS:

  • Can manage any kind of content and experience
  • Supports any channel and can easily adapt to new ones as they emerge
  • Is easy for authors:
    • Web-based publishing tools
    • Safe editing sandbox
    • Desktop tool support
    • Completely in-context
    • Drag and drop
    • Workflow & versioning
  • Is amazing for developers:
    • Based on well known, proven technology stack: Git, Java, Spring, Groovy and Solr
    • Native support for Git
    • Allows developers to work locally and in teams
    • Supports multiple workstreams
    • Enables team to easily move code & content between environments
    • Makes it possible to use desktop native development tools
  • Is insanely great for ops teams:
    • Extremely high performance
    • Has a small footprint
    • Is built to run in secure environments
    • Is multi-tenant
    • Is horizontally scalable
    • Is geo Distributable

Check it out! Crafter CMS is powering 1000s of the world’s top digital experiences.  It’s open source, it’s powerful and it’s wildly different than the hordes of “zombie” CMS’ out there that put a new name and a new skin on the same 20-year-old architectures and approaches.  If digital content and innovation are critical to your success, don’t fall prey to yet another zombie CMS.  Stop Walking.  Start Running.  Check out Crafter CMS!

Responsive vs Adaptive Web Design: Better Together

Responsive web design (RWD), the ability for your web application to “respond” to the size of the view port (traditional screen size vs mobile screen size) is common place and practice today.  Responsive design leverages client sidefront end UI frameworks to hide, show, stack, shrink and grow elements on the screen in a way that is appropriate for the size of the device’s screen.  In essence, it is many user interfaces in a single code base.

Adaptive web design (AWD), a (seemingly) alternative approach to RWD is a server side capability to respond to the client with completely unique templates / markup for a given device type (amongst other facets.)  Adaptive design, while extremely powerful is somewhat less common in part because it relies on a server and is thus a less general technology. It’s also less prevalent in part because, for a large class of problems, RWD is “enough” to get the job done.  However, as complexity and sophistication of requirements mount, adaptive design starts to show clear advantages over a purely responsive approach.

Responsive design and adaptive design are often thought of as an either/or architectural choice.  There is clear overlap in the problems they address and each approach has clear strengths and weaknesses over one-another.  Let’s take a quick look at a side by side comparison:

Comparison

Technical Approach

Responsive Design: Leverages server agnostic front end frameworks (eg. Twitter Bootstrap) to render a appropriate content flow for the given screen size.

Adaptive Design: Leverages back-end server templates (e.g. Crafter CMS) to render distinct markup for the device and context requesting the application.

Strengths

Responsive Design:

  • Mainstream approach with many frameworks that can be applied to any backend technology.
  • Single code base

Adaptive Design:

  • Truly unique markup can be delivered based on any kind of context (not just screen size.)  This means it’s much easier to deliver contextual functionality to your users.  Example:  A retail store .com site that has a traditional marketing website at mystore.com but once it’s detected that a user is inside a physical store location, it gives them a personalized in-store assistance to enhance their shopping experience.
  • Performance.  With AWD you send only the data you need for the experience you are delivering.  On slower, mobile networks that can make a big difference.

Weaknesses

Responsive Design:

  • Single code base.  The more variations you want to support, the more code and complexity there is in that single code base.  This can get out of control.
  • Performance can be an issue:  RWD sends all of the code for all variations to every consumer whether or not they will see it in their flow or not.  If the amount of code is significant, this can lead to a performance hit on slower/mobile networks.
  • It’s difficult (although not impossible) to address different contexts beyond screen size with Responsive design.  RWD was really intended to different screen sizes (view ports.)  Stretching its role beyond that takes the technology out of its wheelhouse.

Adaptive Design:

  • You need a server backend to support AWD.
  • Instead of a single UI design and template code base, you potentially have many.  If you don’t manage and factor the code properly it will be more difficult to maintain.

Opportunities

Responsive Design:

  • Provides a usable experience on any screen size.

Adaptive Design:

  • Provides a usable experience on any screen size.
  • Provide faster experiences for your users.
  • Allows you to truly contextualize the experience.  Device type/class/screen size is really just the tip of the iceberg.  Once the server is involved any type of contextual data (location, previous use, time of day, etc) can be used to deliver unique and relevant experience/features to the user.  That can be huge.

Threats

Responsive Design:

  • If requirements go beyond screen size, RWD may not be the appropriate solution.
  • If the number of variations is too high performance and code complexity may be an issue.

Adaptive Design:

  • Managing unique templates is a heavier approach that requires server technology and the skills to go along with it.

Better Together

While RWD and AWD are most commonly looked at as competitive approaches, the simple fact is that they are not.  These two approaches are in fact mutually exclusive with another and can be combined to acquire the benefits of both.

Responsive design is front end technology.   Adaptive design is backend technology.  Combine them.

Consider leveraging Adaptive design to drive truly unique and contextual markup to the user for what they are doing, on the device of their choice at that moment.   Allow the front end to leverage Responsive frameworks to make sure those experiences flow nicely on a given device.  For performance and code maintainability, as your RWD code grows in complexity and size, consider breaking it down in to smaller code bases that can be individually delivered to a device by RWD (the server.)

A simple example of this is to have AWD templates for Small, Medium and Large screens.  Each with their own unique features and markup.  When it comes to the specifics like an iPhone vs a Galaxy smart phone (both considered small), RWD steps in to make the minor adjustments required to provide a perfect fit for the given device type. This makes the code more maintainable and more importantly it makes the user’s experience much more zippy.

 

Patterns for Integrating 3rd Party Content in Your CMS

There are often times when you will want to integrate content in your site that does not ORIGINATE in your content management system.  In this article we’ll look at a few high level patterns for integration and discuss the pros and cons of each approach.

Approach 1: Sync to CMS, publish to site as full content

Approach 1 focuses the integration at the CMS level only.  Content is either pulled or pushed from the 3rd party system in to the CMS.  From there it can be further processed and is ultimately published to the website where it can be used like any other type of content including native involvement in search and targeting scenarios.

Pros

  • 3rd party content is converted to 1st class content which allows it to be used natively by the system with not rendering engine level integration.
  • Authors may augment the content coming from the 3rd party system to include additional content and metadata
  • This integration is typically very simple
  • There is no impact on the performance or complexity profile of your delivery environment

Cons

  • Syncs can be tricky.  Remember content originates in the 3rd party system but it’s possible that it may need to be further modified by the CMS.  
  • A mechanism and a process must be defined that allows content updates to flow from the 3rd party system in to the CMS.  Typically this involves a strong ID that identifies each object, a mapping of fields that can always be overridden in the CMS  and mechanism for communicating creates, updates and deletes.

Other Considerations

  • By passing through the CMS 3rd party content is not “immediately” available on the website.  Content must wait for the sync mechanism to operate. Further, there may be workflow required before content can be made live.

When to use this pattern

  • This pattern is often preferred
    • It is relatively simple
    • Allows augmentation of the content in the CMS
    • Requires no run-time integration
    • Has no impact on the performance and SLA of the run-time

When not to use this pattern

  • When any create, update or delete to the content in the 3rd party system must be IMMEDIATELY available on the live site.

Approach 2: Partial sync to CMS, full details retrieved at run-time

Approach 2 syncs a simple jacket for the content to the CMS but relies on runtime integration with the 3rd party system for the full details of the 3rd party content.  The jacket in the CMS carries only the metadata required for the 3rd party content to participate in search, targeting and other dynamic behavior on the site.   The “sync” that creates the jacket in the CMS may be done through a simple integration or can even be a manual process.

Pros

  • Less content is relied on from the CMS which means that for items that have been previously published, detailed data is always 100% in sync with the 3rd party system.
  • Search, targeting and other dynamic capabilities native to the delivery system may still be relied on for functionality within the site.

Cons

  • There is a runtime dependency on the third party system for the actual content.  If that site is down, the content is unavailable.
  • As discussed in approach 1, syncs can be tricky.  In the case of approach 2 we still have some sort of manual or automated sync to create a jacket in the CMS.
  • In this approach there are 2 points of integration 1 at the CMS and one at delivery.  When you add additional moving parts, you are adding operation complexity that must be maintained and supported.
  • Content can be out of sync between what the site has in it’s jacket (and this in the indexes) and what is in the 3rd party system.  You must consider all cases: create, update, and delete

Other Considerations

  • By creating a run-time dependency between the delivery system and the 3rd party system you dictate that the 3rd party system must (generally) have the same reliability and performance capabilities of the delivery system.

When to use this pattern

  • When detailed aspects of the 3rd party content must be IMMEDIATELY up to date.
  • When it is impractical to import all of the 3rd party content in to the CMS.  A typical use case for this approach is 3rd party hosted video.  The CMS may contain only basic metadata and thumbnails while the 3rd party system retains all of the various video encodings.

When not to use this pattern

  • If the website and the 3rd party system must be 100% in sync on ALL aspects of the content at all times
  • When approach 1 is viable.

Approach 3: Run-time integration only

Approach 3 focuses integration at the content delivery tier only.  Display and behavior related to the 3rd party content is all handled through integration.

Pros

  • Approach is the most simple from a “moving parts” perspective. There is no syncing involved
  • 3rd party content is immediately up to date when changes are made in the 3rd party system

Cons

  • There is a runtime dependency on the third party system for the actual content.  If that site is down, the content is unavailable.
  • All content display, and behavior such as query driven listings, content targeting, and search must be integrated.
  • It can be difficult to integrate functionality like search where CMS content and 3rd party content are placed together on the page in a seamless way.  This is because the implementation is very likely to require issuing at least two queries (one to the CMS and one to the 3rd party system.)

Other Considerations

  • By creating a run-time dependency between the delivery system and the 3rd party system you dictate that the 3rd party system must (generally) have the same reliability and performance capabilities of the delivery system.

When to use this pattern

  • When 3rd party content must be IMMEDIATELY available and up to date on the site the instant it is updated in the 3rd party system.
  • When there is no need to rely on native capabilities of your delivery platform for delivery of the content and dynamic behavior (like search.)

When not to use this pattern

  • When option 1 or 2 are viable and use of native capabilities of the content delivery platform useful / required.

 

Never Use a Traditional CMS to Back Your Applications!

Almost every application today, regardless of the delivery technology and channel (web, mobile, kiosk, etc) has content in it. Smart developers quickly realize that managing the strings and the other content should be done outside the application rather than embedding it in the code base. Rather than build custom databases and authoring tools most developers look for a Content Management Systems (CMS) to fill this need. But there’s a problem with that…

Traditional CMS technologies (WordPress, Drupal and many others) have an architecture and approach that was designed and built over 20+ years ago. Let that sink in.

How can something built over 20 years ago or even something that was built “today” but that maintains the same basic pattern that was introduced over 20 years ago possibly be the right answer for today?  It can’t.  Here is just a few of the issues:

  • They are built with older technologies like legacy PHP, Struts, Sling and JSPs etc.
  • They don’t scale easily/cost effectively because of shared content stores based on SQL and Java Content Repositories (JCR.)
  • They are monolithic.  Most systems couple authoring and delivery which makes the system complex to maintain, hard to secure and even more difficult to scale.
  • They mandate rigid development and theme frameworks that slow down and limit innovation.
  • They make it difficult to roll out new functionality through your dev-ops process.
  • Thy are full of bolt-on solutions to keep up today’s needs like content as a service. Remember when they were designed, the world was just web pages.  You can’t teach an old dog new tricks.
  • Because of their heritage as page centric platforms they lack flexibility

Who in their right mind would put a technology with all that baggage in their application architecture?! Don’t do it. Just don’t.

So what’s the answer?  Back to building custom databases and editorial tools?  No.

To solve this problem a class of CMS solutions have show up in the called Headless CMS.  These solutions provide very basic content management and deliver the content as a API.  This capability is called Content as a Service (CaaS.)  Many of these are available only as Software as a Service (SaaS) solutions in the cloud.  These solutions solve some of the problems that traditional CMS solutions have by moving all presentation and development responsibility to the consumer (outside the CMS) and making scalability a vendor issue.

If all you need is “headless content”/CaaS and public cloud/SaaS vendors are a viable answer for you then you may have a solution.

However, many situations call for a solution that includes but go far beyond headless content — templates, personalization engines, queries and other key CMS capabilities are still needed by most solutions. Further, some companies still require on-premise installations.  For these organizations the field of viable solutions is much smaller.  They need a fully featured CMS platform without all the baggage — one that that has been completely re-architected and re-oriented for today’s high rate of innovation/iteration and digital experience challenges. That’s where Crafter CMS, an open source, Java based, enterprise-grade CMS really shines.

Crafter CMS is not a traditional CMS. Crafter CMS is a new platform built on modern technologies and a completely different architecture that is designed for situations that require rapid innovation, flexibility, enterprise integration and extreme performance and scalability.

How is Crafter CMS different from traditional CMS technologies? Here are 10 reasons why:

  1. Not page centric: Crafter was built to manage any kind of digital experience and related content.  Unlike legacy CMS software, it’s not page centric.
  2. Modern technology: Crafter is built with today’s most modern enterprise friendly technology like Java, Groovy and Spring, Git and Apache Solr.
  3. Tech you know, skills you have: While Crafter CMS has a lot of built in services and capabilities it doesn’t add or enforce a lot of framework. Developers leverage existing skills for familiar technologies rather being forced to learn and use platform/vendor specific technologies, and frameworks.
  4. Rapid development: Coding support for Groovy and Freemarker scripting removes the need to for heavy coding and deployment cycles.
  5. Amazing for devs and ops: Crafter fits seamlessly into your development and DevOps process. Finally there’s a CMS available that is not only powerful from a development perspective but that also plugs into your development process!
  6. Micro servicesCrafter is a decoupled CMS with separate authoring/management and delivery capabilities that are built on a micro services architecture.
  7. FAST! Crafter is blazingly fast. Rather than use databases and JCR repositories that are fundamentally slow and difficult to scale, Crafter uses an in memory database, disk and Apache Solr for content storage and retrieval.
  8. Extreme scalability: Crafter is horizontally scalable. Experiencing a huge surge in “traffic”? Just add more nodes. There’s no database to scale behind Crafter’s delivery tier. Further, because Crafter uses simple but powerful technology to drive dynamic content a single server can do a tremendous amount of work.  That means fewer servers are required to get the job done.  Fewer servers translates to less infrastructure, less labor, less cost.  Huge win.
  9. Geo-deployable: Crafter is geographically scalable and can even serve content in remote or disconnected environments. No databases. No clusters. No problem.
  10. Proven: Crafter CMS is battle tested and powering content and experiences at many of the world’s top brands and most innovation-forward companies.

Separating content from code is smart move. Betting on a traditional CMS to try an make it happen when you need development agility and scalability is a dumb move. Check out Crafter CMS!  It’s a totally new take on what a CMS platform should be!!

Querying Content in Crafter CMS

Types of Content Queries

Crafter CMS supports 3 specific types of content queries:

  • Cross content Lucene/Solr queries. This enables you to query any/all content objects, by any group of properties.)
  • Filtered Structural Queries. This enables you to query against the repository structure e.g. “Get all articles by author XYZ”
  • Content Item specific query. This enables you to write queries inside of a given content item.

Type 1: Make a Lucene/Solr Query

The following code examples use the Crafter Search Service in Crafter Egnine to get content. You can find the interface for this service HERE.

def queryStatement = 'content-type:"/component/article" AND author:"Russ Danner"'

def query = searchService.createQuery()
query = query.setQuery(queryStatement)

def executedQuery = searchService.search(query)
def itemsFound = executedQuery.response.numFound
def items = executedQuery.response.documents

return items

Type 2: Make a Query for Content Based on Structure

The following code examples use the Site Item Service in Crafter Egnine to get content. You can find the interface for this service HERE.

def topNavItems = [:]
def siteDir = siteItemService.getSiteTree("/site/website", 2)

if(siteDir) {
    def dirs = siteDir.childItems
    dirs.each { dir ->
            def dirName = dir.getStoreName()
            def dirItem = siteItemService.getSiteItem("/site/website/${dirName}/index.xml")
            if (dirItem != null) {
                def dirDisplayName = dirItem.queryValue('internal-name')
                   topNavItems.put(dirName, dirDisplayName)
            }
   }
}

return topNavItems

Make a Query for Content Based on Structure with Filter

The following code examples use the Site Item Service in Crafter Engine to get content. In the example we build on the Site Item Service of getting objects under a specific tree in the repository by supplying a filter that will be applied to each object first to determine if it should be part of the result. Filters can make their determination based on the path or the content or even “outside” influence.

  • You can find the interface for this service HERE.
  • Note in the example below we define our own filter based on the ItemFilter interface found HERE.
  • However, you may use out of the box filters as well if they meet your needs. These are found HERE.
  • Finally be aware that for simple filename patterns, methods for this already exist in the Site Item Service and no filter is required (but they make for an simple to understand example.)
import org.craftercms.core.service.ItemFilter
import org.craftercms.core.service.Item
import java.util.List


def result = [:]
def navItems = [:]
def siteDir = siteItemService.getSiteTree("/site/website", 2, new StartsWithAItemFilter(), null)

if(siteDir) {
    def dirs = siteDir.childItems
    dirs.each { dir ->
            def dirName = dir.getStoreName()
            def dirItem = siteItemService.getSiteItem("/site/website/${dirName}/index.xml")
            if (dirItem != null) {
                def dirDisplayName = dirItem.queryValue('internal-name')
                   navItems.put(dirName, dirDisplayName)
            }
   }
}
result.navItems = navItems

return result


/**
 * Define a filter that returns only items that have a name that starts with "A" or "a"
 */
class StartsWithAItemFilter implements ItemFilter {

    public boolean runBeforeProcessing() {
        return true
    }

    public boolean runAfterProcessing() {
        return false
    }

    public boolean accepts(Item item, List acceptedItems, List rejectedItems, boolean runBeforeProcessing) {

      if (item.getName().toLowerCase().startsWith("a")) {
          return true
      }

      return false
    }
 }

Type 3: Make a Query Against Fields in a Content Object

The following code examples use the Site Item Service in Crafter Engine to get content. You can find the interface for this service HERE.

def result = [:]
def segment = "a segment value" // could come from profile, query param etc

// load a specific content object
def itemDom = siteItemService.getSiteItem("/site/components/sliders/default.xml")

// query specific values from the object
result.header = itemDom.queryValue("/component/targetedSlide//segment[contains(.,'" +  segment + "')]../label")
result.image = itemDom.queryValue("/component/targetedSlide//segment[contains(.,'" +  segment + "')]/../image")

return result