I've some html5/ js game widgets that are shared between my webapp and my ipad app. I've used some ERB code here. The process is, whenever the user purchases a game from ipad, I copy all these assets to a temp folder, zip it and send it back.
Now the problem is, since I'm using ERB, the code is not compiled. This game widget folder is not a part of the asset pipeline as it is required only in certain cases.
Is there a way I can compile these games on demand before copying?
From what I can understand, I'd say your problem lies with your use of ERB code
ERB, like HTML, can only be rendered by a specific technology stack (in our case Rails). This means you need all the other dependencies to make it work, which is where you're hitting problems
Rails
I would recommend your best bet is to create a Rails process to "compile" the JS for you
As a matter of speculation, I'd recommend you'll have to look at creating either a queued job or a scheduled rake task to do this:
Create a special controller action
Use the controller action to load required data
Use a way to create a ZIP file
Save the file
If you'd like me to write some code (although I've never done it for this before), I'll have a look at it for you
Related
When I start a new Rails application, I often use certain parameters to rails new like --skip-spring or --skip-turbolinks.
I understand I can put these in ~/.railsrc, but when using multiple dev computers, it can be a bit tedious to keep railsrc files in sync across all of them.
Can I use application templates to add these parameters to the generator? That would be great, because application templates can be referenced by a url and downloaded on the fly.
(Also I know I can use templates to make changes after the application is created, so I can remove spring or turbolinks or whatever, but it would be much nicer to never generate the app that way.)
To answer my own question after looking into how this works, I think the short answer is that it's not possible to add generator parameters from an application template to rails new itself. The reason is that the template code only runs when the application is already generated.
So that I could take advantage of all the already well developed front-end tools like requirejs, bower and grunt... It's just that so many of them somehow get crippled going with rails.
Primary advantages:
It is easier to load third party scripts this way. It is always possible and sometimes easy to put these through the asset pipeline, but it is also often tedious and you lose bower.
Scripts in public will not be digested, so they can be loaded by non-rails pages easily. For example, you use a javascript file on your site, and also need to load it on another, e.g., PHP site, or need to allow other people to load your script for an embedded API, etc... then you'll need to serve from public.
Primary disadvantages:
Because you're not using the asset pipeline you lose:
Asset combining and compression. Asset pipeline CSS and Javascript will be loaded in a single HTTP request each, and the content can be minified. This makes first page load on your site faster, especially if you have lots of client code or a site that needs to be super snappy for occasional visitors.
Digesting. The asset pipeline protects you 100% from cache vagaries and potentially having different users seeing your site with different version of your assets. Once you deploy, every visitor will get the new assets.
Relatively automatic etagging. Once those visitors get the new assets, their clients will generally cache them for a long time. Rails can afford to let assets cache essentially forever because digesting ensures you're not punished for this later.
So there are pros and const both ways and neither is right or wrong.
It's just that so many of them somehow get crippled going with rails
Pipeline
The reason is you're not meant to use the likes of Grunt etc with Rails. Rails' asset pipeline is only meant to contain the files which can be precompiled & used directly in your application:
The asset pipeline provides a framework to concatenate and minify or
compress JavaScript and CSS assets. It also adds the ability to write
these assets in other languages and pre-processors such as
CoffeeScript, Sass and ERB.
This will typically mean compiled third party JS/CSS files, and your own application JS/CSS files. I don't see how something like Grunt would provide any benefit to this? All it does it create a way for you to manage dependencies, versioning & source of particular assets?
--
Public
Using the files in your public folder isn't such a big deal. One of the most prominent things it does do is to exclude those particular files from the file digest processs, allowing you to use the likes of endpoints (scripts) which can be accessed by other services (outside the scope of routes.rb)
A good example of this is when we created an analytics system, and put the analytics.js into the public folder, so all the widgets could access it. This allowed other sites to access this file, regardless of the state of the asset pre-compilation.
One caveat to this would be you could perhaps have some way to store a "pseudo" file in the public folder, with it routing dynamically (with ERB) to the precompiled equivalent, but I've got no experience with this
--
Pipeline
The benefits of keeping your assets inside the asset pipeline, as stated by gwcoffey, are:
They will be compiled as you design (I.E primarily into application.js, but also into any other files you define too)
You don't need to worry about versioning (every precompile is basically a way to better the version without worrying about grunt etc)
You can include as many dependencies as you want - meaning you're able to create a totally modular set of assets which can be used throughout your app; rather than single scripts which will have their own dependency base
Recommendation
Unless you maintain third-party scripts which need dependencies to run, I would not recommend using Grunt for Rails. If you develop your own JQuery / Javascript scripts, by all means run them through Grunt etc; but for use in your app, I'd steer clear
Hope that helps!
How would you structure a simple Sinatra app?
I'm making it right now and I want the app to have these features:
The "app" is more of an admin dashboard for all the information inside it. Then another app will access the information via REST. I have not created the dashboard yet, just the getting of things from the database
Sessions and authentication (have not implemented this yet)
You can upload pictures, and other the other app can display those pictures
I have created a testing file using RSpec
Reports generation via Prawn
Currently the setup is just this:
app.rb
test_app.rb
because I have literally just the app and testing file. So far I have used Datamapper for the ORM, SQLite for the database. This is my first Ruby/Sinatra project, so any and all advice is welcome - what other libraries should I be using, should I put stuff like config.ru, etc.
Sinatra is not opinionated when it comes to your file structure, you can place files however you like. When I first started I just dropped everything in the top level, but over time reading how people structure their code, reading over the source code of gems I've broken up my code into smaller .rb files that fulfill a specific function and places all of them under /lib, it's a convention carried over from rails perhaps but does not have any of the magic associated with it in rails. If you use scss or coffee script they depend on certain folders to exist, you will discover for yourself over time (and even then you can reconfigure them however you wish) and from this you will figure out what works best for you.
if you write a restful api, check out grape - https://github.com/intridea/grape
you will also find sinatra-contrib to be very useful - https://github.com/sinatra/sinatra-contrib
As for what to do with your config.ru - https://github.com/rack/rack/wiki/%28tutorial%29-rackup-howto
I'm making a gem that will add some custom responders to an application's controllers. To test this, I'm going to need a dummy application sitting inside of a test directory that I can load and somehow generate views from.
I'd prefer to use Cucumber to test this gem, because that is what I'm most comfortable with having used it in the past.
How do I generate an application inside of my test directory like this? I will need at least a controller and a model, but views aren't necessary (the responder is only for JSON). Can I just generate a new Rails app within /features/support/dummy? How would I run the dummy application from within my test suite?
At first, do not generate anything within features/support/. That's the place for global hooks.
Your problem sounds not hard if I understood correctly. Here is my proposed steps.
Create a demo directory in project root. New demo app will be under it.
Create a ruby module/class under features/support/, with methods to generate a demo app and delete it. The demo app will be simply some directories like app/contorllers for test purpose. Making a whole new Rails app sounds overkill.
Create a tag for the Scenario which need generate app. Add Before and After hook for this tag to add and remove app for this Scenario, by calling the module/class in #2
How can I run specific compilation tasks with rails/asset pipeline/sprockets within my application?
Basically, I have sets of user created css for an application; users upload css for their parts of the application (security considerations aside etc, already handled). How do I run a task to compile specific css sets into the main css I have? This is not a live compilation issue, I just want to take an input, compile that to a file, and serve that that on demand, which is more a 'I need this set of css precompiled at will when I want to precompile it within a running application'
I'm updating something implemented previously where I was able to haphazardly serve user generated css, I'd like to integrate this with the asset pipeline. How can I get greater control over the asset pipeline? I'm assuming I need to learn more about Sprockets, but I'd be curious what anyone could add to assist.
Per user CSS files would be possible, but to use Sprockets and the pipeline in the intended way to generate the files is going to take a bit of messing about.
To generate a user CSS file you are going to have to:
1. Generate a manifest for the user.
The manifest would include the main css via a sprockets directive, and require self at the end along with the user css.
The manifest file would need a name that is unique to the user
2. Compile the manifest.
You won't want to compile them all, so you'll need to write something to do just the one you want.
3. Add the new manifest to the pipeline manifest
This is a YAML file that holds the mappings between the name of manifests and files in the pipeline and their hashed counter-parts. You'll need to add your new (or updated) file hash to this without clobbering the other entries.
4. Restart your app.
This is required because Rails read in the pipeline manifest when it starts up, so you would not see any changes you'd made until this occurs.
==
Then you will be able to reference the username based CSS file for the user.
The with this approach is that each time you deploy the custom manifest would be overwritten.
If you are storing the user's custom CSS in the database you could write out the custom user manifests at each deploy.
Another approach is to use the pipeline for the main CSS and ignore it completely for the user CSS, just doing what you do now. Use on link for the pipeline CSS and a second for the user CSS. You could still minify the CSS when the file is created, but if the extra request is out of the question then something based on the above.
Best of luck!