I had been using almost the same, just with more separated, and readable data:


var config = {
MSG: {
invalid_value: "Invalid value",
enter_text: "Please enter text"
},
URLS: {
login: "/user/login",
register: "/user/register"
},
CSS: {
selected: "sel",
error: "error"
}

}


to use:


alert(config.MSG.ivalid_value);


I think it’s more readable than using underscore separators.

ksgy on December 20th, 2011 at 8:26 am

I certainly agree that your configuration data shouldn’t be sprinkled throughout the code, but I don’t think that this approach will work in a large scale JavaScript application, which may have 100s of KLOCs, and potentially thousands of configurations.

I tend to use a single, central localisation system for messages and strings displayed to the user (MooTools’ “Locale” class is great for this), as I find (as you note!) that strings change the most frequently. The remaining configuration of each widget/class/module/item/whatever I keep in class (or widget etc.) itself. Using a system like MooTools’ Class options means that these configurations can change depending on context, and that their flow is clear.

All that being said, we run Java on the server, and I still haven’t come up with a reasonable and compatible solution for the Java side of things.

barryvan on December 20th, 2011 at 4:07 pm

@Julien – I thought about using NodeJS. However, several things prevented me from pursuing that. First, I’d have to write a Java properties parser, which I had no interest in doing. Second, Java is still far more ubiquitous than NodeJS. Being able to package up a JAR file and give it to someone is easier than guiding them through NodeJS setup, then npm setup.

Nicholas C. Zakas on December 21st, 2011 at 8:23 am

@ncz: Yes, I think we’re on the same page! I think that the difference is that where you might use a prefix (like “MSG_”), I’d prefer some way to use nested JS objects, particularly for localised strings. The difficulty, of course, is that Java .properties files don’t support nesting. Perhaps this could be an enhancement for props2js: the ability to take a .properties file like this:

primary_alpha_one = A
primary_alpha_two = B
primary_beta = C
secondary_alpha_four = D

and turns it into

{
primary: {
alpha: {
one: 'A',
two: 'B'
},
beta: C
},
secondary: {
alpha: {
four: 'D'
}
}
}

Of course, adding js2props would then become extremely handy, and somewhat less trivial. I’ll try to have a bit more of a think about it after the Christmas break. I’m half-tempted to consider an intermediary format that can be used at build time to produce both the client and server portions, excluding values as appropriate. Hmm…

I suppose that part of the problem is where you should draw the line. Should any value (URL, CSS class) be stored in a common area if it’s used more than twice? Thrice? Maybe just once? It’s not an easy predicament from which to extricate oneself: on the one hand, it’s very easy to end up tangled in an ad-hoc nightmare; on the other, it’s also easy to end up in configuration (cf. abstraction) hell. Sigh — I wish there were a panacea for these problems!

(I realise you have a lot of experience with large-scale web-apps. Apologies if I inferred that you didn’t — it certainly wasn’t my intention!)

@Oren: I think that the goal of this project isn’t to provide you with a single place to store each module’s configuration. Even when you’re using a modular structure, there are pieces that are common to the majority of modules: things like the string “OK” or “Cancel” (localised), for example. Taking the CSS example from Nicholas’s post, your modules could be built to either use the value of CSS_SELECTED if both the config object and that value are available, or use its own if not. That way, your modules remain self-contained, but have the ability to function more consistently within the application as a whole.

barryvan on December 21st, 2011 at 5:06 pm

Your solution is interesting, but I belilve it might be done better.

e.g:
var config={“MSG_INVALID_VALUE”:”Invalid value”,”URL_INVALID”:”/errors/invalid.php”,
“CSS_SELECTED”:”selected”};

`config’ is object variable so it might be changed.

What if you use something like this:

function CONST(key)
{
var config={“MSG_INVALID_VALUE”:”Invalid value”,”URL_INVALID”:”/errors/invalid.php”,
“CSS_SELECTED”:”selected”};

return config[key];
}

alert(CONST(‘MSG_INVALID_VALUE’));

I this case we’ve got realy readonly values.

advantages:
+ _readonly values_ which sound nearly like “const” [const-like variables]
+ self commented code [in fact your code was self commented as well]

disadvantage:
- object is defined every time we want to read a value – solution below:

var CONST = (function() {
var __c = {a : 1, b :2};
return function(key)
{
return__c[key];
}
})();

CONST(‘a’);

Patryk yarpo Jar on December 23rd, 2011 at 2:53 am

Thank you for sharing it. However, I have a question on extracting class names.

I personally think these class names ARE the APIs between DOM and JavaScript. Is it really necessary to abstract them out? Besides, if you have this configuration CSS_SELECTED = selected and later you are told that the class name should be active, then you end up with something like CSS_SELECTED = active. Now they are inconsistent, and it’s likely that when a developer really wants a selected class, she will use CSS_SELECTED without knowing the actually value now doesn’t correspond to the const name.

Another problem is naming. When the number of class names that need to be abstracted grows large, you will have a long list of const names like “globalNav”, “featureHeading”, “footerCopyright”, etc. Now you have to be careful about name collision. and things start to get ugly with this name soup.

I’ve done things like that before and I just gave up. Would like to know how you will approach it.

Gavin Huang on December 23rd, 2011 at 7:29 pm

@Julien Lecomte
“especially now that it is available on Windows”

Absolutely not a deal-breaker.

Sammy on December 26th, 2011 at 12:15 pm