Case study: Highly modular site structure with Magnolia
•Transferir como PPTX, PDF•
1 gostou•627 visualizações
This presentation was given at Magnolia Conference Basel, June 7-9 2016. It demonstrates how we leveraged Magnolia CMS's light modules to aid our Frontend development while migrating a large telecom operator's site to Magnolia 5.4 from legacy systems. Video of the presentation: https://www.youtube.com/watch?v=ZW23nHVGAdQ&index=6&list=PLxHBbwVVoCoaJ49u_q7IUTvzlTdQ1Uzpt
Recomendados
Mais conteúdo relacionado
Semelhante a Case study: Highly modular site structure with Magnolia
Semelhante a Case study: Highly modular site structure with Magnolia (20)
Último
Último (20)
Case study: Highly modular site structure with Magnolia
- 1. H I G H L Y M O D U L A R S I T E S T R U C T U R E W I T H M A G N O L I A CASE STUDY
- 2. @KAIVOSUKELTAJA N I K O S A L M I N E N Web Developer since 1999 JavaScript / Java / PHP / C++ Lead Front-end developer on the project
- 3. WHEN YOU WANT TO CREATE WORLD CLASS DIGITAL SERVICES FOR YOUR CLIENTS. C O N T A C T tel. +358 40 544 0497 tommi.sipila@houston-inc.com Tommi Sipilä Account manager tel. +358 40 544 3972 tomi.ruotimo@houston-inc.com Tomi Ruotimo CEO
- 4. LARGE INTERNATIONAL TELECOM COMPANY T H E C L I E N T Active in 10+ countries B2B and B2C Mobile and Fixed Broadband Services 20M+ customers 10B+ EUR revenue
- 5. PORTAL PLATFORM RENEWAL T H E P R O J E C T Gradual migration to Magnolia 5.4 From custom legacy CMS and Magnolia 4.5 Learning project for both customer and vendors
- 6. P R O J E C T S C A L E Multiple teams in three countries Hundreds of pages 11 integrations to external systems 1 Dev, 1 Preprod, 4 Prod servers for main site 8 additional servers for other sites 3M+ monthly visitors across sites
- 7. CONCURRENCY C H A L L E N G E S How can we work together with several teams in multiple countries? VARIETY How can we support a different visual layout for nearly every page? How can we move fast without breaking too many things? ROBUSTNESS
- 10. CONCURRENCY DEV TEAM PERSONAL CODE REPOS GITHUB JENKINS LIGHT MODULE PERSONAL CODE REPOS PERSONAL CODE REPOS … …
- 12. FANTASIA 1. Fantasia / Oma valinta 4:llä täytteellä / 58,36 % 2. Americano (ananas, aurajuusto, kinkku) / 3,30 % 3. Julia (ananas, aurajuusto, katkarapu, kinkku) / 2,90 % 4. Dillinger (jauheliha, kinkku, salami, sipuli) / 2,40 % 5. Bolognese (jauheliha) / 2,00 % 6. Opera special (kinkku, salami, tonnikala) / 2,00 % 7. Romeo (ananas, aurajuusto, katkarapu, salami) / 1,80 % 8. Barbeque (ananas, kana, pekoni, sipuli, barbequekastike) / 1,90 % 9. Empire Special (katkarapu, kinkku, salami, tuplajuusto, valkosipuli) / 1,90 % 10.Smetana Pizza (fetajuusto, jalapeno, kebabliha, valkosipuli, smetana) /1,50 %
- 13. HOW MANY DIFFERENT PAGE TEMPLATES DO WE WANT? V A R I E T Y Nearly every page looks completely different We currently have 65 components (and counting) We currently have 9 page templates …of which 2 are in active use …of which one is the front page
- 15. HOW TO DEAL WITH THE HIGH AMOUNT OF MOVING PARTS? R O B U S T N E S S 65 components Most of them have JavaScript functionality Around 5 components used per page Tens of JavaScript components unnecessarily initialized JavaScript components need data from JCR JavaScript components need to communicate with each other
- 16. LIGHTWEIGHT JAVASCRIPT LIBRARY FOR COMPONENT JS FUNCTIONALITY P P R L I B R A R Y Loads and runs component JS only when needed using RequireJS Allows pub/sub communication between components Simplifies passing data from .ftl to JavaScript Allows reloading components on state changes
- 17. W H A T D O E S I T D O ? INITIALIZE DETECT COMPONENTS LOAD DEPENDENCIES BUILD COMPONENTS
- 18. FTL
- 19. JAVASCRIPT
- 20. FTL USING JSON
- 21. JSON MACRO
- 22. SET UP HANDLER CALL HANDLER GLOBAL HANDLER
- 24. SOURCE CONTROL B E N E F I T S F R O M U S I N G L I G H T M O D U L E S Easier merging Code reviews Branches Blame & Bisect TESTING Karma and Mocha Granularity helps unit testing Run tests and enforce coding style standards on every save Isolated logic in components Load and run only what’s needed High modularity DECOUPLING
- 25. Q&A
- 26. KIITOS! Niko Salminen @kaivosukeltaja tel. +358 40 831 1293 niko.salminen@houston-inc.com
Notas do Editor
- Reader’s notes go here.
- I work for a company called Houston. We do all kinds of software development but this was our first Magnolia project. We work mainly for Finnish customers but if you need to contract a few good developers I’m sure Tomi and Tommi would love to hear from you.
- Our client gives our reference permissions only rarely, and unfortunately we didn’t get one so I’ll just call them “The Client” in this presentation. They are a big telecom company with over 20 million customers and a revenue bit north of 10 billion euros.
- The project was basically a migration project, but also a complete redesign. We took pages from the old custom CMS and a support section running on Magnolia 4.5. We redesigned them completely and built them on the bleeding edge 5.4 Magnolia. We had no prior experience on Magnolia but were really lucky to have a most understanding customer. “Let’s learn this together.”
- Here’s a rough outline of our frontend project’s folder structure.
- So, does this setup help with our first problem, concurrency? Here’s how our front end infrastructure is set up. Blah, blah, blah. Note the external teams in swimlanes. Set up for the pizza slide before change: “Let’s change the subject for a bit.”
- Who likes pizza? What is the best pizza?
- The best pizza is the one where you get to choose the toppings. We in Finland call that kind of pizza “Fantasy”. Americano (pineapple, blue cheese, ham) is way behind. There are over 20 pizzas in any restaurant but everybody orders Fantasia. Cause people love variety. *change*
- Same goes with designers. They don’t like templates. Ironically, that means we need tons of templates. …or do we? After building a few page templates and
- We basically have a header, footer and all Fantasia in between.
- The library is initialized on page load. It then detects all JavaScript enabled components on the page. It loads the JavaScript for those components and any dependencies they may have. Finally, it calls the build() -function on them.
- Let’s look at the code real quick. Here’s the FTL of a very simple component called “Big five”. Note the data-component attribute. That’s what the library will look for.
- Lines 1 - 4: RequireJS boilerplate - module name and dependencies. Note we have the module name in snake case here, that’s handled by the library. Lines 10-11: PPR boilerplate for extending the base component Line 16: Override the build function Lines 17 - 20: Delegate all clicks to the first link within the component (hack) Line 22: Return true if initialization was successful and we want to keep the component running
- This is the .ftl of a custom area We have a macro that passes all the component’s properties to its JavaScript through a data attribute
- If you’re curious, here’s the code for the component to JSON converter. I’ll pause for a second to let you take notes. It’s all on one line because line breaks will break data attributes.
- Each component has their own event queue, and there’s also a global queue that all components can post and listen to.
- E2E tests use selenium - that’s not light module specific