What do you think is the best naming convensions for ActionMethodSelector to differentiate from ActionFilter (Attributes).
I need an ActionMethodSelector that does the same as the AuthorizeAttribute-ActionFilter does, but how would you name that ActionMethodSelectorAttribue? (The implementation is not the issue)
When in doubt follow the framework conventions, if you look at some of their implementations you will see in both cases they simply use an Attribute suffix.
AcceptVerbsAttribute : ActionMethodSelectorAttribute
etc.
and
OutputCacheAttribute : ActionFilterAttribute
etc.
If you have no problem using framework attributes in this way, I don't see any reason you should do anything different for your own code.
Unless you want of course :D
What do you think is the best naming convensions for
ActionMethodSelector to differentiate from ActionFilter (Attributes).
The suffix:
XXXActionMethodSelector
XXXAttribute or XXXActionFilterAttribute
where XXX is obviously the function those classes are supposed to accomplish.
XXXXSelectionAttribute
VS
XXXXFilterAttribute
It really doesn't matter, as long as you are consistent with your implementation, and the prefix or suffix adds a clear picture to its intention.
IMHO.
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
Do anyone knows about the class which has the common function which we generally use while developing web application. I have no idea what you may call it, it may be the utility class or common function class. Just for reference, this class can have some common function like:
Generate Random number
Get the file path
Get the concatinated string
To check the string null or empty
Find controls
The idea is to have the collection of function which we generally use while developing asp.net application.
No idea what you are really asking, but there already are ready-made methods for the tasks you write in various library classes:
Random.Next() or RNGCryptoServiceProvider.GetBytes()
Path.GetDirectoryName()
String.Concat() or simply x + y
String.IsNullOrEmpty()
Control.FindControl()
Gotta love the intarwebs - An endless stream of people eager to criticize your style while completely failing to address the obvious "toy" question. ;)
Chris, you want to inherit all your individual page classes from a common base class, which itself inherits from Page. That will let you put all your shared functionality in a single place, without needing to duplicate it in every page.
In your example it looks like utility class - it is set of static functions.
But I think that you should group it in few different classes rather than put all methods in one class - you shouldn't mix UI functions(6) with string functions(3,4), IO functions (2) and math(1).
As Mormegil said - those functions exists in framework, but if you want to create your own implementations then I think that for part of your function the best solution is to create extension method.
I used dotfuscator to protect my source code and I disabled renaming(to keep public methods and class names correct) but I noticed when I used reflector to see the assemblies after encryption that they didn't changed a lot. I still can see the source code.
Any information?
You can specify finely what will be excluded from the renaming phase by using a Obfuscation attribute. For example on a property:
[Obfuscation(Feature = "renaming", Exclude = true)]
public int MyProperty
{
get { return this.prop; }
}
If you disable renaming that means that none of the symbols (methods, types, etc) in your assembly will be renamed, that mitigates much of the usefulness of obfuscation.
If you just want to preserve the names of your publicly accessible methods instead of disabling renaming turn on library mode for each of the assemblies whose public methods you want to exclude from renaming.
In addition, renaming on its own will not cause Reflector to not show decompiled source. In order to break the decompilation you need to be sure to have Control Flow obfuscation enabled as well.
dotfuscator only obfuscate your code, it doesn't hide it completely from prying eyes.
If you really want "hide" the method body from Reflector, I suggest you to use Clisecure. Clisecure can make the logic body disappear while maintaining all the method name.
Do you have an option to obfuscate the logic? You should use that; it will make your logic harder to understand.
Here's a wierd one. I'm reusing a code base that unfortunately must not be updated. This code makes a call to HttpContext.Current.Request.QueryString. Ideally, I need to push a value into this collection with every request that is made. Is this possible - perhaps in an HTTP Module?
Without using reflection, the simplest way to do it would be to use the RewritePath function on the current HttpContext object in order to modify the querystring.
Using an IHttpModule, it might look something like:
context.RewritePath(context.Request.Path, context.Request.PathInfo, newQueryStringHere!);
Hope this helps!
Ditto Espo's answer and I would like to add that usually in medium trust (specific to many shared hostings) you will not have access to reflection so ... RewritePath will remain your probably only choice.