I'm in need for some advice on general application design and practices. My main concern is to find a viable, consistent architecture that won't lead to clutter and will ease separation, modularity and maintenance.
Not being to eager to reinvent the wheel, and not having enough experience with dojo on this scale to make an informed decision myself I would like your input on the matter.
I'm in the planning stage of a major project that involves using dojo to create a new frontend for an advanced CMS tool. All the data exchange will use dojo.rpc and dojo.data except where files are involved obviously. The majority of the tasks performed by dojo will be simple data selection (from tree or grid) and editing by form widgets, so the problem is not the complexity of the tasks themselves, but rather the sheer amount of different modules and views.
What are the major approaches to application design with dojo?
Are there some proven "best practices"?
What are the major pitfalls?
How do I structure my code to avoid "function hell"? Object trees?
What are the best methods to handle scope and closure issues?
Basically, what are the main approaches and what are the criteria for deciding which one fits a specific project?
We're using Dojo in a very
We're using Dojo in a very large application and one problem that I'm currently suffering with is the file layout structure. We thought we were being smart by separating our code into many modules and having them deployed separately but this doesn't work well with the build system.
For performance reasons, you will want to bake your files into a build but there are a lot of limitations if you do not use a simple file structure that is a sibling to the dojo folder.
So my advice is don't try to get too fancy and don't leave creating builds to the end of your dev cycle.
Just to note: in theory,
Just to note: in theory, your dev environment and deployment environment don't explicitly need to be siblings. It is, of course, the most transparent and easiest to do because no "dojo.registerModulePath" call is required. Though you could very well simply shift your files into the build's sights (sibling) immedately before build, and move the optimized tree back (reverting back to registerModulePath) ...
dojo.registerModulePath("custom","../../../../../../custom/code/location") assuming your webserver has paths that deep. It has to be relative to dojo.js folder. More trouble than it's worth to me, but I can see the value in easing the usecase of ../../custom namespace build.
Clarification
I'm so glad I asked - the packaging system and eventual troubles arising from it were totally under my radar. I will take these things into consideration.
I would be very interested in how you have approached simple thing like project layout - of course this depends on the cosen method to.
Do you do everything programatically or do you use and include html files with dojo tags?
How do you keep track of resources - one big nested object that contain references to all global resources (rpc classes, data objects etc) or do you extend classes and tacke these on where needed?