Ember.js project directory structure [closed] - ember.js

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
Is there any good tutorial or Ember.js document describing directory structure for models / views / controllers, app.js and the way to reference those files in the index.html root file.
File to create the "Ember.Application.create" ?
order of inclusion (models.js, apps.js, controllers.js) ?

This tutorial by Dan Gebhardt was very helpful to me in setting up my project structure and figuring out how to include files.

The ember-skeleton project has a reasonable example of project layout for rake pipeline. They do it something like this (from the README):
ember-skeleton
├── Assetfile - App build file
├── Gemfile - Package dependencies for rakep/rack
├── Gemfile.lock - Here be dragons: don't touch, always include
├── app - App specific code
│ ├── css - App CSS or SCSS (.scss)
│ ├── lib - App code, *modularized during build*
│ ├── modules - Module code, *already modularized*
│ ├── plugins - Plugins (e.g. jquery.jsonrpc.js)
│ │ └── loader.js - JS module loader
│ ├── static - Static files, never touched, copied over during build
│ ├── templates - Handlebars templates, *modularized during build*
│ ├── tests - QUnit application tests
│ └── vendor - Vendor code, *modularized during build*
├── assets - Built out asset files, minified in production
│ ├── app.css - Built out app CSS/SCSS
│ ├── app.js - Built out app JS
│ └── loader.js - Built out JS module loader
├── config.ru - Rack development web server configuration
├── index.html - The app entry point
├── tests - QUnit testing files
│ ├── index.html - The testing entry point
│ ├── qunit - Testing support files
│ └── run-tests.js - The PhantomJS QUnit test runner
└── tmp - Temporary build files used by rakep

I have a layout that I am pretty happy with
app.js - this is the main application file and includes settings and the router
views.js - contains views used within the app, although I usually now split this out to homeView.js navigtaionView.js etc
dataModels.js - this is where I hold all my data model objects for the app
dataSources.js - I use this to load datamodels or arrays of datamodels from any api calls I make
accountController.js - controller class, in the attached sample I also have an emailMessagingController and an smsMessagingController
You can find my sample project here
https://github.com/bwship/neptunejs
and the coffeescript files for ember here
https://github.com/bwship/neptunejs/tree/master/public/coffeescripts
and finally the jad file for the layout and index showing how I add these here
https://github.com/bwship/neptunejs/tree/master/views
I do want to eventually start using the ember data style, but have put out a few solid apps using the dataSources and dataModels files.

There still seems to be no clear convention, but currently many people seem to be using Yeoman and the official Ember generator https://github.com/yeoman/generator-ember
While I appreciate the "open" nature of the Ember tutorials, one of the nice things about Rails is the convention of file placement. When we hire a new developer, we don't need to give an explanation about our directory structure... I hope Ember sets an official standard soon.

Related

Project architectures differences for Django + Vuejs (or other) integration

I'm currently looking at project setups for a Django + Vuejs project (though I guess the question is likely just as valid for other frontends, react, svelte etc.).
It seems that there are mainly 2 approaches that come up often, resulting in the following project structure:
The frontend embedded within the Django project (perhaps as a git submodule):
root
├── djangoapp
├── djangoproject
├── manage.py
├── requirements.txt
├── static
├── venv
└── vueproject
├── node_modules
├── package.json
├── public
└── src
Another approach is to have them at the same level from project root, as 2 seperate projects actually (or I guess both could be git submodules to a "wrapper" project), so essentially:
root
├── djangoproject
│   └── <django files & folders>
└── vueproject
└── <vue files & folders>
With the 2nd approach, it seems you basically just see Django as an API. Stuff like collectstatic does not (?) come into play. In development, you need a server up to serve Django's api, and a dev server for the vue frontend.
With the 1st approach (if I understand correctly), seems that you build the Vue static files, and then manage all of that with Django's collectstatic/static files management.
Seems the 2nd approach is a better decoupling of the 2 components. With the 1st, you need to configure vue (or vite) rather specifically and Django's static files as well. What we gain by doing this isn't obvious to me - the more I think about it, the more it seems clear that the 2nd approach is better.
What potential advantages would there be in the 1st approach? Dev conveniences I'm not seeing? Easier deployment? Or is it just a somewhat outdate approach that still lingers the web?

Yii2 deployment for contributing

I am beginner Yii2 contributor. When I contribute in yiisoft/yii2 project, it is quite clear how to deploy the project and run its phpunit-tests. But I have some questions about working with extensions:
First I add an extension with composer require. Then git clone the same extension inside my home directory. After that I replace the first directory with symlink, which pointed to the second one. It is quite convenient due to I can see changes on the site, but I can't use composer anymore.
How to run the extension`s tests? They often depend on Yii2 app class, but
$ vendor/bin/phpunit vendor/yiisoft/yii2-elasticsearch/tests/
PHP Fatal error: Class 'yiiunit\extensions\elasticsearch\TestCase' not found in /var/www/yii2.test/vendor/yiisoft/yii2-elasticsearch/tests/ActiveDataProviderTest.php on line 11
$ vendor/bin/phpunit vendor/yiisoft/yii2-queue/tests/
PHP Fatal error: Class 'tests\TestCase' not found in /var/www/yii2.test/vendor/yiisoft/yii2-queue/tests/JobEventTest.php on line 22
Should I specify a config file? Or should I run these tests independently
of the framework?
So, would you please share with me the best practices about this situation?
You should run these tests outside of the framework. From extension perspective, yiisoft/yii2 is a dependency and should be installed in vendor directory inside of extension directory. So in short, you should go to extension directory and call composer install. After this you should get directory structure similar to this:
extension/
├── src/
│ └── ...
├── vendor/
│ ├── yiisoft/
│ │ ├── yii2/
│ │ └── ...
│ └── ...
├──composer.json
└── ...
Then you can run tests directly from extension directory (probably by vendor/bin/phpunit command).

Integrating jquery-csv into Rails app, ES15 syntax causing issues

I have already implemented a csv import feature in my app using this plugin, and it works great! But recently I had to reinstall some of my assets and it appears the plugin has some recent additions that include ES15 syntax. My Rails 4 app isn't ready to digest ES15 so I'm looking for a way to exclude the offending files if I can.
The plugin's directory structure looks like this (with some items omitted for brevity).
├── src
│   ├── jquery.csv.js
│   └── jquery.csv.min.js
└── test
├── csv.from_array.js
├── csv.from_arrays.js
├── csv.parsers.js
├── csv.to_array.js
├── etc ...
The ES15 code only appears in the test/ files. In my assets pipeline I include jquery.csv.js, which apparently includes the test/ files, as it's choking on the ES15 when I precompile assets. (If I don't require jquery.csv.js, assets precompile fine.)
This illustrates the errors I'm seeing when I precompile.
Seems like I should be able to do without the test files, but looking in jquery.csv.js it's not obvious to me how they're being included.
I know I should probably focus on getting Rails upgraded or use webpack/babel/whatever to integrate ES15 but I'm hoping for a short-term fix so I can move forward.
Thanks for any tips!

How to use models between multiple apps?

I'm building a Django app and I was asked split apart models.py and put the resulting models in a 'models' folder. I did that and it works fine.
I was then asked to move the models folder to the Project level so that the models can be used by other apps.
The file structure would look like this (taken from the Django tutorial):
mysite
mysite
polls
db.sqlite3
manage.py
models <- Have the poll app's models in there?
However, everything I have read suggests this is heavily frowned upon and that models should live at the app level, not the project level.
So, what is the best way to handle this is Django -- to let models be used by multiple applications? Some of the things I have read suggest importing models between apps or changing the models Meta class db_table option.
A majority of the posts I have found are from 5+ years ago though, so I'm not sure what the best current approach is.
If I import models to a new app, and then /do something with them, do they point to the same database as the app they were imported from or is a new database created for the new app?
Thanks for the help. Very appreciated.
I was wondering the same thing and saw you got a decent answer from reddit, but thought I'd throw my 2 cents in.
You could refactor the models into individual apps.
tl;dr
Some assumptions about your situation
At first, the models were split out from models.py into individual python files to improve maintainability
The models were moved up to the project level to minimize impact to the models by changes in the applications (or vice versa)
So for an example:
mysite
├── polls
│ ├── __init__.py
│ ├── admin.py
│ ├── apps.py
│ ├── migrations
│ │ └── __init__.py
│ ├── models
│ │ └── __init__.py
│ │ └── foo.py
│ │ └── bar.py
│ ├── tests.py
│ └── views.py
├── db.sqlite3
├── manage.py
└── mysite
├── __init__.py
├── settings.py
├── urls.py
└── wsgi.py
We have 2 models (foo and bar) that we separated for some logical reason.
IMHO, I think that overall maintainability could benefit by putting the foo and bar models in their own apps IF they satisfy 2 criteria
They are categorically different
They are used by multiple applications
At this point, the models can be imported by other apps in your site just as before, but the layout looks more like the Django best practices
New Layout:
mysite
├── polls
├── foo
│ └── models.py
│ └── etc...
├── bar
│ └── models.py
│ └── etc...
├── etc...
It's a good question, when you start programming in Django they tell you (Django project team) that an application is like a module, but they do not tell you how to do it.
You can do it as Rohan says in the comment to your question: "You can refer models from one app into another using 'appname.model_name' in the relationship fields.", but you must keep in mind that the concept of application in Django is thought to make these modules reusable, according to that the best option would be to orient your applications to services or another architecture that allows you to uncouple The applications of your project, look rest framework as an option

Use cases for new Django 1.4 project structure?

I guess this is sort of a followup question to Where should i create django apps in django 1.4? The final answer there seemed to be "nobody knows why Django changed the project structure" -- which seems a bit unsatisfactory.
We are starting up a new Django project, and currently we are following the basic structure outlined at http://www.deploydjango.com/django_project_structure/index.html:
├── project
│ ├── apps
│ │ ├── app1
│ │ └── app2
│ ├── libs
│ │ ├── lib1
│ │ └── lib2
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
└── manage.py
But I think we also are anticipating a multi-developer environment comprising largely independent applications with common project-level components, so it seems cleaner to me to separate out the project and app paths.
├── project
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── apps
│ ├── app1
│ └── app2
├── libs
│ ├── lib1
│ └── lib2
└── manage.py
It's hard to come up with any specific, non-stylistic rationale for this, though. (I've mostly worked only with single-app projects before now, so I may be missing something here.)
Mainly, I'm motivated by the fact that Django 1.4 seems to be moving in the latter direction. I assume there is some rationale or expected use case that motivated this change, but I've only seen speculation on what it might be.
Questions:
What was the motivation for the 1.4 project structure change?
Are there use cases where having apps inside/outside of the project makes a non-trivial impact?
It's much easier to extract an app from a project because there are no more imports like this:
from projectname.appname.models import MyModel
instead you import them the same way you would import apps which are installed via a python package
if you use i18n then this could make an impact because makemessages searches for translation strings in the current directory. a good way to translate apps and the project using a single .po file is to create the locale folder outside the project dir
├── project
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── app1
├── app2
├── locale
│ ├── en
│ └── de
└── manage.py
I marked the earlier response as an answer, but I ran into this blog post off the IRC archives that seems to have some additional info.
http://blog.tinbrain.net/blog/2012/mar/15/django-vs-pythonpath/
As I understand it, the gist is:
When you're developing, manage.py implicitly sets up PYTHONPATH to see the project-level code, with the result that import myapp works for an app defined inside the project.
When you deploy, you generally don't run manage.py, so you would have to say import myproject.myapp, thus things break on deployment if you don't know about this.
The "standard" fix is to add the project to PYTHONPATH, but this results in double-imports (myapp and myproject.myapp), which can generate weird behavior on things like signals.
So the 1.4 project structure seems mainly intended to eliminate the possibility of devs relying on an odd effect of manage.py.