A typical extjs example application includes the extjs library by referencing files such as:
ext-all.css
ext-all.js
What's the 'rails 3.1 way' of including these files, noting that they reference hundreds? of files in subdirectories
(e.g. ext-4.0.2/resources/themes/stylesheets/ext4/default/_all.scss)
and there are relative paths:
(e.g. background-image:url('../../resources/themes/images/default/shared/shadow.png'))
I'm tried numerous combinations of require_tree et al., but can't seem to get it to work.
I'm wondering if I need to mess w/ 'provide', but I can't seem to find the documentation I need.
What you want is for this file to compile via the Rails asset pipeline:
resources/themes/templates/resources/sass/my-ext-theme.scss
To get this to work, I learned a few things the hard way:
ExtJS uses SASS to compile (so does Rails) and Compass, which includes blueprint and compass CSS kits. Compass doesn't work with rails, you need to use the gem "compass-rails", which doesn't include the CSS toolkits. Only the main compass gem has these toolkits, and it's a dependency for compass-rails so you should get them if you bundle compass-rails, they need to be in your sass.load_paths config. If you include the "compass" gem without compass-rails you will have strange errors and become an expert at the rails asset pipeline as you try to solve them!
ExtJS uses an older version of SASS, the newer one Rails uses doesn't like having functions and mixins defined inside of modules. To fix this, look at the errors it's giving you (always a function or mixin definition) and move them to _functions or _mixins files.
(more info: getting error after ugrading to sass-3.1.8)
Here's how to get up and running:
Put this into your config/application.rb:
# Set up our ExtJS SASS build environment
config.sass.load_paths << "#{Rails.root}/vendor/assets/stylesheets"
config.sass.load_paths << "#{Rails.root}/vendor/assets/frameworks/compass/stylesheets"
config.sass.load_paths << "#{Rails.root}/vendor/assets/frameworks/blueprint/stylesheets"
Put the ExtJS stylesheets (the ext4/default directory in the SDK) here:
vendor/assets/stylesheets/ext4/default/
Put my-ext-theme.scss into app/assets/stylesheets and use it like you normally would with rails. It will call this code:
#import 'ext4/default/all';
That will bring in all of the ExtJS definitions, and you should be on your way.
Jeff! Take a look at my answer here, I think your problem is the same.
Related
We have an ExtJS modern app. We would like to use cmd to minimize/compress our code into a single .js file - effectively doing what a non Ext app would do with other minifiers like uglifyjs or terser.
I believed we could achieve this with the compile command such as:
sencha -sdk ext-7.1.0.46 compile -cl=myclassfolder -inp=ES6 concat outfile.js
However, it complains that it can't find the Ext classes with an error like:
[ERR] Failed to resolve dependency Ext.data.Model for file myapp.model.mymodel
[ERR] Unknown definition for dependency : Ext.data.Model
It seems to be the basic task of extending Ext.data.Model it doesn't like and very much feels like I simply need to reference the extJS class structure correctly for this to work, but can't figure out the command line to make it happen (I somewhat assumed that the sdk reference would fix this).
Is this possible?
Ok, to help anyone who is facing the same problem and wants to compress/minify their ExtJS but without creating a full sencha app.
The command is fairly simple and the answer is to include the path to your dependent js files in the -cl (or -classpath) argument, then exlude the Ext namespace:
sencha -sdk stack/Sencha/ext-7.2.0 compile -cl=ext-modern-all.js,packages/ux/modern/ux.js,myclassfolder -inp=ES6 exclude -namespace Ext and concat outfile.js
You can then use terser or your preferred minify tools to minify/mangle the output (or add the compress command to the above to allow cmd to minify also). It's a reasonable way to build your ExtJS code into several manageable extjs "modules" which can be loaded when needed (or when security allows) rather than the "big bang" approach of cmd.
This will produce a single js file, correctly ordered, the only issue is that it includes the Ext microloader code, which it adds by default. I have not managed to have the compiler not inlcude the microloader, however you can effectively disable it by defining the microloader yourself between the load of your ext-all.js file and your newly created file by using something like this is another file or inline script tag:
Ext.Microloader = {
run: function(){}
};
I know there aren't many folks left using ExtJS, hope this helps someone at some point, at worst case it allows a bit more control of the ExtJS build process.
I followed the angular-meteor tutorial for the Socially app in Angular2. It basically works (after a few manual steps to fix package dependencies, etc), however, I am unable to debug the client side code in Chrome Dev Tools. When I navigate to the sources for my *.ts files, all I see are things like
module.export("default",exports.default=("<div> <ul> <li *ngFor=\"let party of parties\"> {{party.name}} <p>{{party.description}}</p> <p>{{party.location}}</p> </li> </ul> </div>"));
Other strange things in dev tools: my app.ts is blank. I see html files with !raw suffixes.... (e.g. app.html!raw). What is the !raw suffix and what causes that?
How can I debug my typescript?
I may be able to help with some parts of your question.
You don't mention which version of meteor you're using, but I assume version 1.4 or 1.4.0.1. I have seen that these versions of Meteor seem to have issues with sourcemaps for Typescript files (probably as they have to go through multiple transpilation steps).
I don't yet know where exactly the bug lies (Meteor or the Typescript compiler package).
Here's one github issue for this: https://github.com/barbatus/typescript/issues/23
UPDATE: This issue has now been fixed.
For now, my suggestion would be to try reverting to a 1.3.x.x version of Meteor. For something like the Socially tutorial, the easiest option is to specify the Meteor release at creation time:
$ meteor create --release 1.3.5.1 Socially
(list of releases is at: https://github.com/meteor/meteor/releases)
The 'app.html' and 'app.html!raw' files are generated by the meteor angular compilers as a way of working around issues with using templateUrl and the meteor build process. My understanding is that the preferred approach is to have inline templates or import the templates like this:
// This import loads the content of the html file into 'template'
import template from './app.html';
#Component({
selector: 'app',
// Instead of templateUrl, use:
template, // <--- 'template,' is syntactic sugar for: 'template: template,'
directives ... etc.
The import statement is a bit unusual, and this magic is achieved by the meteor angular pre-compiler that converts every html and css file into a couple of js files. That's what strange app.html and app.html!raw are.
The funny characters in the first app folder seem to be a bug. Meteor tries to generate put in a computer emoji, but sometimes this gets handled incorrectly. I'm not sure if this is a bug Chrome, ChromeDevTools or Meteor. (Personally, I wish they'd ditch the emoji).
There are several blog posts that explain why switching from grunt or gulp to building with just plain npm is a good idea for example this one by Cory Hourse or this one by Keith Cirkle. One thing these blog posts do not explain is how I can easily do environment configuration. For example a common requirement is to have different REST API locations. During development the server might be running on localhost:8080, but on production it should be accessed through a relative URL such as /api or /rest/api and the port or protocol are different for development and production.
There are several solutions for this. For example grunt supports template strings like <% %> and <%= %> and there are grunt or gulp plugins like in this question about grunt-ng-config. These solutions are specific to Angular (which I am using), but I am not necessary looking for an AngularJS specific solution.
I also know of the angular-environment plugin, but as far as I can see this does configuration at run time and I am looking for something that can do this at build time.
So what I am looking for is something that allows me to configure my application at build time either by replacing some template strings or by generating a Javascript file with some variables that I can read at run time.
One requirement is that it should be OS independent. So I do not want to use UNIX specific tools such as sed to rewrite a file. And due to different variable expansion (e.g. % vs. $) a solution should not rely on environment variables.
Is there an existing solution or a best-practice for this?
due to different variable expansion (e.g. % vs. $) a solution should
not rely on environment variables
this cuts off your best solution. Why not rely on env vars? node provides
process.env
to access env vars. You could create custom gulp / grunt tasks that use process.env instead of the "different variable expansions" you refer to.
You can use, for example, Jade templating to pass env var values to your HTML at build time. This would generate your index.html on the fly as part of the build process and add relevant classes based on env vars.
For example, according to the value of an env var you might set a class on the HTML tag.
This might reflect the customer.
Then you could have some CSS
.customer1 .myimage {
background-image: url("customer1.png");
}
.customer2 .myimage {
background-image: url("customer2.png");
}
or you could use JavaScript to detect which class was added to head during the build.
https://github.com/eiriklv/react-masonry-mixin/blob/master/README.md
The above example shows the simple steps to get masonry-mixin working on node-js.
What solutions are available to enable my react component to use this plugin within a normal webpage? I would like a solution that has the least amount of 3rd party software to get working.
The require statement is not available without npm from what I understand.
Require statements can be used in client-side using a preprocessor called Browserify.
In order to use Browserify, you have to have one main .js file from which all your other files are loaded via require statements (however tangentially). You then run the Browserify command to parse and bundle it all into one file:
$ browserify main.js > bundle.js
I've personally used react-masonry-mixin, and this is the approach I use (although automated with Gulp).
Using Cmd 3.0.0.141, I have successfully generated a workspace and an Ext app in that workspace. The application builds correctly until I attempt to integrate the Bryntum Scheduler, where I encounter an error when I try to build:
"Failed to resolve dependency Sch.panel.SchedulerTree for file ExtCalendar.view.Tree"
the app is very simple at this point, uses Ext.application and follows the MVC pattern where I have a view defined "ExtCalendar.view.Tree" that extends 'Sch.panel.SchedulerTree". I also have models and stores that extend Bryntum classes as well, so I assume the compiler will trip over those as well, since it can't see the Sch namespace.
I've added a 'js' path to my app.json that points to the bryntum js file where 'Sch.panel.SchedulerTree' comes from. I've tried to run the 'refresh' command with the same results (Failed to resolve...). I've regenerated the bootstrap.js file manually using 'compile', but nothing from the Sch namespace ever gets added to it, despite the Brytum lib file being in the classpath.
What do I need to do in order to successfully run the 'build' command with libs like this?
Or, do I need to take a more granular approach using the 'compile' command?
With the help of the nice folks on the Sencha forums, I was able to resolve my build issues. The solution, for me, involved a shim. I added an external shim.js file to my index with as many //#require and //#define directives as needed in order to resolve the dependency issues.
According to the nice folks at Bryntum, once I upgrade from the free-trial version of the Bryntum Scheduler, I will be able to get rid of the shim and simply rely on the sencha.cfg classpath pointing at the Bryntum src.
Also, as an aside, the app.json file is not used in ExtJS apps, its inclusion in the generated files was a bug in build 141 of Cmd v3.
See this thread for more detail.