I have a List<> as part of a users profile stroed in the web.config like so
<properties>
<clear/>
<add name="EditorUploads"
type="System.Collections.Generic.List`1[[System.String]]"/>
</properties>
Although this code works, I don't know why. I can't find any documentation on what the `1 means anywhere. Can anyone shed some light on this please? Thanks.
The ``1` is a different notation used for generic types.
The 1 indicates the number of generic type parameters.
I have seen this notation when writing stacktraces as strings as well. It seems to indicate the generic characters <> and the following type is the generic type, eg:
List<string>
To denote the number of Type parameters that follow.
Related
We have camelCase, PascalCase, snake_case, and kebab-case. Is there a name for dot.separated.case?
Maybe there isn't a name for it, maybe I can't properly word my question for Google, but I can't find anything for it.
The "dot case format" or "dot notation" is the common denotation here. The format often used in property files, resource-bundles or yaml-files.
It's basically a convention that makes it easier to see what properties are related.
For example:
person.title="Title"
person.surname="Surname"
person.job.description="Some description"
You can easily collect similar properties by filtering the prefix like 'person.' to only see the properties defined for a person.
The dot.case format is also used in maven to name properties. E.g:
${project.build.directory}
See also the maven pom properties
I have been using different forms of Mule's Expression language.
I couldn't figure out the difference between
#[flowVars.myVariable]
and
#[flowVars['myVariable']]
They both give the result when there is a variable. But why do they behave differently when the variable is not present?
Like if the variable being called is not available, then the first expression would result in a exception. Whereas the second expression just gives out a warning or prints out as is, if in a logger message.
Why is this difference?
Also when going through the documentation for Mule 3.6 I found that the second expression is not longer shown in the documentation.
Is the expression #[flowVars['myVariable']] being deprecated?
The difference comes from the way MVEL deals with these two different ways of accessing map entries.
#[flowVars['myVariable']] is equivalent to flowVars.get('myVariable'), which does not fail if the flowVars map does not contain the 'myVariable' entry,
#[flowVars.myVariable] treats the flowVars map as a virtual object, leading to an exception if the 'myVariable' entry is missing because in this case it doesn't resolve to a map get but instead to directly using an object member (either a field or a method), which must exist before being accessed.
I don't think #[flowVars['myVariable']] could be deprecated since it's a core feature provided by MVEL.
Reference: http://mvel.codehaus.org/MVEL+2.0+Property+Navigation#MVEL2.0PropertyNavigation-MapAccess
David has given a nice explanation around your question. To extend that explanation I would just like to add that you can use #[flowVars.?myVariable] to make your code null safe. This is equivalent to #[flowVars['myVariable']].
Regarding #[header:originalFilename], as David said this is not MEL. You can get a list of non-mel expressions which are commonly used in Mule applications in the following link.
http://www.mulesoft.org/documentation/display/current/Non-MEL+Expressions+Configuration+Reference
I have the following tag in a webservice xml response:
<text>"><&</text>
And this is reported in my characters method as "><&, but I need to be reported as it is ("><&).
I've set XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES to Boolean.FALSE, but it doesn't work.
Can anyone help me?
Thanks in advance.
Joan.
No, this is not possible with Woodstox. Handling of character entities, and pre-defined entities (lt, gt, amp, apos, quot) is automatic and is required of XML parsers.
There are some XML parsers that expose underlying raw buffer contents; I think xpp3 does that. You could try it instead. But none of Stax implementations that I know of supports such access, nor SAX parsers.
Here is a simple explanation of the problem. Keep in mind this isnt the real problem
Lets say in my language functions cannot return pointers and member vars cannot be references. Bison is complaining (with like 40 reduce/reduce problems) about not deducing if the type in type what is a function or member variable. I know it but its ridiculous to have >40 conflicts from this one line.
Class Name { ...
Type& func() {
Type* Var=0
Type What
How should i deal with this? should i use %glr-parser and set expect/expect-rr to a value? or should i use a Type that has everything and filter what is legal or not in code? It looks like my choices are have more conflicts/ambiguity VS writing more code to deal with it. I am not sure which is worse so i wonder if any of you guys had to deal with this.
You shouldn't try to express type constraints in the grammar. This was proven pretty conclusively by the Algol-68 fiasco documented by Wirth and others.
This question is a little silly, but sometimes it's tough to figure out how to name things correctly. The conversion will parse a config file into XML and vice versa. I want to call the program MyCompany.Config2Xml, but the program also needs to be able to "Xml2Config".
I propose: ConfigParser
In keeping with SqlDataReader, TextReader, XmlReader etc I'd just call it ConfigReader and ConfigWriter.
Or, you could just go the serialization approach and then not have to worry about naming conventions.
CC for short:
ConfigConverter ?
Rather than ConfigParser as proposed by jeffamaphone (+1 for nice username), make it a verb:
parse-config
This makes it read nicely in scripts:
if ! parse-config < config-file > config.xml; then
exit 1
fi
I think it helps a lot to think about the verbs (methods) you intend to use with the class and the role the class plays in the application.
In other words if you envision the operation to be {class}.Get() or {class}.Load() then ConfigParser might be a good choice.
If on the other hand you have a corresponding {Class}.Set() or {class}.Save() operation then something like ConfigManager would be a better choice, particularly if the class will be used to isolate the application from the persistence of its configuration.
If the role of the class is nothing more than part of a standalone application or a step in a longer running process then I would would lean more towards class and method pairs that are more like Convert.ToXml() Convert.ToConfig() or Translate.FromXml() Translate.FromConfig().
General term seems like it would be format convertor, or transformatter (by analogy with transcoder). In terms of the specific names you discuss, I think I'd go with ConfigConvertor.
DaTransmogrifier
UberConvertPlus
Xml2Config2Xml
ConfiguratorX
'XConTrans'
or simply 'Via'
ConfXmlSwitcher :P