Skip to main content
Geographic Information Systems

Return to Answer

grunt esri slurp is a game changer!
Source Link
Steve
Steve
  • 1.3k
  • 1
  • 8
  • 19

I would agree with Moyles that the samples are just samples and dojo boileplate is a great resource however at current snovers boilerplate isn't a viable solution. You have two different versions of dojo going on there. The current js api still uses the classic require syntax of dojo 1.6.1 and does not support AMD. I'm sure that a newer js api will be built on 1.7.x and since converting classic dojo.defined modules to AMD is mostly trivial I would choose that route.

If you're starting your project now then I would choose whatever server side framework you wanted to use (if it is necessary for your application. If its just a single page viewer with no server side requirements then don't over complicate things). It could be rails, php, asp, whatever. Follow the best practices for your framework/language.

Then since esri is built on dojo you are already loading a great js framework for creating large scale web applications. Structure your code so that the dojo's loader can load your widgets and modules with the dojo require syntax. Write dojo widgets and modules, use dijits and dojox tools when necessary ( http://dojotoolkit.org/documentation/tutorials/1.6/declare, http://dojotoolkit.org/documentation/tutorials/1.6/recipes/custom_widget/, http://dojotoolkit.org/documentation/tutorials/1.6/understanding_widget, http://dojotoolkit.org/documentation/tutorials/1.6/templated, http://dojotoolkit.org/documentation/tutorials/1.6/cdn). Do not write inline js like the samples do. Create a build profile to optimize all your code when its time for production.

You have to keep your esri and custom code separate to a certain degree because they don't offer the source for compiling - it's already built and minified. The build tool doesn't like that so much.

EDIT

I built a grunt tool, esri_slurp to download the esri js api so you can use it as a package in your applications. This allows you to run the build and get a single file.

I would agree with Moyles that the samples are just samples and dojo boileplate is a great resource however at current snovers boilerplate isn't a viable solution. You have two different versions of dojo going on there. The current js api still uses the classic require syntax of dojo 1.6.1 and does not support AMD. I'm sure that a newer js api will be built on 1.7.x and since converting classic dojo.defined modules to AMD is mostly trivial I would choose that route.

If you're starting your project now then I would choose whatever server side framework you wanted to use (if it is necessary for your application. If its just a single page viewer with no server side requirements then don't over complicate things). It could be rails, php, asp, whatever. Follow the best practices for your framework/language.

Then since esri is built on dojo you are already loading a great js framework for creating large scale web applications. Structure your code so that the dojo's loader can load your widgets and modules with the dojo require syntax. Write dojo widgets and modules, use dijits and dojox tools when necessary ( http://dojotoolkit.org/documentation/tutorials/1.6/declare, http://dojotoolkit.org/documentation/tutorials/1.6/recipes/custom_widget/, http://dojotoolkit.org/documentation/tutorials/1.6/understanding_widget, http://dojotoolkit.org/documentation/tutorials/1.6/templated, http://dojotoolkit.org/documentation/tutorials/1.6/cdn). Do not write inline js like the samples do. Create a build profile to optimize all your code when its time for production.

You have to keep your esri and custom code separate to a certain degree because they don't offer the source for compiling - it's already built and minified. The build tool doesn't like that so much.

I would agree with Moyles that the samples are just samples and dojo boileplate is a great resource however at current snovers boilerplate isn't a viable solution. You have two different versions of dojo going on there. The current js api still uses the classic require syntax of dojo 1.6.1 and does not support AMD. I'm sure that a newer js api will be built on 1.7.x and since converting classic dojo.defined modules to AMD is mostly trivial I would choose that route.

If you're starting your project now then I would choose whatever server side framework you wanted to use (if it is necessary for your application. If its just a single page viewer with no server side requirements then don't over complicate things). It could be rails, php, asp, whatever. Follow the best practices for your framework/language.

Then since esri is built on dojo you are already loading a great js framework for creating large scale web applications. Structure your code so that the dojo's loader can load your widgets and modules with the dojo require syntax. Write dojo widgets and modules, use dijits and dojox tools when necessary ( http://dojotoolkit.org/documentation/tutorials/1.6/declare, http://dojotoolkit.org/documentation/tutorials/1.6/recipes/custom_widget/, http://dojotoolkit.org/documentation/tutorials/1.6/understanding_widget, http://dojotoolkit.org/documentation/tutorials/1.6/templated, http://dojotoolkit.org/documentation/tutorials/1.6/cdn). Do not write inline js like the samples do. Create a build profile to optimize all your code when its time for production.

You have to keep your esri and custom code separate to a certain degree because they don't offer the source for compiling - it's already built and minified. The build tool doesn't like that so much.

EDIT

I built a grunt tool, esri_slurp to download the esri js api so you can use it as a package in your applications. This allows you to run the build and get a single file.

added 583 characters in body
Source Link
Steve
Steve
  • 1.3k
  • 1
  • 8
  • 19

I would agree with Moyles that the samples are just samples and dojo boileplate is a great resource however at current snovers boilerplate isn't a viable solution. You have two different versions of dojo going on there. The current js api still uses the classic require syntax of dojo 1.6.1 and does not support AMD. I'm sure that a newer js api will be built on 1.7.x and since converting classic dojo.defined modules to AMD is mostly trivial I would choose that route.

If you're starting your project now then I would choose whatever server side framework you wanted to use - if(if it is necessary for your application. If its just a single page viewer with no server side requirements then don't over complicate things). It could be rails, php, asp, whatever. Follow the best practices for your framework/language.

Then since esri is built on dojo you are already loading a great js framework for creating large scale web applications. Structure your code so that the dojo's loader can load your widgets and modules with the dojo require syntax. Write dojo 'classes'widgets and modules, use dijits and dojox tools when necessary ( http://dojotoolkit.org/documentation/tutorials/1.6/declare, http://dojotoolkit.org/documentation/tutorials/1.6/recipes/custom_widget/, http://dojotoolkit.org/documentation/tutorials/1.6/understanding_widget, http://dojotoolkit.org/documentation/tutorials/1.6/templated, http://dojotoolkit.org/documentation/tutorials/1.6/cdn). Do not write inline js like the samples do. Create a buildbuild profile to optimize all your code when its time for production.

You have to keep your esri and custom code separate to a certain degree because they don't offer the source for compiling - it's already built and minified. The build tool doesn't like that so much.

I would agree with Moyles that the samples are just samples and dojo boileplate is a great resource however at current snovers boilerplate isn't a viable solution. You have two different versions of dojo going on there. The current js api still uses the classic require syntax of dojo 1.6.1 and does not support AMD. I'm sure that a newer js api will be built on 1.7.x and since converting classic dojo.defined modules to AMD is mostly trivial I would choose that route.

If you're starting your project now then I would choose whatever server side framework you wanted to use - if it is necessary for your application. It could be rails, php, asp, whatever.

Then since esri is built on dojo you are already loading a great js framework for creating large scale web applications. Structure your code so that the dojo's loader can load your modules with the dojo require syntax. Write dojo 'classes' and modules. Do not write inline js like the samples do. Create a build profile to optimize all your code when its time for production.

You have to keep your esri and custom code separate to a certain degree because they don't offer the source for compiling - it's already built and minified. The build tool doesn't like that so much.

I would agree with Moyles that the samples are just samples and dojo boileplate is a great resource however at current snovers boilerplate isn't a viable solution. You have two different versions of dojo going on there. The current js api still uses the classic require syntax of dojo 1.6.1 and does not support AMD. I'm sure that a newer js api will be built on 1.7.x and since converting classic dojo.defined modules to AMD is mostly trivial I would choose that route.

If you're starting your project now then I would choose whatever server side framework you wanted to use (if it is necessary for your application. If its just a single page viewer with no server side requirements then don't over complicate things). It could be rails, php, asp, whatever. Follow the best practices for your framework/language.

Then since esri is built on dojo you are already loading a great js framework for creating large scale web applications. Structure your code so that the dojo's loader can load your widgets and modules with the dojo require syntax. Write dojo widgets and modules, use dijits and dojox tools when necessary ( http://dojotoolkit.org/documentation/tutorials/1.6/declare, http://dojotoolkit.org/documentation/tutorials/1.6/recipes/custom_widget/, http://dojotoolkit.org/documentation/tutorials/1.6/understanding_widget, http://dojotoolkit.org/documentation/tutorials/1.6/templated, http://dojotoolkit.org/documentation/tutorials/1.6/cdn). Do not write inline js like the samples do. Create a build profile to optimize all your code when its time for production.

You have to keep your esri and custom code separate to a certain degree because they don't offer the source for compiling - it's already built and minified. The build tool doesn't like that so much.

Source Link
Steve
Steve
  • 1.3k
  • 1
  • 8
  • 19

I would agree with Moyles that the samples are just samples and dojo boileplate is a great resource however at current snovers boilerplate isn't a viable solution. You have two different versions of dojo going on there. The current js api still uses the classic require syntax of dojo 1.6.1 and does not support AMD. I'm sure that a newer js api will be built on 1.7.x and since converting classic dojo.defined modules to AMD is mostly trivial I would choose that route.

If you're starting your project now then I would choose whatever server side framework you wanted to use - if it is necessary for your application. It could be rails, php, asp, whatever.

Then since esri is built on dojo you are already loading a great js framework for creating large scale web applications. Structure your code so that the dojo's loader can load your modules with the dojo require syntax. Write dojo 'classes' and modules. Do not write inline js like the samples do. Create a build profile to optimize all your code when its time for production.

You have to keep your esri and custom code separate to a certain degree because they don't offer the source for compiling - it's already built and minified. The build tool doesn't like that so much.