The directory structure in Ember App Kit dictates that all controllers go in the '/app/controllers/' directory; handlebars templates go in the '/app/templates/' directory, and so on.
However, my team are currently developing an Ember application in which the number of functional areas (and therefore source files) is continually growing, so we want to create subdirectories under these directories for our controllers, templates, etc, rather than group everything in the same directory.
We have done this for one functional area by organising our controller and corresponding handlebars template in the following manner:
/app/controllers/availability/availability.js
/app/templates/availability/availability.hbs
So far, the only way we have been able to get this approach to work (i.e. to link our controller and template in this nested directory structure) is to create the following route:
this.route('availability.availabilty', {path: "/availability"});
This has the side-effect of Ember creating the following for us:
Route Name: availability.availability
Route: AvailabilityAvailability
Controller: AvailabilityAvailabilityController
Template: availability/availability
URL: #/availability
The word 'Availability' is duplicated in the resulting Ember controller to echo our nested availability/availability directory structure.
Does anyone know of a better way of organising an application in subdirectories within Ember App Kit? This surely must be a common requirement for applications with a large number of source files.
We would wish, for example, for Ember to create the following for us:
Route Name: availability.availability
Route: AvailabilityAvailability
Controller: AvailabilityAvailabilityController
Template: availability/availability
URL: #/availability
Many thanks
From the documentation on Nested directories http://iamstef.net/ember-app-kit/guides/naming-conventions.html it seems that you can do what you're looking to do with a single tweak. Instead of putting availability.js in the availability subfolder it should be one directory up, then all the sub availability controllers are placed in that subfolder.
+-- app
+-- controllers
| +-- availability
| | +-- edit.js
| +-- availability.js
+-- app
+-- templates
| +-- availability
| | +-- edit.hbs
| +-- availability.hbs
Please look into ember-pods.
http://cball.me/organize-your-ember-app-with-pods/
This is a way to structure your ember application in a way you were desiring.
Related
Is it possible to separate the templates .hbs from component class javascript .js in Ember 3.15 Octane.
A folder structure like:
app/
components/
js/
hbs/
The “classic” directory structure does separate component Javascript and template files, but not in the way you specified. Running ember generate component component-name --component-structure classic --gc would result in this structure (ignoring the tests directory):
app/
components/
component-name.js
templates/
component-name.hbs
If you really must have the directory structure you specified, you could accomplish it using a custom resolver. Here’s a blog post that gives a high-level overview of that. I’d caution against that kind of thing, though, as it’s usually beneficial to stick with what most of the community uses, and in 3.15 that’s the flat component structure. What’s your use case?
I just want to ask what is the best approach to integrate sass/scss on ember project?
Currently my project is in pod structure and I just import style.scss on main app.scss under styles folder.
Is it fine or there is a better approach?
--- app
---- pods
------- home
---------- template.hbs
---------- controller.js
---------- style.scss
---- styles
------- app.scss
Then in app.scss styles imported look like this
#import "./app/pods/home/style.scss";
I haven't used pods in years - because (like expecting controllers to be removed) - I was told that there was going to be a new file layout system. Since hearing that / I've heard bits and pieces of conversation that lead me to believe that pods aren't really a go-to for new projects.
That being said, I share your desire to have a nice file structure. I'd love to 'drag' a folder from one project to another / and just have all the parts of the component copy over.
Since we have the app.scss - (you said you're using sass) - / that kinda acts as the index.
I include resets and mixins and a bunch of stuff for setup. - so, that's not really podish... and maybe there are 'page' level kinda layout... which doesn't really fit either... - so, what it comes down to is really 'components', right?
ember-component-css is pretty cool - but it also has some opinions that could clash.
There's this - https://github.com/justtal/ember-cli-sass-pods - but it's 4 years old / (but so are pods) - so, it might still work great.
Because there isn't a really clear path here... I just create a component folder in styles/components/component-name.styl - and then in my styles/components.styl I #import 'component-name.styl - and then in my app.styl I import the components...
In my case / I actually like to use the cascade - and I need the files to all to be combined - in order. I can't have some of it in the vendor file.
It's not ideal (just because I have to create each file explicitly and register it) - but I can't afford to just keep wishing there was a better file layout.
Instead of fuzzy searching component-name > template
I just search template > component-name
¯\_(ツ)_/¯
I wonder which style will cause me less pain in future transitions. They'll offer codemods to help / but they can't account for unique configurations.
I'd suggest asking this in the official discuss forum. You'll get the real answers there. : )
https://discuss.emberjs.com/
app/styles directory, is the home for stylesheets like CSS, SASS, or LESS.
Folders like vendor and public that can also hold many other files of the developer's choice.
So in your case if you wish to have separate scss file for each pod,
you can put it in the place as you mentioned. (else)
have it under app/styles/pod1.scss and import it under .ember-cli-build.js -> app.import('app/styles/pod1.scss')
[References]
You can get the detailed view of Project layouts, Stylesheet compilation, Assets and dependencies below
Project layouts
Stylesheet compilation
Assets and dependencies
Besides ember-component-css there is ember-css-modules.
Both addons try to achieve about the same goal, however I really prefer ember-css-modules.
That addon has an addon called ember-css-modules-sass. Both together will easily allow you to write one sass file per component.
You just place a styles.scss file in your component pod (app/components/my-component/styles.scss and then use local-class="my-class" instead of class="my-class" in your template.
Your classes in your scss will be automatically namespaces.
I'm using jade with gulp to generate a static html prototype but having problems with relative links to assets like css files from jade templates located in subdirectories.
As this is a prototype and team members should be able to take a look at it quickly,
the files should be usable out of the box by using just a browser with no further configuration
no server is used
the files should be viewable on different machines
Project Structure
The source folder structure is like this:
src
|
|--first.jade
|
|--subdirectory
| `--second.jade
|
|--templates
| |--layout.jade
| `--head.jade
|
`--css
`--styles.css
first.jade and second.jade both extend layout.jade.
layout.jade includes the partial head.jade, which contains a relative link to styles.css:
head
link(rel='stylesheet', href='css/styles.css')
gulp generates this structure (which is how I want the project to be structured, so this shouldn't change):
build
|
|--first.html
|
|--subdirectory
| `--second.html
|
`--css
`--styles.css
Problems with this approach
The relative link to the css does not work for second.html as it is
in a subdirectory. The link in the rendered html is
<link rel="stylesheet" href="css/styles.css">
but it should be this in order to work:
<link rel="stylesheet" href="../css/styles.css">
I have to use different extend statements in first.jade and
second.jade, which is not a real problem but rather annoying.
first.jade:
extends templates/layout.jade
second.jade:
extends ../templates/layout.jade
Possible solution (which quite doesn't fit)
One solution to problem one could be to use a base tag in head.jade like this:
base(href='/Users/myusername/build/')
This works perfectly, but only on my machine, and only if I leave the project folder at the current location. This won't work for anyone else as the path used in the base tag will not be found on their machine.
Question
Is there some clever way to solve problem one with just using jade? Bonus for problem two...
It seems to me that the problem at hand should be a very common one, so I might have overlooked it in the docs or something.
This is what I came up with: Using the base tag in combination with jade variables.
head.jade now includes a block containing a variable to set the base path with a default value of '.':
block basetag
-var base = '.'
head
base(href='#{base}')
link(rel='stylesheet', href='css/styles.css')
This works for all templates in the root directory by default.
For all templates in a subdirectory, the base variable can be set to '../' like this:
extends ../templates/layout.jade
block basetag
-var base = '../'
I got function to make relative path from dividing slash with current path.
-
// Count depth directory hierarchy
var depth = (relativePath.match(/\//g) || []).length;
var relativeRoot = new Array(depth + 1).join( '../' );
visit my repo
I am not quite sure if my directory structure has the correct hierarchy and I decided to stop the development unless I will have it good.
I have order, customers, users .
So what I have is:
myproj
|-myproj
|-web_app
|---orders (with views.py, ajax.py)
|----templatetags
|---users
|---customers
|---search
|---static
|-----app
|-------_base
|---------css
|---------images
|---------js
|-------orders
|---------css
|---------images
|---------js
|-------customers
|---------css
|---------images
|---------js
|-------users
|---------css
|---------images
|---------js
|-----bootbox
|-----bootstrap
|-------css
|-------fonts
|-------js
|-----dajax
|---templates
models.py is in web_app directory, there are models common for all modules. My questions are:
1) What changes would you do in this structure? (static files for every module should be where?)
2) I have problem of inserting custom template tag defined in orders/templatetags/orders_extras.py from users template. How can I make some common templatetags for every "module" ?
Thank you.
This is explained in Django documentation very well. The good approach is:
Project
- App1
(Put app specfic templates to the app templates/App1/templates/App1/template files
- App2
- App3
- template for project (templates/ files)
Now, if you want template tags only for specific app create /templatetag directory under that app and do that.
For universal template tag do this:
Project
- templatetags
- __init__.py (Make sure it contains __init__.py)
- polltag.py
Explained here: https://docs.djangoproject.com/en/dev/howto/custom-template-tags/
How can I make some common templatetags for every "module" ?
You should place it near the templates directory
myproj
|-myproj
|-web_app
|---templates
|---templatetags
|---orders (with views.py, ajax.py)
|----static
|-----static_files_here
dajax
Is this about dajax? If you are new to django, I recommend to get away from this stuff. You can just watch the issues list of this project to decide whether you should use it or not. The problem not only about that dajax is bad or good, but that these issues are being made by newbies that don't understand how ajax works, what are csrf tokens and so on.
When I started to learn django, I tried dajax too, but finally I have realized that you should understand how ajax and django works by their own and then try to combine them.
So, my team and I are new to Django development. We've been trying to design our project structure over the last couple weeks, and we've done a lot of reading to try and get a grasp of the best practice of doing this.
However, we are still struggling to get our heads around the best way to store our templates/static files that are generic to all applications.
Let me detail our structure we've implemented so far:
root-folder/
app-1/
static/
app-1/
css/
js/
img/
templates/
base.html
base-app-1.html **extends base.html
app-2/
static/
app-2/
css
js
img
templates/
base.html **extends base.html at 'project-name' level
base-app-2.html **extends base.html
project-name/
collectstatic/
templates/
base.html
static/
base/
css
js
img
The one thing that bugs me with this structure is that our top level templates reside inside the 'project-name' level. I would like to see this folder at the same level as our root level static folder.
However, I don't want to move the root level static folder content into 'project-name/collectstatic' because I don't want to have files inside that folder being version controlled.
We realise that there is no definitive answer to this problem in the Django world. But, are we on the right lines? Have we misunderstood something?
A couple ideas we've got are:
To have an app dedicated to top level templates and htdocs called something along the lines of 'general' or 'generic'.
To move the 'project-name/templates' dir to the root level along side our 'static' folder there.
To stop talking about this problem and go with the structure drawn out above.
In Django it's preferable to rely on staticfiles' AppDirectoriesFinder finder and the template's 'app_directories.Loader` loader classes for managing your static files and templates.
That means that you'll have some sort of project.core, project.base or project.commons application that you'll populate with base templates and static resources that are reused throughout your project.
I'm assuming your problem with the project-name/collectstatic/ folder is that it's your defined STATIC_ROOT, on a path that's under version control. Ideally, you'll move your static and media root outside of your project's sources. The simplest solution is to move it next to your project's top-level package, in the standard project layout for distributing Python packages, or to your Web server's preconfigured document root.
In either way, this should move your locally generated static resources outside of your project's Python packages.