What is the idiomatic way of structuring a flatiron HTTP application?
I'm playing around with node.js and flatiron and I want to create a semi-trivial HTTP application. The documentation from the flatiron website does a pretty good job of describing each of the components but not necessarily how to structure your spangly new application.
Questions that I have range from: Is it good practice to split templates into different files or is that just a legacy of having to work with C# during the day? to how to approach testing.
Examples or recommendations from other flatiron apps will be helpful; folder structure, testing conventions and common practices will all be happily borrowed.
I would at least like to know the rules before I start breaking them!
A bit late, but this question is unanswered.
flatiron is not a full stack web framework. As I understand and feel it's a framework for webapps in opposition to express / geddy, which are for dynamic websites. For static websites there are blacksmith or windersmith and such.
flatiron is a bundle of modules you can put together as you wish. The question for best practices is more about if you work alone, together and if you will release your code publicly. If you work alone and private you can organise your code as you see fit. My organisation for a small webapp looks like this:
- app // css, js, images, templates - assets // css, js, images - templates // html - partials // html partials since i work with plates - config // config.json - lib // modules i would use in other projects as well - node_modules // … - app.js - package.json
How you do with your templates depends major on your template engine. I find most engines overkill for a small webapp. I prefabric the templates with wintersmith or blacksmith and then use plates to bring some dynamics in it.