5

Is this possible using v1.6.1? Due to the Xdomain configuration of my client's dojo deployment, it is necessary to execute a new build each time dev code changes. As you can imagine, this is a huge time waster.

From everything I can see there is no way to exempt the core from the build playing by DOJOs rules. So I am wondering if there is a way to break the rules (modifying the Rhino calls?) to get to where I need to be.

Web Devie
  • 1,207
  • 1
  • 13
  • 30
Derald Price
  • 51
  • 2

3 Answers3

2

A couple thoughts.

  1. You can avoid building most of dojo (dijit, dojox) but I imagine you already know that
  2. This restriction you are facing seems odd. Isn't there some way you can just upload the specific JS files you are editing during development?

Maybe if you give more details on the client setup, I can help you brainstorm a way around this problem.

Update Here's what I think you need: Customize Dojo Base in Build. This allows you to specify particular bits of the dojo base to include.

This works in pre-1.7, so you should be good.

Appears to be exactly what you want:

layers: [
  {
       name: "dojo.js",
       customBase: true,
       dependencies: [
       ]
  },

 // ... remainder of profile

 ]

This will give you the absolute bare minimum of dojo (which you still don't need for your dev scenario, but which will drastically reduce the amount of files processed).

For other use cases, you can use the dependencies attribute to add in other stuff from dojo core.

Update 2: Here's a couple build-time optimization suggestions:

1) Don't intern strings, and don't compress, when in dev. There are arg values you can pass to avoid these time-consuming steps (example is for ant build):

<arg value="internStrings=false"/>
<arg value="layerOptimize=false"/>

2) Build to a ram disk to speed copying of files

mtyson
  • 8,196
  • 16
  • 66
  • 106
  • Thanks for the feedback mtyson. To flesh this out a little more, this application is very large and has at least 15 different teams of 4-10 people working on it. As a result the client chose to segregate the dojo code on a seperate server from the presentation server. So, everything in the app is Xdomain. – Derald Price Feb 01 '12 at 20:02
  • So even for dev, you have to deploy the app itself and the JS codebase to different domains? And what you need is the ability to let a dev build as small amount as possible (that includes the bit they are working on), so they can get the xdomain version and test it.... thinking... – mtyson Feb 02 '12 at 00:47
  • Ok, updated the answer, I think I found something that will work for you. – mtyson Feb 02 '12 at 02:14
1

Dojo supports mix-and-match - so you can use xdomain and/or custom build for the stuff that does not change - and use regular dojo.require for the JS/widget that is changing often - and then just push that JS to see the change without a new xdomain/custom build/deployment

You can explore using local modules with xdomain build. Also, Dojo allows using multiple custom builds - so you can do a stable custom build for the widgets that don't change so much and another smaller build for code that is changing frequently.

animuson
  • 53,861
  • 28
  • 137
  • 147
Vijay Agrawal
  • 3,751
  • 2
  • 23
  • 25
  • Thanks Vijay. What I really need to do is find a way to create a build that excludes dojo base completely. I know this is not the way the build process works so I am looking for a "work around" if there is one. – Derald Price Feb 01 '12 at 20:22
1

Why not use dojo 1.7, load asynchronously, and rely on it's legacy support? http://livedocs.dojotoolkit.org/loader/amd

Ted
  • 1,641
  • 7
  • 30
  • 52