I use both webpack and django. Now I move bundled assets to /static/ directory of django each time, so I'd like to make more effective process.
I read some articles and many people recommend to use django-webpack-loader, but I don't fully understand what it does.
I've already read the official documents below.
https://owais.lone.pw/blog/webpack-plus-reactjs-and-django/
https://406.ch/writing/our-approach-to-configuring-django-webpack-and-manifeststaticfilesstorage/
I think it's for collecting bundled assets located outside of django projects, but it seems almost same as creating a symbolic link from django project to dist/ directory in webpack.
Is there any other useful feature in django-webpack-loader?
It's a handy little tool. This gist of webpack loader is create a mechanism to link up to your latest bundle in an automated fashion.
A "render_bundle" template tag is provided that outputs link to load in either your latest JS or CSS bundle.
The tag is based from a hash of the bundle code (so this will change if your bundle changes) therefore browsers will always load in the most up-to-date version of your static assets. This cache-busting technique is useful when testing on mobile devices or situations where performing a 'hard' refresh of the page is not straightforward.
I believe this is achieved by the template tag referring to the output of BundleTracker, which outputs metadata about the status of your webpack bundle in webpack-stats.json.
https://www.npmjs.com/package/webpack-bundle-tracker
I think you might be missing that webpack will append a random hash code (so new builds bust caches). Without some special logic, django won't know how to account for the hash.
In my opinion all the other stuff the other answerer mentioned are sort of extra bonuses to make your life easier.
Related
I'm completly new with Django and python (and alone as tech in my company, not able to ask help to previous dev). I have to maintain an existing app written in django still developing new services fully written in node, which is my most important task (and my skills). I have a problem that i have fixed some bugs in UX, fixing CSS mostly. And I don't understand how to build sass.
In manage.py, when i ask the list of commands the only things which is related to my problem is "collectstatic" which seems to not build but just collect static files (good naming so) in one folder. And obviously, it doesn't resolve my problem.
Any suggestion ? I'm lost in this big new thing. Many love on every body who can help me. Do you know if there is an integrated tool ? Do i need to use an external compiler which is just not documented ?
Django got nothing to do with compiling assets, you compile it your way in node using your favorite bundler like gulp or webpack and then introduce the final path to django. but people stumbled upon this and created bunch of helper libs, checkout django_webpack.
In case you felt overwhelm then save learning curve time and do like I said earlier, bundle it on your flavor and create a management command in Django that you can run the bundler from python context.
I'm trying to optimize my company's application.
Tha architecture at this time is composed of different folders (inside common folder) for different sections of the app (for example Managing Bills, Managing Canteen, Managing Events etc etc).
Every js and css are included in the first page of the application (login.html) because I'm using the simple page template of jQuery Mobile.
Now I'm considering to add some other components to make the app easier to mantain and maybe speed it a bit.
What do you think about:
RequireJS to divide each section in a module so i can load only the javascript of a particular module at run-time instead of loading within login.html
Inline #imports for CSS files to produce single composite CSS
uglify.js to Minimize file sizes
Handlebars.js to realize fragments of html reusable
Do you think is a good way of work for an application that will become greater by adding new sections?
Do you think of other tools?
Thank you
This is a very broad question. I think you're on the right track... I'll list some libraries that could be worth trying:
Require.js - Will give you the ability to have 'modules' and dynamically determine and load dependancies. Alternatively some people prefer patterns such as the Revealing Module Pattern, jQuery Plugin Style or Common JS style modules. For what it's worth I recommend Require.js.
Bower is a package manager, you can use it to bower install [package]. They have a lot of packages here and you can also link it to your own repo. This could be helpful for managing dependancies.
Uglify.js and Google Closure Compiler are both good for minifying your code. Remember that some minification configurations such as advance mode could break your code. Run tests against the minified version of your source code.
QUnit is good for doing JavaScript unit tests. There are many other alternatives like Jasmine, which is what the Cordova guys use.
Lodash is another (faster) implementation of underscore.js that will provide a lot of utility methods for working wit arrays, objects, functions, etc. It also includes templating support. There's a good talk by the author here.
There a MV* JavaScript frameworks that could help more than jQuery (DOM+AJAX+Animations) or jQuery Mobile (Mostly UI) such as: Dojo, AngularJS, Backbone and Ember.js.
For UI you may want to checkout Adobe's topcoat repository and website. There's also Twitter Bootstrap and Foundation which allow you do to responsive design out of the box. If you're set on jQuery Mobile I personally like this Flat theme.
JSDoc and YUIDoc are good alternatives for documenting your JavaScript code.
I have no idea how many of those tools will interact inside Worklight Applications. It should be fine, since Worklight doesn't impose a certain set of JavaScript libraries you have to use. However, I haven't personally tried most of them inside Worklight Applications.
Ember don't seems to play well with requirejs or building with r.js without some hackery.
Bit hard to manage a large application, I like to break down my file structure as HMVC, which manages modules bit easier :
app
- blah
- modules
-module1
- controller
- model
- view.
Has anyone come up a build stack to automate the compilation into single file with dependency management?
Update: You should now be starting new projects using ember-cli, which provides all the build/dev tools plus many other useful features.
Original answer:
An example Ember project using grunt.js as a build system:
https://github.com/trek/ember-todos-with-build-tools-tests-and-other-modern-conveniences
I've used this as a starting point for some Ember apps and it works well.
Ember don't seems to play well with requirejs or building with r.js without some hackery.
Why do you want to use require.js in the first place?
As for making this all work you'll need a build tool. I recommend brunch (Node) or iridium (Ruby). Brunch is more simple and supports many different module formats. Iridium is much more powerful. It uses Minispade for modules. Require.js/AMD is not needed because your js is always delivered as a single concatenated file.
For stand-alone ember dev I use ember-skeleton as a starting point, which is itself based primarily on rake-pipeline.
https://github.com/interline/ember-skeleton
This provides the whole kit-and-kaboodle for beginning an app, but the meat of it is the rake-p Assetfile, which describes how rake-pipeline will digest all the files, filter their contents, and ultimately combine them into the final handful of files. Additionally, the combination of loader.js and the minispade filter allows the use of 'require()' statements for managing dependencies amongst your files.
I like to deploy the Spreecommerce locally and want to implement my own changes. I have deployed successfully but I don't know where the actual sources files comes or running. I need help to sort this out. Please can any one help me.
Thanks in Advance
Bundler downloads dependent gems into a cache location, but you don't want to mess with that if you're looking to make code changes. Anything you change there will be lost later when you update your gems.
You'll want to familiarize yourself with the standard rails customization methods. In order of least-to-most intrusive:
Decorators - files in your host application's app folder structure (assets, controllers, models, overrides, views, etc) which change a single method on Spree's objects by using the syntax Spree::[whatever class].class_eval do and then using standard ruby method definitions (followed by end). These files match their Spree counterpart in the same folder, just in your app instead of Spree's source. And with _decorator added to the end of the filename. See an example here: https://github.com/binaryphile/spree_dibs_1.2/blob/master/app/controllers/spree/admin/payments_controller_decorator.rb
Overriding entire Spree files - copy the Spree source file to the same location in your app then make the necessary source changes. This will override Spree's file of the same name (no _decorator this time). You're taking responsibility for migrating all future code changes by Spree to that file into your copy, which is why this is less desirable.
Fork the Spree source - change your Gemfile reference to your version instead of Spree. Make your changes to this code directly and run it instead of regular Spree. This is highly undesirable, as it makes upgrading Spree versions very involved and difficult.
If you're planning on making the code reusable, you could also investigate making it into an internal or published extension. See the Spree docs on that approach.
Im new to GIT and dont know yet how much it will fit my needs, but it looks impressive.
I have a single webapp that i use for differents customers (django+javascript)
I plan to use GIT to handle these differents customers version as branches. Each customer can have custom files, folders and settings, improved versions... but the should share the same 'core'. We are a small team and suscribed a github account.
Is the branch the good way to handle this case ?
About the settings file, how would you proceed ? Would you .gitignore the customer specific settings file and add a settings.xml.sample file for example is the repo ?
Also, is there any way to prevent some files to be merged into master ? (but commited to the customer branch). For example, id like to save some customer data to the customer branch but prevent from to being commited to master.
Is the .gitignore file branch-specific ? YES
EDIT
After reading all your answers (thanks!) i decided to first refactor my django project structure to isolate the core and my differents apps in an apps subfolder. Doing this makes a cleaner project, and tweaking the .gitignore file makes it easy to use git branches to manage the differents customers and settings !
Ju.
In addition to cpharmston's answer, it sounds like you need to do some refactoring to separate out what is truly custom for each client and what isn't. Then you may consider adding additional repositories to track the customizations for each client (entirely new repos, not branches). Then your deployment can pull your "core" from your main repo, and the client-specific stuff from that repo.
I would not use branches to accomplish what you are trying to do.
In source control, branches are intended to be used for things that are meant to be merged back into trunk. For example, Alex Gaynor spent his summer of code working on a branch of Django that allows for support for multiple databases, with the goal of eventually merging it back into the Django trunk.
Checkouts (or clones, in Git's case) might better suit what you are trying to do. You would create a repo containing all of the project's base files (and .sample files, if you will), and clone the repo to all the various locations you wish to deploy the code. Then manually create the configuration and customization files at each deployment (take care not to add them to the repo). Whenever you update the code in the repo, run a pull on each deployment to update the code. Viola!
Other answers are correct that you'll be in the best shape for maintenance to the extent that you separate out your core code from the custom per-client code. However, I'll break from the crowd and say that if you're unable to do that (say because you need to add extra functionality to core code for a certain client), DVCS branches would work just fine for what you want to do. Though I'd probably recommend per-directory branches rather than in-repo branches for this purpose (git can do per-directory branches as well, it's nothing but a cloned repo that diverges).
I use hg, not git, but all of my Django projects are cloned from the same base "project template" repo that has utility scripts, a basic common set of INSTALLED_APPS, etc. This means when I make changes to that project template, I can easily merge those common updates into existing projects. This isn't exactly the same as what you're planning, but is similar. You will occasionally have to deal with merge conflicts, if you modify the same area of code in the core that you've already customized for a specific client.
Matthew Talbert is correct, you really need to separate the custom stuff from non-custom stuff. If you can refactor all the core code to be contained in one directory, your clients can use it as a read-only git submodule. The added benefit is that you lock them into an explicit version of the core code. This means that they would have to consciously update to a newer revision, which is what you want for production code.
After reading all your answers (thanks!) i decided to first refactor my django project structure to isolate the core and my differents apps in an apps subfolder. Doing this makes a cleaner project, and tweaking the .gitignore in the differents branches file makes it easy to use git branches to manage the differents customers and settings !