topic Re: Building a modular application in ArcGIS JavaScript Maps SDK Questions

Building a modular application

HenryColomb — Fri, 18 Nov 2011 17:06:37 GMT

Hey all
I am coming from a flex background and like a few other people on this forum started working with the javascript api after certain developments regarding flash in the past couple weeks. I have some sites and functionality working fine but there is one issue I am having trouble with. I would like to be able to develop a javascript app with a modular structure(similar to the sample flex viewer) so as to keep from having 500+ lines of javascript in the main html page and have something a little easier to work on and maintain. I know you can do this with dojo but I am having problems getting the dojo.require("mymodule") to resolve at the same time as getting dojo.require("esri.map") to resolve. Does anyone have a simple example of say an identify task in a seperate .js file or something similar?
Hope that makes sense.
Thanks
Henry

Re: Building a modular application

derekswingley1 — Fri, 18 Nov 2011 20:23:34 GMT

This is something we should probably talk about more often but we tend not to because it's so dojo centric. Plain old JavaScript will let you do whatever you want from stuffing everything in a single .html file to setting up your own class-based inheritance system. The latter is a ton of work but thankfuly dojo takes care of this for us. I would recommend reading up on dojo.declare and also looking into creating custom widgets as another way to modularize your code.

You mentioned that you're having some trouble with module paths. What are you specifying in your dojoConfig or djConfig object and where are your .js files relative to file where modulePaths are defined?

Re: Building a modular application

HenryColomb — Fri, 18 Nov 2011 20:47:13 GMT

After some more work on it I got some simple references to work when I added a local copy of dojo.js. Then trying to do an identify task in mymodule.js with the map code in index.html and trying to reference back and forth was making my head spin. Much of this has to do with being a javascript noob and being used to dealing with complied code. Ill check out your links and see if I can get something very basic going and post the code.
Thanks for such a quick reply Derek!

Re: Building a modular application

HenryColomb — Wed, 23 Nov 2011 20:24:55 GMT

So after a little more work and understanding I have a custom dojo widet at domain/site/custom/CustomWidget like in the linked tutorial. If I set the djConfig to baseUrl : './' it breaks all the layout and other dojo code. If I comment out the baseUrl the app loads fine but then I get a "reference error custom is not defined". According to dojo the default baseUrl is set by the root of the dojo.js but what is the baseUrl when loading dojo from cross domain like arcgisonline.com/jsapi/arcgis/?v=2.5.
Thanks
Henry

Re: Building a modular application

DavidHollema — Fri, 09 Dec 2011 21:52:16 GMT

I'm having difficulty with this too. I'm trying to reference a custom dijit on my local web server while using the ESRI's javascript API via CDN. I'm trying to make use of dojo module system and have my folder structure correct to map to the namespace.

In my host html page...

<script type="text/javascript" src="http://serverapi.arcgisonline.com/jsapi/arcgis/?v=2.5">

and

   <script type="text/javascript">
     var djConfig = {
        parseOnLoad: true,
        modulePaths: {"nrss": "http://localhost:70/Scripts/nrss"}
    };

and

dojo.require("nrss.overflights.dijit.SimpleBehavioralDijit");

Trouble is firebug tells me it's looking for an xd.js file. I don't know how to create one. Further, I don't understand how the xd files differ. I'm familiar with cross-domain issues in Silverlight/Flex and jsonp approaches but don't understand how that relates to these xd files. Also, what is a cross-domain build of dojo or esri's javascript api?

Two useful links but still don't get me all the way to a solution.

http://www.reigndropsfall.net/2010/07/07/local-modules-with-xdomain/
http://nileshbansal.blogspot.com/2008/03/creating-custom-dojo-widget-using-cross.html

I tried manually creating the xd file following the recipe from the 2nd link above but it fails...how can I create these using the dojo build system? And how do these xd files differ? Ultimately I want to use remotely hosted esri api with locally hosted custom widgets.

Re: Building a modular application

HenryColomb — Fri, 09 Dec 2011 23:04:11 GMT

Hey David
I have almost got this working the way I want after going through a couple of the dojo tutorials which were very helpful. Using Custom Modules with a CDN and Application Controller.
Start a blank site in your IDE and link it to your IIS and run through these. Also in the tutorials make sure to copy the css links and js files from the tutorial sources. In the dojoConfig(or djConfig) I replaced isDebug:true with debugAtAllCosts:true which will let you step through your modules with firebug. I can post some code too if need be. Make sure to put the dojoConfig script tag before the cdn script tag.
Hope that helps
Henry

Re: Building a modular application

DavidHollema — Mon, 12 Dec 2011 20:05:13 GMT

Henry,

Thanks for the links...that first one was especially helpful and I'm now running my custom dijit and CDN simultaneously. I have another issue in how my custom dijit is behaving with the attribute inspector (http://forums.arcgis.com/threads/45726-Editor-attribute-inspector-default-values?p=156031) but at least I'm past step 1. Here's what I ended up doing.

<script type="text/javascript">
     var djConfig = {
         parseOnLoad: true,
        baseUrl: "Scripts/",
        modulePaths: { "nrss": "nrss" },
        debugAtAllCosts: true
    };
</script>


    <script type="text/javascript" src="http://serverapi.arcgisonline.com/jsapi/arcgis/?v=2.5">
    </script>
    <script type="text/javascript" src="/Scripts/Overflights.js"></script>

    <script type="text/javascript">
        dojo.require("dijit.form.Button");
        dojo.require("dijit.dijit"); // optimize: load dijit layer
        dojo.require("dijit.layout.BorderContainer");
        dojo.require("dijit.layout.StackContainer");
        dojo.require("dijit.layout.ContentPane");
        dojo.require("dijit.layout.LayoutContainer");
        dojo.require("dijit.TitlePane");
        dojo.require("nrss.overflights.dijit.SimpleBehavioralDijit"); //my custom dijit
        dojo.require("dojo.parser");

        var user = '@User.Identity.Name.Replace('\\','/')';
        var overflights = new Overflights(user);

        dojo.addOnLoad(function(){
        overflights.initMap();
        });
    </script>

The trick was setting the baseUrl properly and modulePaths correctly. My script folder structure looks like this...

webroot/Scripts/nrss/overflights/dijit/SimpleBehavioralDijit.js

I did not have to go down the xd route at all. Standard, non-xd dijit worked fine. See the link above for source code for dijit.

Re: Building a modular application

JohnnyPenet — Wed, 25 Apr 2012 15:22:49 GMT

Hi Henry,

You can look at my blog 'jpenet.blogspot.com' . I am currently migrating a Silverlight application towards JavaScript based on using MVVM pattern.
In Silverlight I used PRISM to have a modular framework. Based on that I idea I am now trying to create a 'ArcMap' light with JavaScript keeping the JavaScript code separated from the web page. As I do this part-time, it will take some time before I can release the whole application. In principle this could be done in the same way in flex.

Regards

Johnny

Re: Building a modular application

derekswingley1 — Wed, 25 Apr 2012 16:33:48 GMT

I am currently migrating a Silverlight application towards JavaScript based on using MVVM pattern.
In Silverlight I used PRISM to have a modular framework. Based on that I idea I am now trying to create a 'ArcMap' light with JavaScript keeping the JavaScript code separated from the web page.

I'm happy to hear that you're moving to using the ArcGIS API for JavaScript but I'd like to discourage you from trying to duplicate ArcMap in a browser. Web apps should not strive to duplicate heavyweight desktop clients, even if your goal is a light version. I would instead encourage you to build focused, targeted apps with a specific use in mind. Try to build apps that answers a specific question or addresses a specific problem rather than building something that is a tool for general analysis.

Re: Building a modular application

JeffPace — Wed, 25 Apr 2012 17:42:04 GMT

I'm happy to hear that you're moving to using the ArcGIS API for JavaScript but I'd like to discourage you from trying to duplicate ArcMap in a browser. Web apps should not strive to duplicate heavyweight desktop clients, even if your goal is a light version. I would instead encourage you to build focused, targeted apps with a specific use in mind. Try to build apps that answers a specific question or addresses a specific problem rather than building something that is a tool for general analysis.

While I agree with this both in principle (as a developer) and in theory, unfortunately it does not work in practice. On mobile devices users are willing to tolerate a single use app because they are so fast and lightweight.

However, on the web, they expect full functionality. Can you imagine from a training standpoint:

If you want parcels, open this webpage. Oh you want to see Zoning, thats a different app. Oh you want Utilities, app number 3. Measure, Redline, Geocode? apps 4 5 and 6.
User = gone.

Of course, as soon as we add it all to one app, you get complaints about speed.

Our app is a slow all in one, so we developed a very light fast specific app. Immediately requests starting pouring in to add everything we had removed to speed it up.

Unfortunately, for the majority of our users, the specific question or problem they want answered is "how can i do everything that i can do on the desktop on the web for free"

🙂

Here is a link to our slow all in one.

http://www.mymanatee.org/gisapps/mapviewer/

Re: Building a modular application

derekswingley1 — Wed, 25 Apr 2012 19:07:53 GMT

Can you imagine from a training standpoint:

If you want parcels, open this webpage. Oh you want to see Zoning, thats a different app. Oh you want Utilities, app number 3. Measure, Redline, Geocode? apps 4 5 and 6.
User = gone.

I hear ya. What I'm trying to say is that there's a sweet spot: can (should?) a parcel viewer also show zoning info? Yes, of course. Zoning is a logical addition and usually not more than an additional attribute. Now, does your parcel/zoning viewer app need 20+ additional map services, a TOC to manage them all along with multiple toolbars with map navigation tools that 99% of your users will ignore and probably not understand? I hope the answer is a resounding no.

Other features like measuring and geocoding have a place (especially geocoding, most people expect to be able to enter an address and have the map go there) and can usually be included in a simple, easy-to-understand way. I think you run into trouble (and usability issues) when you start adding toolbars and duplicating functionality in your app.

Redlining is a different animal as I think it means different things to different people. On the whole, if you're asking people to annotate and/or edit maps/data, I would make that a separate app. Use a simplified, read-only app for public consumption and a more fully-featured (but still not an ArcMap clone!) for things like editing and making custom maps.

Re: Building a modular application

JeffPace — Wed, 25 Apr 2012 19:14:40 GMT

I hear ya. What I'm trying to say is that there's a sweet spot: can (should?) a parcel viewer also show zoning info? Yes, of course. Zoning is a logical addition and usually not more than an additional attribute. Now, does your parcel/zoning viewer app need 20+ additional map services, a TOC to manage them all along with multiple toolbars with map navigation tools that 99% of your users will ignore and probably not understand? I hope the answer is a resounding no.

Other features like measuring and geocoding have a place (especially geocoding, most people expect to be able to enter an address and have the map go there) and can usually be included in a simple, easy-to-understand way. I think you run into trouble (and usability issues) when you start adding toolbars and duplicating functionality in your app.

Redlining is a different animal as I think it means different things to different people. On the whole, if you're asking people to annotate and/or edit maps/data, I would make that a separate app. Use a simplified, read-only app for public consumption and a more fully-featured (but still not an ArcMap clone!) for things like editing and making custom maps.

Totally agree. We ended up with the all in one app, but with config files to determine what layers/widgets load. (?type=landdevelopment). That way its one app to maintain, limitless config options.

So on land development, you get zoning, etc
and on utilities you get trash pickup.

Also means only one interface to learn/teach, but with customizable options.

Re: Building a modular application

JohnnyPenet — Mon, 21 May 2012 13:17:25 GMT

The idea was not to create a general application, but creating a general GIS JavaScript library that endorse the ArcGis JavaScript API, hiding some of the async functionality, making the job easier for doing application development. I agree that in most cases you have to make a more restricted application. What I am here is doing, is creating an application that can be used for testing the different aspects of the ArcGis JavaScript API and how far you can go with this in web editing.

Having such a tool, as a developer I no longer need a desktop license for simple consulting of data or creating some simple features.

I'm happy to hear that you're moving to using the ArcGIS API for JavaScript but I'd like to discourage you from trying to duplicate ArcMap in a browser. Web apps should not strive to duplicate heavyweight desktop clients, even if your goal is a light version. I would instead encourage you to build focused, targeted apps with a specific use in mind. Try to build apps that answers a specific question or addresses a specific problem rather than building something that is a tool for general analysis.