We are testing HAML and SASS on a recent project to speed up our development flow.
We built the static front-end, and from here, will be integrating the source into a Wordpress build. HAML isn't going to be used in the WP integration; we only used it to rapidly build the static front-end. However, not that it matters for this question, but we're using SASS throughout the entire build and into the WP integration. We're using Prepros as the preprocessor.
So, when building in PHP, it's pretty simple to use partials to make the front-end build more organized and efficient. No problem.
But we're using HAML on this project -- as an HTML generator -- and would love to integrate the language in all future builds if we can figure everything out. And we're trying everything possible to avoid having to expand into learning Ruby and/or configuring a complex development environment.
Anyways, using the overview above, is it possible to use partials to construct layouts in HAML without over-complexing the build? I've seen many answers relating to yes--and the answers are there--but the background information and semi-documentation just happens to never be there.
If anyone could point me in the right direction, that would be absolutely amazing. Please know that I appreciate any effort and advice from the community!
Thanks again,
B
Related
What is the most elegant way to get a riot based UI today?
i'd love the following points to be addressed:
A proper code-mapping for easy debugging
A good way to bundle the application (so far i used Webpack and JSPM)
It would be lovely if it would work elegantly with Typescript.
Is it best to use Tag files, or straight JS? If the later, would it be better to use a class that inherit from riot's tag class? If so, can i place the template code in a different file?
Future compatibility: i saw that there's going to be a change (that "export default" thing) - how would you recommend to write the code for the smoothest migration path?
If you have more items for consideration - please add them....
Thanks for asking these questions. I have tried to answer to all your questions hoping they could be useful also to other Riot.js users
A proper code-mapping for easy debugging
the riot compiler generates simply javascript code without modifying too much the structure of your original source code. Any modern browser should be able to provide with debugger breakpoints and console calls all the debugging tools you need. Check for example the stack trace of this error you don't need much more to figure out where it's coming from.
A good way to bundle the application (so far i used Webpack and JSPM)
In this repo we provide 3 different javascript bundle examples: rollup, webpack, riot-compiler. I personally prefer rollup but you can (and should) use whatever works best for you and your team.
It would be lovely if it would work elegantly with Typescript.
The riot public methods are already available as Typescript interfaces:
- https://www.npmjs.com/package/#types/riot
- https://www.npmjs.com/package/#types/riot-route
I am not a typescript user and that's why I will not invest time in making examples in a technology I don't use but PR are welcome
Is it best to use Tag files, or straight JS? If the later, would it be better to use a class that inherit from riot's tag class? If so, can i place the template code in a different file?
I recommend you to just use Tag files because riot was designed as component library and it embraces completely the philosophy of components composition vs class inheritance. If you have code you share across several components you can either use mixins or import it with your bundler directly in your tags see for example
Future compatibility: i saw that there's going to be a change (that "export default" thing) - how would you recommend to write the code for the smoothest migration path?
Riot 3 will be not compatible with Riot 4. (that will be a full rewrite) I can't recommend any best practice to make your code portable to Riot 4. Remember that Riot 3 will be still supported and your code will run even on IE9 for the next 10 years. Once riot 4 will be released and the API will be stable I can provide more hints about a migration path.
I just got access to the new Stencil beta and I have no idea what to do. I have reviewed all of the documentation on the BC developer website, but I don't know how to proceed. I am also not sure if I will even be able to create designs in Stencil since I don't know Handlbars or json - are those programming skills required or can we still rely on CSS and HTML for most design customization? BC told me there is no support for getting set up and to ask in this forum instead.
Normally I would look under the hood of an existing theme to see how it's built and try "learning on the job" but since I can't even get access to the files, I am at a loss. I created an account on GitHub but I have never used it so I don't know where to look for the files (I did a search but there are thousands of files there and I again couldn't figure out where to start). Can anyone point me in the right direction so I can determine if using Stencil is even feasible for my projects?
Handlebars compiles serverside as HTML. You do still have stylesheets, but we are using some SASS custom functions (documented in Stencil docs).
I'd recommend taking a look here: http://blog.teamtreehouse.com/getting-started-with-handlebars-js
I am converting a good old ASP.Net website to a single page application using Ember.js in a ASP.NET Web API project.
All the devs of my team and myself are pretty new to javascript. We spent the last 2 weeks learning the basis and comparing SPA frameworks. I apologize in advance if my question sounds stupid :)
All the Ember tutorials I have found so far included all Handlebars templates into one single file. I assumed it would be pretty obvious to split them into separates files (*.hbs) when the time would come, but it's not. I might be totally missing something here, but I found about 4 ways to get my templates back when I need them. I'd like to know which method you would recommend:
Concatenate and then inject all the template files when the app loads. I could write some C# code on the server-side that concatenates all the templates files into a single one when the app loads (i.e. each time a visitor enter the app). It seems odd to me, in terms of processing, but also because the generated HTML file will be pretty heavy.
Load each template dynamically via Ajax when I need it. Pretty much what is done here. I kinda like this solution even though I haven't tried it yet. It makes sense to me to get asynchronously a template when I need it instead of loading the entire app on the first load.
Use the Bundling mechanism of Asp.Net MVC. I found stuff like csharp-ember-handlebars to precompile the templates on the server-side and return them as a single javascript file. It works-ish but I feel like the precompiled file will become pretty heavy as I add new templates.
Use Grunt with the plugin grunt-ember-handlebars to precompile the templates. I'm not familiar with Grunt but if I understand well all the devs working on the project will have to install Node.js + Grunt + learn how to use a command prompt + remember to run the command before each commit (if they modified a template). This is not obvious for the web designers. And adding grunt to the build actions will require the entire dev team (working on other projects) to have grunt on their machine (not acceptable).
I need to find a simple and elegant solution to address this issue. My project is in a solution with 35 other projects and I cannot add too much complexity to the build, neither depend on unstable libraries. Maybe I have been too optimistic when I thought I could use Ember for my project. Any suggestion would be welcome!
Your #3 is the most ideal (and common) way that I've seen applications handle templates. With a compiled and minified template file you really don't have to worry to much about performance problems in regards to adding new templates, especially if you take advantage of caching.
One benefit to having the templates compiled and available off-the-bat is that users only need to Download Your Resources Once™, as apposed to downloading resources for each subsequent page load. This leads to a fantastic user experience.
With the tools we have today for assets optimization (for example YUI compressor), how do you automatize it?
For example, I have designed a new website using LESS, so every time I have to edit CSS I have to manually convert them to LESS. The same for Javascript.
So I have to make my PHP project to point to my uncompressed CSS/JS, and when I'm finished, I compress/optimize them, and point my project to the optimized ones again.
I know that there are tools that helps with this (like less.app, which I've used), and that even there are PHP libs that manage all this problem (like Assetic), but I don't like them much. I'm searching for a "programmed" way to deal with optimized assets. Maybe some script that "watches" the uncompressed files or something...
I wish I could have too many alternatives as the Django framework has.
Please, if the question is not well redacted, tell me and we can improve it, so we can establish a good practice for assets :)
I think one efficient solution would be to do this task on the development side, when writting code, and point the code to the optimized files.
One tool that seems to work well is Live Reload (only for OS X, although there is a Windows version on the way).
I like this option as there is no overload on the code to maintain assets.
I am rather new to Sitecore and would like to know a bit more about the regular approach to a new project. I'm therefore willing to listen and try out some of the experienced Sitecore developers solutions. I have alot of questions, i won't ask them all. I am just very curious to the approach other people have.
What would be the best approach to start a Sitecore project?
How would you set your project up?
What will be your approach looking at the recycling of code in future projects?
In short: What experiences do YOU have (if you have worked with or are working on Sitecore projects) and how would you recommend other people to work with Sitecore.
Right now we are busy on building Sitecore blocks that we can just recycle in other projects but i know for sure there are 1001 handy tips and tricks out there. I hope we have some Sitecore pro's # stackoverflow that could help a bit.
Here is some general setup info, based on how we do things.
Subversion
This is not Sitecore specific but we set up our repository like this
branches - This is used for working on big updates to the site that may take a while. Say for example I wanted to update how all of the sidebars on the site worked, and this was going to take a few weeks to complete. What we do is create a new branch, and set up another sitecore instance for this dev branch and do what we need to do. When it is complete we merge it back into the trunk for testing and deployment.
tags - This is used for keeping a copy of code that will never be merged back into the trunk (that is the difference between this and branches), so for example when we deploy an update to a site we can create a tag of said code so we can go back to it if necessary.
trunk - The active code, anything checked in here should always be deployable.
The Trunk
This is where we are actively developing/fixing bugs, depending on which part of the project that we are on. We set it up something like this (as an example the project is called TheProject)
We keep our solution file at the root of this folder, this will reference the various libraries in the src folder as well as the web project in the website folder.
docs - A place to put documentation about the site. I strongly suggest that as you complete features/sections you write up a little guide about any special knowledge needed for it to work. So say I am working on a featured content box on a landing page. This box will automatically pull some content unless it is explicitly overridden. What I do when I complete something like this is I write a guide for the customer, using a lot of screenshots. I send the guide to the customer as well as put it in the docs folder. This both helps the customer train their staff, as well as helps new developers come up to speed with how things are done.
lib - This is where we keep any DLLs we are going to need to reference in our projects.
test - A place to put unit tests.
src - This is where we keep our project specific library code. So in here we would have a folder called TheProject.Library, and in there would be the visual studio project for said
web/Website - This is where we have Sitecore installed and is the root of the site. In here we have a project called something along the lines of TheProject.Web. In the project we add all of the general stuff like the web.config/layouts folder and so on.
General Sitecore Code Library
One the best things you can do is from the start setup a general Sitecore library that can be added onto over time. Then when you write any code for a project that is not only applicable to the project, you can add it there. It may seem obvious, but this will really help in the long term. You will end up with much more solid code, see link text .
So when we are done with all this we have something like this as a solution/project structure
TheProject (The solution)
TheProject.Library
TheProject.Web
MyCompany.SitecoreLibrary (our general sitecore library)
Tools
This is another general thing, but I find it can really help speed up Sitecore development. If you find yourself doing something over and over in Sitecore, using API write a tool to do it for you. This not only helps with solving whatever problem you are tackling, but also helps to get you more familiar with the API.
Resharper
This is more of a general .NET development suggestion, use Resharper(http://www.jetbrains.com/resharper/index.html). I am sort of a a Resharper fan boy, it makes so many things with development easier and quicker. In my mind the biggest advantage though is how easy it makes refactoring code, which is really important to do over time to keep things clean and understandable.
I hope some of this helps.
Gabe
This is, as you said, quite a big question. Here are some of my thoughts:
Developing Environment
First of all when I start a new project I install Sitecore on my developing environment and I make sure everything works. Either during installation or after I place the databases on a separate SQL-server and change the connectionstring accordingly.
I open up Visual Studio and create a solution and include the files needed. I create some kind of HelloWorld rendering and try building the solution so that I can verify that everything is working as it should.
When everything is up and running I create a zip-file of the whole solution, including the data-folder. Now it is time to add this to some kind of version control system, in my case Subversion.
I add the zip-file to subversion and also add all files that I think will be changed during the project, usually I tell subversion to ignore the sitecore folder, this speeds up performance drastically when checking in files.
After I perform a commit-action the other team members of my project can check out the code and start developing (after unzipping the zip-file, off-course)
We all work towards the same database although this goes against Sitecore recommendations, we havent had any problems with this approach however items in GUI created/changed by one developer take some time before it is created/changed for all the others.
We could off-course develop several different projects using the same Sitecore installation but since almost all customers use different versions of Sitecore we have found this approach a bit cumbersome.
Often we set up an automated build-server but this is a whole other issue.
Reusable code and renderings
I would like to say that we create neat packages based on the same codebase that gets reused between projects but unfortunately we are not there yet. Today it is a lot of cut and pasting between solutions.
Uploading code to customer
This is done via sitecore packages, normally with some kind of dynamic selection for what files to include, say all ascx-files in a specific folder changed the last 5 days.
There you have it.
Take a look at this series.
Especially the component architecture part have increased our level of reusability.
When you create your Visual Studio's project in Sitecore's web root folder and you will keep all Sitecore's dlls files inside bin directory, don't forget to add to project's references all these files:
bin\ComponentArt.Web.UI.dll
bin\HtmlAgilityPack.dll
bin\ITHit.WebDAV.Server.dll
bin\Lucene.Net.dll
bin\Mvp.Xml.dll
bin\Newtonsoft.Json.dll
bin\RadEditor.Net2.dll
bin\Sitecore.Kernel.dll
bin\Sitecore.Logging.dll
bin\Sitecore.NVelocity.dll
bin\Sitecore.Zip.dll
Because when you CLEAN your project and you will have reference only Sitecore.Kernel.dll (in most of cases), you will lost most of dlls from bin directory!!