blog.boro2g.co.ukblog.boro2g .co.uk - Some ideas about coding, dev and all things

online. blog.boro2g .co.uk Some ideas about coding, dev and all things online. Menu About Why is choosing a CMS so damn hard? March 30, 2021 by boro Imagine the scenario – you start on a new feature or project and there is a need for dynamic content. Sounds simple right? Just pick a CMS platform, setup an account, update a bit of content, publish and you are done. Well, if only it was that simple! * *Note – this post assumes that a platform like WordPress isn’t sufficient for your requirements Where to start? If you look at https://en.wikipedia.org/wiki/List_of_content_management_systems , it certainly won’t clear things up. There are a LOT of options! So, what sort of information should you use to feed into your decision process? A few core CMS concepts Before we go further, let’s define a few key concepts: Headless Content Management System (CMS) – A headless CMS is a content management system that provides a way to author content, but instead of having your content coupled to a particular output (like web page rendering), it provides your content as data over an API.” https://www.sanity.io/blog/headless-cms-explained Digital Experience Platform (DXP) – Gartner defines a digital experience platform (DXP) as an integrated set of technologies, based on a common platform, that provides a broad range of audiences with consistent, secure and personalized access to information and applications across many digital touchpoints.” https://www.gartner.com/reviews/market/digital-experience-platforms It’s worth noting that certain vendors aim to fulfil both entries above, whereas others operate purely as headless, cloud native SAAS providers. How to help you make a decision? Ah, but what if the decision has already been made ? Within your team(s) or business(es), do you have an existing CMS? If so, can it be scaled or modified to serve your new needs. It’s worth considering that ‘scaled’ here covers many things – licensing, usability, modifiability, supportability, physical capacity and a raft more. This discussion often leads to some interesting outcomes and can easily expose issues, or the opposite, a positive view of existing tooling. Ok, so we already successfully use CMS X We’re getting warmer, but I’d suggest you still need to answer a few more questions: Is it fit for purpose? Do it’s content delivery approaches fit the needs of your new requirements? Will the team that use the system be the same as the existing editors? How to select a new CMS? I’d recommend you build up your own criteria for assessing different tools, here are a few thought starters: Cost What are the license fees, and how do they scale? Is it a consistent cost year by year? What if you need more editors? What if you need more content items, or media items? What if you need to serve more traffic? How much would a new environment cost? How much does it cost to run and maintain the system? What hosting costs will you incur? How much does a release cost? What cost lies with your different DR options? How will the infra receive security patches and softwareThe key thing for me is flexibility. If it’s done right you give yourself options – you want to deploy as a monolith, no problem. You want to deploy each bit in isolation, well that’s fine too. How does it look? Some key highlights of the image above: MonolithToMicroserviceApi.WebApi This is the shared singular WebApi project that brings everything together You can run this via IISExpress, or IIS etc and all the Api’s from the other projects will work within it MonolithToMicroserviceApi.Search.WebApi This is the search micro(macro) service You can run this in isolation, much like you can the common one MonolithToMicroserviceApi.Weather.WebApi The same concept as Search, but with other example controllers and code MonolithToMicroserviceApi.Shared.* These libraries contain common functionality that’s shared between each WebApi Adding a new WebApi The search project has a good example of this. If you look in MonolithToMicroserviceApi.Search.WebApi.Startup You need to add the ApiConfiguration class itself (see the project for examples), the ApiConfigurations code above and then register them all. Similarly in the common project startup ( MonolithToMicroserviceApi.WebApi.Startup ). Simply add each ApiConfiguration and register them. The Api glue So how does it all glue together? The key underlying code that allows you to pool controllers from one project into another is: What issues you might run into? Routing There is a commented out example of this – in the core project and weather project we have a ‘WeatherForecastController’ – if both of these have the same [Route] attribute you will get an exception. A simple fix is to ensure each controller has isolated routes. I’m sure a more clever approach could be used if you have LOTS of WebApi projects, but I’ll leave that for you to work out Dependency bleeding I don’t feel like this approach introduces any more risk of either cyclic dependencies or ‘ balls of mud ‘ – IMO that comes down the discipline of the team building your solutions. Summary What I like about this approach is flexibility. On day 1 you can deploy your common project to a single box and all your api’s are working in one place. Over time, as complexity grows, or your dev teams evolve, different parts can be cut apart but without any fundamental changes needed. You need to scale your search api, well no problem – deploy it as a single api and scale as you need. You need to push the weather api to multiple data centres for geo reasons, cut it out and deploy as you want. Another team needs to own search, again thats fine – you could even pull out to another solution, remove the ApiConfiguration and everyone is happy!? ? I hope it provides some good inspiration. It really doesn’t take much code, or configuration to build what I’d consider to be a very flexible approach to structuring your dotnetcore WebApi projects. Posted in Architecture , Webapi | Leave a comment Sitecore forms – custom form element save issue August 4, 2020 by boro In a recent project we needed to add some richer functionality to a form, so decided to wrap it up in a custom Vue.js component which we could then integrate into Sitecore forms. Sounds simple right? Building the component Sitecore provides some good documentation on how to build different flavours of form rows – have a look at the walkthrough’s in https://doc.sitecore.com/developers/93/sitecore-experience-manager/en/sitecore-forms.html if you are interested. Saving your data Assuming you want to build something a bit richer than the demo video component, chances are you want to actually store data that a user provides. In our use case, we used Vue.js to update a hidden input – under the hood we then save that data into the DB and also ping off to other save actions. Simples? Well, not quite – unless you know where to set things up. Configuring the form row In Sitecore forms, a custom form row needs a few things. A template in master to represent the configuration of the form row, and a set of items in core to represent the UI for configuring the form row. https://doc.sitecore.com/developers/93/sitecore-experience-manager/en/walkthrough–creating-a-custom-form-element.html The importance of AllowSave This is the key bit, and took a fair amount of digging to find. I could see my custom data was being posted back to Sitecore, with the right data. But, it was never getting saved in the database ? To fix I needed to make sure that both the configuration in core and my custom template had AllowSave available. In core, under ‘/sitecore/client/Applications/FormsBuilder/Components/Layouts/PropertyGridForm/PageSettings/Settings’ you create your custom configuration including sub-items based off the template ‘FormSection’ (see ‘/sitecore/client/Applications/FormsBuilder/Components/Layouts/PropertyGridForm/PageSettings/Settings/SingleLineText/Advanced’ for reference’ Here is where you need to ensure...