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?
Related
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 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.
where to place the js_plugins and css_plugins?
I want to create a html/css template.some css files and are coded myself,such as
css/my.css
js/site.js
but sometimes I want to use some existed css or js plugins from other people who had shared on web,such as
1.some plugins only have css,no js needed. (ex:css3_button.css)
2.some plugins have both css and js. (ex:jquery.prettyphoto.js && jquery.prettyphoto.css)
for these plugins ,where should i put them in my template folder?
i do it like this bellow, but i don't think my structure is good enough.
index.html
css
....my.css
js
....my.js
css_plugin
....css3_button
........css3_button.css
js_plugin
....jquery_prettyphoto
........jquery.prettyphoto.css
........jquery.prettyphoto.js
how to place these files, to ensure the easy managing in the feature?
I use static folder, which includes folders for CSS, images and JavaScript. You can also add a folder for your plugins, where each plugin will be in its own folder.
You can replicate your general structure inside each plugin folder, but most plugins come pre-organized, and changing their structure is not always easy.
example
index.html
static
...js
...css
...img
...plugins
......myFavoritePlugin
.........css
.........js
.........img
......myFavoritePlugin2
.........css
.........js
.........img
Keeping the plugin files together makes their maintenance easier, but it affects performance. It is best practice to combine CSS and JavaScript files when deploying on production machines. You can have best of both worlds if you use build scripts, such as ant
I'm working with a Satchmo installation that resides within an existing project. This project has its own templates as well as templates for some of the various apps that are installed. Some of these app-specific templates have their own app_base.html variations that expect to derive form base.html. I'd like to be able to do the same thing with my Satchmo templates and have them reside within my project's base, but also have some additional html added around all of them.
/templates
base.html
index.html
/news
news_base.html (extends base.html and adds news-specific template features)
index.html
detail.html
/store
base.html (overriding Satchmo's base)
This structure works somewhat, but not how I expected. in /store/base.html (Satchmo's base) I've simply replaced everything with a test message. I can see the message, so I know satchmo is loading its base and not the site's base. However, I can't extend my project's base anymore since using:
{% extends "base.html %}
Yields a recursion error since its calling itself and the following simply won't work.
{% extends "../base.html" %}
I realize that I can change my project's base.html to a slightly different name and point all app-specific templates at them, but it seems like a pretty major hack on such a fundamental aspect of the template structure.
Hmm, I didn't think django looked up templates relatively like that.
Kinda crazy hack, but this should work:
/templates/store/base.html extends "global_base.html"
/templates/global_base.html extends "base.html"
Depending on how you have your template structure set up, it might also be a good idea to play with the settings.TEMPLATE_LOADERS variable.
TEMPLATE_LOADERS Default:
('django.template.loaders.filesystem.load_template_source',
'django.template.loaders.app_directories.load_template_source')
A tuple of callables (as strings) that
know how to import templates from
various sources. See The Django
template language: For Python
programmers.
For more information on how this affects the template loading process:
http://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types
From the way you describe your problem, it seems like by commenting out the "app_directories.load_template_source" file line, you might be able to better find a way to accomplish what you're doing.
django.template.loaders.app_directories.load_template_source
Loads templates from Django apps on
the filesystem. For each app in
INSTALLED_APPS, the loader looks for a
templates subdirectory. If the
directory exists, Django looks for
templates in there.
This means you can store templates
with your individual apps. This also
makes it easy to distribute Django
apps with default templates.
For example, for this setting:
INSTALLED_APPS = ('myproject.polls',
'myproject.music') ...then
get_template('foo.html') will look for
templates in these directories, in
this order:
/path/to/myproject/polls/templates/foo.html
/path/to/myproject/music/templates/foo.html
Note that the loader performs an
optimization when it is first
imported: It caches a list of which
INSTALLED_APPS packages have a
templates subdirectory.
This loader is enabled by default.
I just had this same problem. It looks like the satchmo developers planned for this by putting an "empty" base in the shop template directory. While this may not be relevant to you anymore, I would have like to have seen this here.
You can make a "shop" directory in your template directory and copy the main satchmo base.html to that directory.
This worked for me.