Config of Java class goes to XML. One of the most frequent complaints I get from Java devs is that they work with XML half the time, not Java.
I mean, separating this probably has justifications. But for me it's much easier to keep files in a config.js and export the config, like George explained. Then again, I'm not working in large teams so this might not work for others. 2014-02-06 11:32 GMT+01:00 Gagle <gagle...@gmail.com>: > Would you store configuration data in a .java class? This is the same case. > > http://stackoverflow.com/questions/18255226/storing-configuration-data-json > > Use yaml, properties, ini, xml or your own format, but please, don't use > json or javascript files... People like comments. If I remember correctly, > someone said that json was choosen to save the metadata file (package.json) > because there were no good alternatives. > > El jueves, 6 de febrero de 2014 08:17:38 UTC+1, George Snelling escribió: > >> Alex, >> >> We just say >> >> config = require('./config.js') >> >> where config.js exports a plain old javascript object. >> >> I think this solves both beefs you have with json: comments and trailing >> commas. >> >> Admittedly this approach suffers the keyword problem: if you name any of >> your config keys javascript reserved words you may die a puzzling death. >> By convention we don't do that. >> >> Perhaps yaml is more elegant and powerful, but exporting plain old >> javascript objects for config works fine for us. >> >> Regards, >> >> -George >> >> On Wednesday, February 5, 2014 4:37:22 AM UTC-8, Alex Kocharin wrote: >>> >>> >>> 05.02.2014, 15:47, "zladuric" <zlad...@gmail.com>: >>> >>> >>> >>> On Tuesday, February 4, 2014 2:43:25 PM UTC+1, Alex Kocharin wrote: >>> >>> >>> 04.02.2014, 17:01, "Oleg Slobodskoi" <ole...@googlemail.com>: >>> >>> Am 04.02.2014 um 13:46 schrieb Alex Kocharin <al...@kocharin.ru>: >>> >>> 1. Why JSON? This format was created for data serialization, and isn't >>> suited for maintaining by humans. >>> >>> We could support cjson (https://github.com/kof/node-cjson) or yml ... >>> but I am not sure that json is an issue here. I personally had never a need >>> to use something more expressive in this case, but I am open for it. >>> >>> YAML of course. It's the most sensible general purpose format used for >>> config files (unless your tool is able to change that config on the fly in >>> which case the issue starts to be complicated). >>> >>> >>> >>> Out of curiosity, where can one get informed on these things? >>> >>> Personally, I prefer json over yml. That way I never leave JavaScript >>> way of thinking and encapsulating things. But I don't do all that much >>> configuration, it's generally customizing pregenerated config files. I >>> rarely produce packages, I mostly consume them. >>> >>> >>> If you prefer json over yaml syntax, switch to json5 instead. It solves >>> most of the json issues, keeping common syntax the same. I didn't mention >>> that because it's not yet a standard, but I hope it'll be soon. >>> >>> For config files there are exactly two issues with json: >>> >>> 1. doesn't support comments >>> 2. doesn't support trailing commas >>> >>> Here are a few examples I started to collect recently, you can see for >>> yourself: >>> https://github.com/rlidwka/yapm/blob/master/changes/ >>> package-yaml.md#a-few-examples-why-you-should-not-use-packagejson >>> >>> Apart from comments, there are quite a few quirks there. Did you know >>> that JSON is not a subset of javascript? It creates a handful of issues as >>> well. I love it how \t, \b and other escape characters are supported, but >>> \v don't. And as everyone knows already, JSON isn't extendible and doesn't >>> support dates. Remember escaping "\/" and that history of how ASP packed >>> Dates? That was funny indeed. >>> >>> There are good parts in there too. For example, LDJSON is generally a >>> very good idea, and used wisely. >>> >>> YAML has its share of issues of course. It doesn't support tabs for >>> indentation (pretty stupid decision imho), has no block comments, and it's >>> hard to update it from an application without changing it's formatting. >>> >>> There is no ideal data format you know. Each one of them is used for >>> different things. JSON is good for what it does (it's client-server data >>> exchange). But unfortunately it's too easy to use (how do you like that you >>> can do require('./something.json'), but require('./something.yaml') is >>> officially deprecated?), so people misuse it quite widely. :( >>> >>> >>> >>> >>> -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to a topic in the > Google Groups "nodejs" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/nodejs/qnBP3jF7Phg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > nodejs+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- Zlatko -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
