I'm looking at the ado.net ef membership provider and notice they have something a little different to register the provider
type="OmidID.Web.Security.EFMembershipProvider`2[
[OmidID.Web.Security.Default.DefaultUser,
OmidID.Web.Security.EFMembershipProvider],
[System.Int64]], OmidID.Web.Security.EFMembershipProvider"
I've never seen the bits in square brackets before and took a look around and can't seem to find what they allude to, I'm guessing its setting the type of user but I'm not sure.
Is this configuration specified somewhere? what does it mean?
The type is Generic, the square brackets indicate what types the generic type should be used with. In this case the EFMembershipProvider class has 2 generic parameters that should have the types OmidID.Web.Security.Default.DefaultUser in the Assembly OmidID.Web.Security.EFMembershipProvider and System.Int64. The EFMembershipProvider class itself is in the Assembly OmidID.Web.Security.EFMembershipProvider.
See the MSDN documentation on GetType for more information on how to express generic type names as strings.
Related
I am trying to learn Servlet annotations and came across this snippet
#WebServlet(urlPatterns="/MyPattern", initParams={#WebInitParam(name="ccc", value="333")})
This makes sense to me. However, I don't understand why it is not like this
#WebServlet(urlPatterns="/MyPattern", initParams={(name="ccc", value="333"), (name="abc", value="1")})
So, the question is why we need to put #WebInitParam annotation when we already declared the attribute as initParams. It seems redundant to me, or am I missing something?
The alternative you suggest would not even compile.
When you look at the JLS, it states this:
It is a compile-time error if the return type of a method declared in
an annotation type is not one of the following: a primitive type,
String, Class, any parameterized invocation of Class, an enum type
(§8.9), an annotation type, or an array type (§10) whose element type
is one of the preceding types.
So in order to group name and value together, which represent the initialization parameter the only option is to use annotation (#WebInitParam in this case) with corresponding values set as its parameters.
As with most questions about language design choices we can only speculate here. I think some reasons for this are:
Keeping the language simple.
It is kind of redundant, but the syntax for annotations can be reused and does not require new language constructs. This makes it easier to parse and to read. Sure, It's longer, but it's also more explicit to write the annotation's name.
Don't restrict possible future language enhancements.
The proposed syntax would not work if annotations would support inheritance. I don't know if that's even a planned feature but it would not be possible to implement straightforward it if the type can be omitted.
In many cases an array of annotations seems like a workaround anyway. It can be avoided in Java 8, where you can add multiple annotations of the same type:
#WebServlet(urlPatterns="/MyPattern")
#WebInitParam(name="ccc", value="333")
#WebInitParam(name="abc", value="1")
(I don't know if the servlet api actually supports this yet though)
I'm trying to standardise the way I name things, but as a newbie I always seem to come up with an issue somewhere further down the line.
Case in point - I have a user control and enum that clash. The UC is very specific and contains a form dropdownlist/validation for customer input - the name relates to the type of input so the class is named EmploymentStatus.
However, the dropdownlist is populated via an enum - ideally this would be called EmploymentStatus too as I've adopted the recommended singular form for enums.
No doubt everyone has come across this issue at some point, but what is a good solution?
I think namespaces would be the way to go here. Just put the enum in a separate namespace then refer to fully qualified e.g.
MyCompany.MyApplication.AnotherNamespacePart.EmploymentStatus
If this is a bit verbose then you can use namespace aliases to make things a bit more readable.
using myEnum = MyCompany.MyApplication.AnotherNamespacePart;
... some code
myEnum.EmploymentStatus
Please note I've assumed C# here but the principle will hold for other asp.net languages
In my humble opinion and all that
At a high level, how do these dep. injection frameworks work?
I can understand if you always instantiate an object via a custom factory like:
IUser user = DepInjector.Get<User>();
I'm guessing what happens is, wherever you defined the mappings, it will look at the type you want and try and find a match, if found, it will via reflection instantiate the type.
Are there dep. inj. frameworks that would work like:
IUser user = new User();
If so, how would it get the correct user, where is it hooking into the CLR to do this? In case of an asp.net website, is it any different?
If you want to know how Ninject works then the obvious place to start would be reading How Injection Works on their official wiki. It does use reflection but it now also uses dynamic methods:
"By default, the StandardKernel will
create dynamic methods (via
System.Reflection.Emit.DynamicMethod)
that can be used to inject values into
the different injection targets. These
dynamic methods are then triggered via
delegate calls."
As for you second example, I don't believe there are any DI frameworks that would do what you ask. However, constructor injection tends to be most common way of implementing IoC, so that when a class is constructed it knows what type to bind to via some configuration binding. So in your example IUser would be mapped to concrete User in config bindings so that any consuming class that has an IUser parameter as part of its constructor would get the correct User type passed in.
AFAIK there's no way to "hook into" object instantiation with the CLR. The only way to use DI in the second case would be to employ an assembly rewriter (i.e. a postprocessor similar to PostSharp) to replace the call to new with a call to the DI factory method (i.e. GetUser) in the compiled code.
I have a ASP.NET web service. This web service works fine. However, the WSDL lists some parameters as optional (minoccurs = 0) and others as non-optional. Some of the optional parameters are actually not optional, others which are marked as non-optional are actually optional. I would like to fix this, but I can't find the location where this information is coming from.
It seems to me that all primitive types (int, boolean etc.) are non-optional and all other parameters are marked as optional. However, I can't find a location where I can change this. I would like to specify default values for the primitive values if they are missing in the request and specify which non-primitive parameter is actually optional. Where do I do this?
I am assuming that when you say ASP.net web services, you are creating web services with ASMX extension. I think that what happens in this case is that all nullable types become optional and non-nullable become non-optional.
You could perhaps manually edit the generated WSDL file. But then you would have to redo that work if the wsdl was regenerated.
I would suggest that you switch to WCF with basisHttpBinding (except for the name of you service your clients should not notice the difference).
Using WCF you can simply mark the parameter in the data contract as required or not:
[DataMember(IsRequired="false")]
The primitives are not reference types, but rather they are value types. You can make a value type "nullable" a couple ways.
The short-hand is
int? i;
or long-hand here
Nullable<int> i;
Following up from my last question does anyone know how I can use a dictionary object in application scope in Classic ASP? You cannot use Scripting.Dictionary - if you try you will see something similar to the following:
Application object error 'ASP 0197 : 80004005'
Disallowed object use /xxx.asp, line 2. Cannot add object with apartment model behavior to the application intrinsic object.
I found this article on (good ol') 4GuysFromRolla but it points to Microsoft's free Lookup Component and a free Dictionary Component from Caprock Consulting - both of which are dead links.
The article clearly explains why you can't use the Scripting.Dictionary in application scope, but I was wondering if anyone knew of a free alternative or where I might find a copy of the old components that 4GuysFromRolla mentioned?
I was able to download the Dictionary Component from Caprock Consulting using this link: http://web.archive.org/web/20000619122506/http://www.caprockconsulting.com/data/CaprockDCT.zip
I have the LookupTable-component and can provide it to you if interested.
However, I have notived that you can use .NET HashTable in application-scope which might be useful for you.
just do this:
<object id="YOUR_VAR_NAME" progid="System.Collections.HashTable" runat="Server" scope="Application"></object>
this will give you a global, application-wide HashTable-object.
Beware of modifying this to heavily though, I have problems with memoryleaks where eventually the applications session-handling gets unreliable (doesn't invoke SessionStart properly)
i had the same issue and ended up feeding the application variable with the content of my dictionary and added
for each obj in application.Contents
if Left(obj,6) = "urlLog" then
application.Contents.Remove(obj)
end if
next
to kill all the application variables in the global.asa on application.end ( you could also use the Application.Contents.RemoveAll but i heard there was som issue with it leaving some variable up and causing memory leak even tho i could net find any solid source to prove it ...
anyway is the Caprock dictionary working for you ?