An outlet for my obsession with technology
development
My Dojo Design Pattern
Oct 3rd
This is how I take advantage of dojo when developing an application that uses the toolkit.
First, in the past few months most of the applications I developed have has sparse use of JS with one major exception. Each application has an main “application page” where a bulk of the action takes place.
My current project is a large mapping application similar to maps.google.com or maps.live.com. The application instantiates with a large map and a variety of tools that users can use to generate reports based on the underlying map data. There are ancillary pages for help, sitemap, contact, etc that do not require the amount of JS the map interface requires.
Separation
I create multiple JavaScript files, one XXXX.js and the other XXXX-app.js. The app.js file is only included on the application specific pages.
Note: during development I will create separate JavaScript files for major functionally but combine them before moving to production.
Includes
I try to only include the app.js on the application page.
Onload
1:
2: function init() {
3: app_name = new app_name();
4: app_name.postCreate();
5: }
6: dojo.addOnLoad(init);
app_name
dojo.declare is my friend..
1: dojo.declare("my_app", null, {
2: _date : '',
3: schedule_success : 'Scheduled',
4: store_dealer : null,
5:
6: constructor: function() {
7: },
8: postCreate: function(){
9: var page_body = dojo.query('body')[0];
10: switch(page_body.id){
11: case 'index':
12: this.index.init();
13: break
14: default:
15: console.log('default');
16: break;
17: }
18: },
19: index: {
20: init: function(){
21: dojo.connect(dojo.byId('dashboard'),'onclick',function(){ dijit.byId('tabs').selectChild('tab_dashboard'); });
22: dojo.connect(dojo.byId('export'),'onclick',function(){ dijit.byId('tabs').selectChild('tab_export'); });
23: }
24: }
25: });
ASP.NET naming conventions…yuck
Sep 9th
Typing the phrase “naming conventions” makes me feel ill. They have always been someone of an objective topic and a topic that has ALWAYS lead to intense debate. Well, I hope that my little foray into code analysis has lead me to stumble upon a clear concise description for ASP.NET naming conventions.
I ran the new release of FxCop against one of my projects today and came across a few, 1504 to be exact, messages about incorrect naming conventions. Ha!, Like there is a correct way to format your code…wait…what Microsoft thru the error…hmm…maybe someone should check the error description.
Update: The error log is from a clients project, I do not have control over naming standards with this particular client.
Type, namespace, and member identifiers are Pascal-cased.
Parameter identifiers are camel-cased.
Two letter acronyms within these identifiers should be upper-cased, for example, use System.IO instead of System.Io.
Acronyms of three or more letters should be Pascal-cased, for example, use System.Xml instead of System.XML.
The pascal-casing convention capitalizes the first letter of each word, as in BackColor.
The camel-casing convention formats the first letter of the first word in lowercase and capitalizes the first letter of all subsequent words, as in backgroundColor.
Although it may be common practice for some two letter acronyms to not be fully capitalized, violations of this rule should not be excluded for this reason. For example, ‘DbConnection’, is common but incorrect; use DBConnection.
A violation of this rule might be required for compatibility with existing, non-managed symbol schemes. In general, however, these symbols should not be visible outside the assembly that uses them.
