Building a modular application

[HenryColomb]

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

[derekswingley1]

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.

[JeffPace]

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.

[JohnnyPenet]

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.