The customer, realizing the many benefits, embraces the idea. Excitement is felt by all, as we embark on this new project with Adobe’s AEM 6 platform at our side.
The project architecture is laid out by carefully structuring the business data types/models, and meticulously designing the user interface and experience. However, only about half of our team is experienced in AEM 6. The other half of the team consists of web developers experienced in front-end client side technologies. The journey begins peacefully, AEM 6 developers working on the back-end business logic and the front end web developers working on the user experience.
We have agreed on a tight deadline, and the customer wants to start seeing the server side data and user experience come together. As we begin to tie our backend data and server-side logic to our components, we are met with the inevitable. Those experienced in AEM 6 will now have to decide what logic and control must be moved, implemented, or added to the component JSPs to bind the back-end business models/data to our user experience. With every step, our JSPs become more unreadable, our components less modular, security less maintainable, and testing more unbearable. What started out as beautiful markup, backed by incredibly efficient data objects and server-side logic, is now a confusing web of embedded scriptlets, anchored to the now splintered business logic. There must be a better solution.
Most experienced developers have encountered a project as disorganized as the one we just described. However, it brings up some notable points. We have all seen that terrifying JSP file that warrants a long sigh and a fresh cup of coffee before it can be tackled. Don’t forget all that HTML and CSS you got from the designer that had to be changed and tweaked to get your component to even render in AEM. Granted, some of these issues can be solved for using JSTL taglibs, various JEE technologies, and Javascript templating engines. It turns out, this is just not what many AEM developers want. We enjoy the power and comfort the JCR provides, and the ease of functionality and extensibility that Sling gives us. With other templating frameworks we lose this.
Welcome Adobe’s new AEM 6 Sightly framework! Sightly is Adobe’s new HTML templating engine, meant to replace JSP and ESP, as the predominate templating engine for AEM 6. Adobe’s goal with Sightly was to produce more readable, maintainable, and secure code while distinctly separating the logic and markup. In this post, we will be covering Sightly and some of the key reason why you might want to consider Sightly for your next AEM project.
Why Sightly
If the above scenario or your own experience is not reason enough, why would you choose to start using Sightly? In a presentation from Gabriel Walt, Adobe AEM Product Manager, Adobe is approximating a 25% reduction of cost to production. The main focus is aimed at improving efficiency with component development time to production and costs. The diagram below shows where Adobe finds AEM development suffers the most. Here we see after the design of HTML/CSS/JS we have to convert it to a JSP, edit and hack it together to fit the JS and CSS, and then implementing the server side calls and logic in the JSP. Though not every AEM component development process follow this paradigm, for most it can increase component design time and cost significantly. Given this paradigm, the workflow is a three step process.
What if there were only two design processes? That would certainly cut down on development time and cost. With Sightly, that is now possible. Sightly is valid HTML5 markup. It is implemented through data attributes and parsed HTML text. This allows the business logic and simple UI logic or control to be elegantly separated. Shown below is a simple code snippet comparing JSP and Sightly with the same functionality.
Sightly consists of very simple presentation logic and anything beyond that will have to reside as a separate helper class. The Sightly ‘Use API’ defines the structure for external helper classes. These can be Java, other supported JVM languages, and now Javascript!! That’s right, similar to what Node.js provides, you can now develop your entire application in Javascript! This means the server-side code can easily be edited by front end developers. The only current downside to using Javascript with Sightly for the server-side logic is that it is going to be a little slower. Adobe states they are currently working to improve the performance to more closely match the specs of traditional JVM languages. Sightly APIs tie directly into Sling and provide access to page properties, node properties, request objects and most everything you are used to in AEM JSPs. Now our development process can look more like the image below.
Now, with the development split clearly into the Component front-end design and the Business server-side logic, development time and costs can be reduced. This allows your developers to focus on what they’re good at and become more efficient in their day-to-day work. When you allow the developers to focus on what they’re good at and what they enjoy, it carries across the organization and the project is completed quickly and efficiently. This allows the team to complete the tight deadline they originally agreed to at the start of the project.
If the above scenario or your own experience is not reason enough, why would you choose to start using Sightly? In a presentation from Gabriel Walt, Adobe AEM Product Manager, Adobe is approximating a 25% reduction of cost to production. The main focus is aimed at improving efficiency with component development time to production and costs. The diagram below shows where Adobe finds AEM development suffers the most. Here we see after the design of HTML/CSS/JS we have to convert it to a JSP, edit and hack it together to fit the JS and CSS, and then implementing the server side calls and logic in the JSP. Though not every AEM component development process follow this paradigm, for most it can increase component design time and cost significantly. Given this paradigm, the workflow is a three step process.
What if there were only two design processes? That would certainly cut down on development time and cost. With Sightly, that is now possible. Sightly is valid HTML5 markup. It is implemented through data attributes and parsed HTML text. This allows the business logic and simple UI logic or control to be elegantly separated. Shown below is a simple code snippet comparing JSP and Sightly with the same functionality.
Sightly consists of very simple presentation logic and anything beyond that will have to reside as a separate helper class. The Sightly ‘Use API’ defines the structure for external helper classes. These can be Java, other supported JVM languages, and now Javascript!! That’s right, similar to what Node.js provides, you can now develop your entire application in Javascript! This means the server-side code can easily be edited by front end developers. The only current downside to using Javascript with Sightly for the server-side logic is that it is going to be a little slower. Adobe states they are currently working to improve the performance to more closely match the specs of traditional JVM languages. Sightly APIs tie directly into Sling and provide access to page properties, node properties, request objects and most everything you are used to in AEM JSPs. Now our development process can look more like the image below.
Now, with the development split clearly into the Component front-end design and the Business server-side logic, development time and costs can be reduced. This allows your developers to focus on what they’re good at and become more efficient in their day-to-day work. When you allow the developers to focus on what they’re good at and what they enjoy, it carries across the organization and the project is completed quickly and efficiently. This allows the team to complete the tight deadline they originally agreed to at the start of the project.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.