I was wondering if you normally capitalise any letter in query strings, use dashes or underscores for variable names, or have any other query string naming convention. I cannot find any reference to it.
Edit: Since there seems to be no convention, are there any best practices or usual way to do it?
I don't recall actually ever seeing people use dashes in parameter names in the query string. That probably shoots it down as best practice.
I would personally avoid camel case because I don't want to get into case sensitivity/insensitivity issues.
That leaves underscores, which I find is commonly used.
There is no convention in this case at all. URLs (in .NET at least) are case insensitive anyway.
Related
I have this line of code before I create my entity manager:
breeze.NamingConvention.camelCase.setAsDefault();
and this query:
var query = entityQuery.from('vehicle')
.expand("engine, driveType")
.select("engine.friendlyEngineName, driveType.friendlyDrivetrain")
The data comes back like so:
driveType_FriendlyDriveTrain = "Rear Wheel"
engine_FriendlyEngineName = "6.2L V8"
Why are "FriendlyDriveTrain" and "FriendlyEngineName" PascalCase? This seems clearly wrong since I set camelCase before I created the EntityManager and the query. How do I make it so that the parts after the '_' are camelCase as well?
note: I made sure to remove any web api json formatting configurations so that breeze is the only one managing the translation.
edit: The weird thing is that this same query returns properties that are camelCase after the '_' when it hits the cache. So same query, two different results.
Please review the documentation on NamingConvention. If that doesn't clear it up, you can come back and ask a more specific question. Thanks.
Edit 2 Sept 2014 (morning)
Please also explain what you think Breeze should be doing with the "_" character. The Breeze convention treats it like any other identifier character (e.g., a-z,A-Z,0-9) and does nothing with it. It seems you want your convention to skip over leading underscores and lower the case of the first char thereafter if it is alpha. I think you also want to drop the underscores ... but I'm not sure.
That's cool. You can write your own NamingConvention that does what you want. And you can make it the default too. In fact, the noUnderscoreConvention shown on the NamingConvention documentation page is more than half way home for you.
I will say you threw me for a loop with your mix of periods and underscores in the select statement and returned data. I have no idea how you got the select to work or got that kind of result.
Edit 2 Sept 2014 (afternoon)
Ok ... I overlooked the fact that you are doing a projection!
The projection flattens dotted property path values (whether ComplexType or EntityType navigations). It creates projected property names for these "flattened properties" by using "_" as the separator character. Yes, it applies the applicable MetadataStore's naming convention to those "_" separated names and, yes, the Breeze camelCase convention doesn't do anything special with the underscore. So you get back flattened projection property names such as "engine_FriendlyEngineName".
You can call this a bug if you like. I don't. I don't because (a) it seems to me a matter of opinion as to what a camelCase convention should do in this situation; (b) it's been this way forever; and (c) I don't think it is important enough to risk breaking existing applications that might rely on the current behavior ... not when your remedy is so simple.
And that remedy is to write your own camelCase convention that handles these projected property names differently.
Please include it here when you write it so that others who share your perspective may benefit from it.
I'm not sure what you mean when you write: "this same query returns properties that are camelCase after the '_' when it hits the cache". What query is that? Not the one you wrote here.
Projection results don't "hit the cache" ... unless the projected property value is itself an entity ... and that is NOT the case here. What do you mean by "this same query". I await your response.
What are the naming conventions in Rascal? It seems that modules, but not intermediate paths, tends to be upper case, also variable names. Does it make a difference? What is the convention and the rationale behind it?
We are working towards the convention that:
identifiers for functions, variable names, constructors, fields names of tuples and constructors, start with lowercase and continue with camelCase.
user-defined types such as, alias, data, syntax, lexical non-terminals, start with uppercase and continue with CamelCase.
The rationale is that in Rascal syntax definitions we currently need a syntactic difference between type names and label names to prevent ambiguity, and we chose to have one with uppercase and the other with lowercase first letters. The above convention continues in that vain for the rest of the language for the sake of consistency, but is yet to be formalized.
A coworker is running JSLint on our code and fixing the issues that come up. One change he made was to go from this:
document.getElementById(control["value1"]);
to this:
document.getElementById(control.value1);
Is it JSLint's preference to use the dot notation over array brackets? My understanding from here is that the brackets are a bit more flexible, and I wondered what the best practices from the field were.
Best practice is to use . notation unless you actually need to pass a variable.
This looks more normal, and also allows the JITter to do more intelligent things.
I've recently been receiving a lot of first name only entries in a form. While maybe I should have had 2 separate first and last name fields this always seemed to me a bit much. But I would like to try and get a full name which basically can only be determined by having at least one space.
I came up with this, but I'm wondering if someone has a better and possibly simpler solution?
/([a-zA-ZàáâäãåèéêëìíîïòóôöõøùúûüÿýñçčšžÀÁÂÄÃÅÈÉÊËÌÍÎÏÒÓÔÖÕØÙÚÛÜŸÝÑßÇŒÆČŠŽ∂ð,.'-]{2,}) ([a-zA-ZàáâäãåèéêëìíîïòóôöõøùúûüÿýñçčšžÀÁÂÄÃÅÈÉÊËÌÍÎÏÒÓÔÖÕØÙÚÛÜŸÝÑßÇŒÆČŠŽ∂ð,.'-]{2,})/
This is basically this /([a-zA-Z,.'-]) ([a-zA-Z,.'-])/ plus unicode support.
I'd first make sure that you really do need people to give you a last name. Is that a genuine requirement? If not, I'd skip it because it adds unnecessary complication and barriers to entry. If it really IS a requirement, it probably makes sense to have separate first and last name fields in your UI so that it's explicit.
The fact that you didn't do that to begin with suggests that you might not really need the last name as much as you think you do.
To answer your original question, this expression might give you what you're looking for without the guesswork:
/[\w]+([\s]+[\w]+){1}+/
It checks that the string contains at least 2 words separated by whitespace. Like Tim Pietzcker pointed out, validating the words themselves is prone to error.
In Ruby 1.9, you have access to Unicode properties (\p{L} is a Unicode letter). But trying to validate a name in any way (regex or not) is prone to failure because names are not what you think they are.
Your theory that "if there's a space, there must be a last name there" is incorrect, too - think of first and middle names...
Is there any better alternative to this?
name.gsub('è','e').gsub('à','a').gsub('ò','o').gsub('ì','i').gsub('ù','u')
thanks
Use tr.
Maybe like string.tr('èàòìù', 'eaoiu').
substitutes = {'è'=>'e', 'à'=>'a', 'ò'=>'o', 'ì'=>'i', 'ù'=>'u'}
substitutes.each do |old, new|
name.gsub!(old, new)
end
Or you could use an extension of String such as this one to do it for you.
If you really want a full solution, try pulling the tables from Perl's Unidecode module. After translating those tables to Ruby, you'll want to loop over each character of the input, substituting the table's value for that character.
Taking a wild stab in the dark, but if you're trying to remove the accented characters because you're using a legacy text encoding format you should look at Iconv.
An introduction which is great on the subject: http://blog.grayproductions.net/articles/encoding_conversion_with_iconv
In case you are wondering the technical terms for what you want to do is Case Folding and possibly Unicode Normalization (and sometimes collation).
Here is a case folding configuration for ThinkingSphinx to give you an idea of how many characters you need to worry about.
If JRuby is an option, see the answer to my question:
How do I detect unicode characters in a Java string?
It deals with removing accents from letters, using a Normalizer. You could access that class from JRuby.