I have review multiple instructions on URL-parameters which all suggest 2 approaches:
Parameters can follow / forward slashes or be specified by parameter name and then by parameter value. so either:
1) http://numbersapi.com/42
or
2) http://numbersapi.com/random?min=10&max=20
For the 2nd one, I provide parameter name and then parameter value by using the ?. I also provide multiple parameters using ampersand.
Now I have see the request below which works fine but does not fit into the rules above:
http://numbersapi.com/42?json
I understand that the requests sets 42 as a parameter but why is the ? not followed by the parameter name and just by the value. Also the ? seems to be used as an ampersand???
From Wikipedia:
Every HTTP URL conforms to the syntax of a generic URI. The URI generic syntax consists of a hierarchical sequence of five components:
URI = scheme:[//authority]path[?query][#fragment]
where the authority component divides into three subcomponents:
authority = [userinfo#]host[:port]
This is represented in a syntax diagram as:
As you can see, the ? ends the path part of the URL and starts the query part.
The query part is usually a &-separated string of name=value pairs, but it doesn't have to be, so json is a valid value for the query part.
Or, as the Wikipedia articles says it:
An optional query component preceded by a question mark (?), containing a query string of non-hierarchical data. Its syntax is not well defined, but by convention is most often a sequence of attribute–value pairs separated by a delimiter.
It is also fairly common for request processors to treat a name=value pair that is missing the = sign, as if the it was name=.
E.g. if you're writing Servlet code and call servletRequest.getParameter("json"), it would return an empty string ("") for that last URL in the question.
I got some trouble with my bindings using dbms_sql. The user creates the statement and give it to may function as well as the bindings and their values. That means I know about nothing of the statement. An input could be
select salary from employee where name like '%:name%'
This raises an ORA-01006. This post leads me to the reason: the binding is within single quotes so they are treated as a literal, not a binding.
I wrote some code to adjust the statement. But it works only for the given example ('%<binding>%'). Is there any way (maybe using regex) to solve it for all bindings within quotes?
So if input is like '<any pre content><binding><any post content>' it should be modified to '<any precontent>''||<binding>||''<any post content>' (hope that clears my wishes).
I'm not good in using regex so my solution for the example is very unflexible:
l_sql := replace(l_sql, '%:'||p_name||'%', '%''||:'||p_name||'||''%');
BTW: I'm using Oracle 11g.
According to the class file format used by the JVM, may a field or method legally have the empty string as its "unqualified name"? The only real restriction I can find in the relevant section is:
An unqualified name must not contain any of the ASCII characters . ; [ / (that is, period or semicolon or left square bracket or forward slash).
But I'm still having trouble believing this wouldn't cause issues somewhere else. Is the empty string really valid as a field/method name?
NO. JVMS SE 8 §4.2.2:
An unqualified name must contain at least one Unicode code point
JVMS SE 7 did not have this note.
I am writing some Velocity Script as part of a Marketo email template that requires that I check if an boolean attribute on a lead is set or not.
When I attempt to display something associated with a lead in my system I can do something like;
{{lead.myName}}
This also works for fields that have spaces in them;
{{lead.my name}}
When it comes to using that field for #setting or #ifing something then it doesn't work as well.
#if($lead.my name) throws an error saying that an unexpected space has been found.
I have tried variants like #if(${lead.my name}) to no avail.
Any help / pointers would be massively helpful.
Actual use case
In my example the field I need to access is called lead.Subscribed to Innovation (L) 1, I don't think the brackets will cause a problem, certainly any error messages have been space related.
According to User Guide variables cannot have spaces
A VTL Identifier must start with an alphabetic character (a .. z or A .. Z). The rest of the characters are limited to the following types of characters:
alphabetic (a .. z, A .. Z)
numeric (0 .. 9)
hyphen ("-")
underscore ("_")
even with the curly brackets :
this is valid:
#set( ${myemail} = "email#email.com" )
while trhis is invalid:
#set( ${my email} = "email#email.com" )
My best guess will be to change the source system to comply with the velocity naming convention.
This question already has answers here:
Is there any language that allows spaces in its variable names [closed]
(2 answers)
Closed 9 years ago.
Related: Why can't variable names start with numbers?
Is there a technical reason why spaces aren't allowed in variable names or is it down to convention?
For example, what's stopping us from doing something like this?:
average score = sum of scores / number of scores
The only issue that comes to mind is keywords, but one could simply restrict the use of them in a variable name, and the lexer would be able to distinguish between part of a variable and a keyword.
There’s no fundamental reason, apart from the decisions of language designers and a history of single-token identifiers. Some languages in fact do allow multi-token identifiers: MultiMedia Fusion’s expression language, some Mac spreadsheet/notebook software whose name escapes me, and I’m sure of others. There are several considerations that make the problem nontrivial, though.
Presuming the language is free-form, you need a canonical representation, so that an identifier like account name is treated the same regardless of whitespace. A compiler would probably need to use some mangling convention to please a linker. Then you have to consider the effect of that on foreign exports—why C++ has the extern "C" linkage specifier to disable mangling.
Keywords are an issue, as you have seen. Most C-family languages have a lexical class of keywords distinct from identifiers, which are not context-sensitive. You cannot name a variable class in C++. This can be solved by disallowing keywords in multi-token identifiers:
if account age < 13 then child account = true;
Here, if and then cannot be part of an identifier, so there is no ambiguity with account age and child account. Alternatively, you can require punctuation everywhere:
if (account age < 13) {
child account = true;
}
The last option is to make keywords pervasively context-sensitive, leading to such monstrosities as:
IF IF = THEN THEN ELSE = THEN ELSE THEN = ELSE
The biggest issue is that juxtaposition is an extremely powerful syntactic construct, and you don’t want to occupy it lightly. Allowing multi-token identifiers prevents using juxtaposition for another purpose, such as function application or composition. Far better, I think, just to allow most nonwhitespace characters and thereby permit such identifiers as canonical-venomous-frobnicator. Still plenty readable but with fewer opportunities for ambiguity.
I think it is bacause the designers of the language have followed this convention.
I have searched on Google and found that while naming a variable this is a rule which is followed while naming a variable.
Some links are given below:-
SPSS notes
The following rules apply to variable names:
Variable names cannot contain spaces.
C Programming/Variables
Variable names by IBM
Java Variable Naming convention
Variable names are case-sensitive. A variable's name can be any legal
identifier — an unlimited-length sequence of Unicode letters and
digits, beginning with a letter, the dollar sign "$", or the
underscore character "". The convention, however, is to always begin
your variable names with a letter, not "$" or "". Additionally, the
dollar sign character, by convention, is never used at all. You may
find some situations where auto-generated names will contain the
dollar sign, but your variable names should always avoid using it. A
similar convention exists for the underscore character; while it's
technically legal to begin your variable's name with "_", this
practice is discouraged. White space is not permitted.
Wiki for Naming Convention
In all of the above links you will find that the designers have followed this naming convention for naming the variable.
Also check Is there any language that allows spaces in its variable names
This is forced from language designing.
Compiler needs to find out the meaning of words.
Compiler works on a "State Machine" method, and it needs to distinguish key words.
Maybe placing variable names in "[" and "]" give us some solution(like SQL).
But it will be harder to use it in coding...