Im am currently trying out different node.js templating engines, including dust.js
Is it feasible to store all layout and view content in a database instead of the file system? Is there any templating engine which would be a better fit for this case?
Ideally i would create an administration screen where i could edit all master layouts and views, without requiring any file copying.
Definitely feasible, you'll just be responsible for your own template compilation / hydration. Assuming you're using Express, the built-in view engine expects templates to be on the file system, so if you're not going to have them there you have three choices:
1) fork express to remove that check
2) pre-cache all your views in the view cache when the app starts up (so that it pulls them from the cache rather than looking at the file system)
3) ignore the view rendering Express provides and just compile your templates yourself.
Doing 3 seems like the most natural choice, but realize there's a reason Express caches compiled templates, so you may consider building your own template cache (and dealing with cache invalidation when stuff gets updated).
Actually, a 4th method which may or may not work better (untested) would be to use Express's default views rendering, but on app startup write all your view files to a virtual drive using them temp module (here)
Related
This may come from a lack of experience on the various sections of the MEAN stack, but from the various boilerplates I've seen (mean.io, hackathon-starter, etc.) in the app.js code, there is always a call to using jade templating engine. I know that I can switch this to ejs and the like, but I was wondering if there's a means of doing it to where all of my pages are .html files using AngularJS? The components/templating features I'm interested appear to be in Angular already so I'm not sure what I'm losing if I were to attempt to server .html files instead?
If you have multiple html pages in your application, template engine can reduce code duplication between them.
Also, you usually need server-side template engine to provide some kind of a fallback to users who don't have javascript turned on (+ search engines).
I prefer jade over other template engines (and plain html), precisely because it's not html. So it doesn't have certain html issues like whitespace nodes, and always compiles into well-formed html file.
If you follow meanjs.org it uses swig, which parses as HTML. You may consider doing the same?
I am building a website using nodejs and express. How to make divisions in a page dynamic? Is Jade used for that? if not how to do it?what is angularjs used for? Please help i searched a lot on google and i couldn't get a clarity in the usage of them.
Jade creates the html used in the browser on the server-side. The browser executes a request to the web-server, the web-server executes Jade, which will generate the html that will be sent to the browser. This server-side content generation has been very common in the last ~20 years, but it has quite some cons when building rich internet application. Mostly this has to do with performance and client state tracking.
AngularJS is a client-side MVC/MVVM like framework to build so called Single Page Applications (SPA), which allows you to have the complete user interface flow, all content generation and state tracking to be done at the client side. It even allows you to build offline applications. From the developer point of view this feels much more like building a desktop application where the client knows the state of the user interface. From the user point of the view the website will respond much smoother and snappier because the UI is all generated locally.
Note: SPA does not mean that you can only have one page in your website.
It's a technical term where the browser downloads one page (~/index.html), which contains the complete or partial web application. The user technically never leaves this page, but the content (pages) is dynamically swapped in and out from this placeholder page.
To most common way to provide data to a SPA is via RESTful web services. AngularJS comes with builtin support for REST.
Some developers combine server-side content generation techniques with AngularJS, but there's actually no real need for this.
Jade is used as a template engine on both server-side and client-side. Yes, it can update a page dynamically, you just have to compile your jade templates to a javascript functions (using jade -c or something similar).
Yes, you can use angular.js with it, but I see no real need to use two template engines in your project. Suggesting to just stick with jade, unless you know what are you doing.
Express JS uses templates for generating HTML and then server sends them to client in response. There may be several other templates from which HTML can be generated. The ones I was able to discover are:
Jade (http://jade-lang.com/)
EJS (http://embeddedjs.com/)
In my app, I need to use both ExpressJS and AngularJs. I am new to both technologies. While learning angular, I had to use it in pure HTML. After learning ExpressJs, I realized, in order to use angularjs, I need to use them in any of the above templates which will be converted to HTML while sending to client.
Now, I want to use expressjs as my server and angularjs as my client side app. For this, I think I have two options.
Option 1
I can stop using templates altogether and use our NodeJS server to respond by sending simple HTML files. These HTML files will then contain AngularJS coding within them. AngularJS then, on client side, will act as our application. It will demand other HTML documents from the server. Or it can also be used like AJAX, where we can only request the piece of information to update just part of the page rather refreshing the whole page for a minor change.
Option 2
I can use angularjs inside expressjs templates (jade or ejs).
Kindly, help me in understanding the pros and cons of both options. Which one will be your choice in such case.
This is very much an opinion question and Stack Overflow admins hate anything that smacks of opinion, but here's my experience and opinion nevertheless.
I've done a couple of apps now using purely static files (HTML, CSS, and JavaScript) with those calling a service on the back-end to deliver the data. It reduces the back-end, whatever it is (I've used both Java and Node.js), to just being a set of service URLs but it works very very well.
You've got a fantastic hard line between the responsibilities of the
two systems
It's very easy to work on and test each one independently
Bugs are usually very clearly in the front-end or the back-end (all
you have to do is look at the data transferred to know)
The back-end services are ready to be reused to support alternative UIs from the
command line or something mobile specific if you want
You can use one technology for the back-end to start with (say Node.js or Ruby on Rails) and then switch to something else later if you need to. As long as the API stays the same the front-end never knows.
I personally use AngularJS with Express/Jade. The setup is actually pretty simple and I find writing Jade much more enjoyable than writing HTML. I've also adopted writing my Angular code in CoffeeScript as, again, it makes for quicker development. If you are looking to save keystrokes then Jade is a great solution and its integration with Express makes it a no brainer. If you aren't worried about producing code more quickly then there is absolutely no problem with using HTML.
I will point out that one of the greatest benefits I have found to using Jade over HTML is the ability to develop a single page in multiple files, then use include to have them concated before compiling into HTML. This allows you to take larger pages and break them into more manageable chunks. Together with Angular's templating, this can relieve much frustration.
Really it is all a matter of opinion, but since I decided to give Jade a shot, I have not regretted it and I have never ran into a situation where my HTML was rendered incorrectly when using Angular.
I went with option 1 because I didn't want to deal with any potential issues with jade or ejs converting the template incorrectly and interfering with Angular. My app essentially has the index page (which is really just the basic page template with my css and js includes) come out of Express as jade and then angular takes it come there and all my angular templates are in a separate location than my jade template.
Is it feasible to use Mustache templates (http://mustache.github.com) in a theme instead of the default Razor syntax?
As most frontend dev's we work with are on a Mac having to use Razor is creating a bottleneck in development, and I would prefer use a templating engine that can be rendered cross platform.
You can in principle use any view engine that is compatible with ASP.NET MVC, but you really shouldn't. You are going to fight with the system every step of the way. All of the themes and modules that you'll find (and you'll need them), as well as all the views in the core, are going to be using Razor. It's just a very, very bad idea.
You should try to find a CMS that uses Mustache natively as its default templating language, or learn Razor.
You can use it if you're willing to write some view engine services (what has some gotchas) and you can use multiple view engines side by side (i.e. you can keep the existing Razor templates and write your own templates in whatever you want).
The result won't necessarily be appealing but you can do it just as it was done for PHP.
I'm fairly new to Kohana but I like the framework. I've hit a bit of an issue where I need to build a theme system into my application. It is very much application specific and there really won't be any reason to share it down the track. Initially I built it into the modules system within Kohana but now need to expand it. I haven't seen much reference for it but is it best practice to build all support classes like this into the modules or is it best practice to keep application-specific classes etc housed within application/classes?
On a side note, are there any good theme-system examples for Kohana? I really like how Drupal manages its themes and sub-themes and was wanting to emulate a very basic version of this inside my application.
I'd agree with that, anything specific to the application and has no real reuse should be put into the application directory. I like to use modules for fairly generic modules. Examples would be:
contact - Many websites have contact forms.
email - Can be used in lots of places.
etc ...
For your case, you might consider building a templating engine and putting that into a module (it's generic), then simply housing the application specific theme into the application directory where your module can load and use it.