![]() ![]() When a module which does that is installed, SPALP takes care of creating a landing page node for it, and importing the initial configuration onto the node. Each application needs its own module to declare a dependency on SPALP, define a library, and include its configuration as JSON (with associated schema). On its own, the module doesn’t do much other than provide an App Landing Page content type. So, guided by these principles, I’m very pleased to announce the Single Page Application Landing Page module for Drupal 8, or to use the terrible acronym that it has unfortunately but inevitably acquired, SPALP. This helps to future-proof our code, because it’s more likely that evolving requirements can be met by a configuration change, rather than needing a code change. For instance, a recent client requirement to promote their native applications led us to build the App Banners module.Īiming to make our modules open source wherever possible helps us to think in systems, considering the specific requirements of this client as an example of a range of other potential use cases. There didn’t seem to be an established approach for this, so we’ve built a module for it.Īs we’ve previously mentioned, the team at Capgemini are strongly committed to supporting the open source communities whose work we depend on, and we try to contribute back whenever we can, whether that’s patches to fix bugs and add new features, or creating new modules to fill gaps where nothing appropriate already exists. The client’s content team want to be able to control all of the text within the application (across multiple languages), and be able to preview changes before putting them live. Having made the decision to use this architecture, we wanted a consistent framework for managing application configuration, to make sure we wouldn’t need to keep reinventing the wheel for every application, and to keep things easy for the content team to manage. If at some later date, the client decides to move away from Drupal, or at the point where we upgrade to Drupal 9, the applications aren’t so tightly coupled, so the effort of moving them should be smaller. The application can be developed independently of the CMS, so specialist JavaScript developers can work without needing to worry about having a local Drupal build process. This brings a lot of value in terms of accessibility, search engine optimisation, and performance.Ī decoupled system is almost inevitably more complex, with more potential points of failure. There are several discrete interactive applications on the site, but the bulk of the site is static content, so it definitely makes sense for that content to be rendered by the server rather than constructed in the browser. There are a lot of advantages to this approach, in my view. In the past, we’d taken a similar approach, with AngularJS applications on top of Drupal 6 or 7, getting their configuration from ttings, and for this project we decided to use React on top of Drupal 8. Drupal handles routing, navigation, access control, and page rendering, while rich interactive functionality is provided by a JavaScript application sitting on top of the Drupal page. On our current project, we’ve continued to take an approach that Dries Buytaert has described as “progressively decoupled Drupal”. Maybe it’s partly because I don’t want to give up on the sunk costs of what I’ve learned about Drupal theming, and partly because I’m proud to be a boring developer, but I haven’t been fully sold on the benefits of decoupling. A lot of people have been jumping on the headless CMS bandwagon over the past few years, but I’ve never been entirely convinced.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |