How to setup your project for front-end developers.
In my last post, I have mentioned some thoughts on how to create a simple solution structure using Helix Principles. In this post, I would like to drill down a bit further. We will talk about where to store your CSS/JS for every feature and how to store them in your solution.
We are living in a totally different space where you have all the dedicated team around yourself to provide you the HTML/CSS/JS files. If you look at the Habitat site and solution structure, you will see that all of the assets are stored under Theming. Basically, Habitat provides us a single instance of the project to store all the required CSS/JS.
However, if you are working with a team of frontend developers, they will be checking out the whole solution along with Habitat.Theming project. They will be working daily on that project or at least setting up a gulp builds to create a main.css or any .css files.
HOW WE CAN BETTER DESIGN A SOLUTION FOR OUR FRONTDEVS?
There has to be a better way, right? After all, we are geeks. Our job is to make it better.
In my experience, I have created all the features under the website project under project folder. Something like this:
As you can see that for the frontend developers, all they have to check-in the files in this project itself. They can focus on the features listed here and push all the HTML/CSS/JS in. In this way, they are focused on one project only. So, does for the fonts for common and for each website:
Some of you might argue that why don’t we create a separate project for it? You can do it, but it will create another dependency on the project itself. For the website project, all the assets live at one place (even the default HTML file).
Let me know what will you change and how I make it better?
Setting up your solution structure.
Nowadays there is a new facade of Helix principles and how to implement a solution based on it. Just to give you a brief, this is up and coming in Sitecore solution structure. The basics are these:
- Look at your website and broke it down to components (I am sure by now what I mean by components).
- These are going to be your features in the Helix solution architecture. However, there will be different views for this feature. So for example, if you have a Navigation, then this navigation can have:
- You get the gist! Right? Good! Moving on…
- Now you have to look at the solution and decide what will go in Foundation Folder. Like this:
- As you can see there is a LocalDataSource project in which all the dependencies are listed which pertains to access the DB: Pipelines, Getting Item, ItemExtensions, you get it.
- Basically, you need to figure out what are the different way you can conglomerate various data points into one.
- Foundation layer does not suppose to change frequently. Heck! Why would you change the logical structure of getting the item from Sitecore DB?
- Lastly, there is a project folder which consists of all your sites. Even if you are creating one Sitecore site, it is a good practice to have a common site as your base site and a separate site. In this image, you will see the Common &Habitat project layout structure:
To wrap is up (been a long day), Helix setup might take some thinking to do and what really you want to achieve. But at the end of the day, it is a modular & clean architecture.
Some simple adjustments to the configuration of SQL Server can greatly improve the performance of the database environment. Keep in mind that some of these settings may impact the backup approach you employ for MS SQL.
- Set the compatibility level to SQL Server 2008 (100) to take advantage of the latest optimizations.
- Ensure the auto-close property is set to false. This ensures that a page will only make one connection.
- Ensure the auto shrink property is set to false to avoid costly dynamic resizing.
- Ensure the recovery model is set to simple to avoid the high overhead of transaction logs.
There are some posts out there which tell you about useful links in Sitecore. Such as here:
But, did you know Sitecore added few more tools in 8.2?
Support Package Generator
Dependency Injection Configuration
Hope you bookmark these (:
Part of the indexing configuration in Sitecore includes indexing strategies that you select from. These are C# classes that run at indexing time based on how you want the system to behave. The default strategy in a stock instance for the “web” database is
onPublishEndAsync. This strategy uses the event queue to subscribe to the
publish:end event. When raised, it triggers an incremental index update (i.e. not a full index rebuild but small deltas directly on the index).
*/My First Comment on my own blog */