As per the documentation, the ResourceManagerWithCultureStringLocalizer class and WithCulture method were removed in .NET 5.0
https://learn.microsoft.com/en-us/dotnet/core/compatibility/aspnet-core/5.0/localization-members-removed
I need the ability to change the culture to send a bunch of emails, and can not rely on the applications culture.
Microsoft themselves do not offer any alternative for this. As per the documentation:
"Recommended action Stop using the ResourceManagerWithCultureStringLocalizer class and the ResourceManagerStringLocalizer.WithCulture method."
Pretty helpful.
What's the best approach here to change the culture programatically without changing the applications culture everytime?
My pseudo code is:
IStringLocalizer<MyResourceFile> _localizer;
_localizer.WithCulture(new CultureInfo(1111))["myString"]
Related
I'm trying to use T4MVC to create strongly typed links to WebApi endpoints, and while it does generate helpers for my ApiControllers, there's no method for creating links. The generated controllers have ViewNames, but no action methods. I guess this is because ApiController's don't return ActionResult's, but what do I need to be doing instead to create these links?
It is not supported today, but please check out this thread which has some good amount of discussion about it. Feel free to reply over there to add to it.
Still doesn't seem to be supported by the end of 2015.
If it's URL generation that you're concerned with, then take a look at Drum if you're using attribute routing in Web.API 2+. And if you've got routes set up in your application startup (Web.API 1) then it appears Hyperlinkr will be helpful.
If you need other things (like a hard-coded parameter list) then you're still out of luck.
Disclaimer: I've not used either
I am looking at the HDIV framework to implement it in my Grails application. Looks like the framework is more user friendly to Struts/java based applications. They do say it can be configured on other frameworks. This is what it exactly says:
It is possible to use HDIV in applications that don’t use Struts 1.x, Struts 2.x, Spring MVC or JSTL, but in this case it is necessary to modify the application (JSP pages).
I see that we need to modify the editable and non editable data being sent to the server (one of the strategies is to cypher code the hidden field and add a state parameter to link urls.)
And in the response we get back this data and use a validate() function to do integrity checks.
The sample grails-HDIV project on GITHUB is really basic with no details.
Has anyone implemented it on grails?
Thanks
Priyank
I've just written a plugin for this very thing. I'll see if my company will let me release it and if so I'll inform you.
Are there any classes (free, open source or commercial) that perform access control similar to what Java's AccessController does? I want to create a dynamic set of policies that can be changed at runtime.
But, I want to avoid having to code
if Allowed( ... ) then
all over the place. I know that I probably need to adjust my program class hierarchy, but I prefer that instead of manually adding guards all over the place.
If there are is no ready-to-use code, what would be a sensible approach? RTTI?
Edit: Here's an example from the Security Annotations and Authorization in GlassFish and the Java EE 5 SDK article. Since somebody mentioned annotations in a comment, I think this would be ideal:
#Stateless
#RolesAllowed("javaee")
public class HelloEJB implements Hello {
#PermitAll
public String hello(String msg) {
return "Hello, " + msg;
}
public String bye(String msg) {
return "Bye, " + msg;
}
}
From the article:
In this example, the hello() method is accessible by everyone, and the bye() method is accessible by users of role javaee.
Edit:
Well, it appears that the general consensus is that this can't be done in Delphi. Others think it is a bad approach.
Me, I still think this would be great. My experience with Annotations in Java (as a code monkey way down in the totem pole) is positive. You add a new method, you add some form of annotation (not exactly the same as Java Security Annotations) and you are done. An administrator can later go to the admin panel and add grant access to this new handler to a group or individual users. It just works.
These are my current alternatives:
The TMS Security System - this appears like a complete solution, with several tools. Worth looking into. I'm accepting this as an answer even if I'm probably not going for it.
This is something that looks promising: Delphi virtual method interception. It only works on virtual methods, but I don't think that's too difficult to comply. This and annotations could make an interesting system (it appears that this was originally designed for DataSnap authentication)
Having only one ActionManager in your application, and make sure that all actions can be only initiated from there. This way you can use the action manager OnExecute method; I pretend to use the TAction.Name property as the permission name ("handler"), reading a list of allowed actions from a table. I can use the action list from the action manager to display the whole list in the admin UI.
There is no such framework for Delphi yet, nor a concept like EJBs that would fit with it. DELPHI does support class annotations, and a framework like this could be designed, perhaps in conjunction with TAction, to provide security on an action level, but I doubt that this could be extended to blocking specific method calls. Delphi code does not ever ask permission to invoke a virtual method. Anything that injected itself into EVERY virtual method call in Delphi, adding a checkPermission call behind the scenes would (in my opinion) be evil. It would be Slow, and worse than writing such checks in by hand.
However, the same techniques that are used to Mock delphi classes could perhaps be used to create some auto-security wrapper object in the future.
I am guessing that the if the Java library in question used Aspects (essentially "injection" implemented via a technique like code-hooking) then it would not require "CheckAllowed" calls everywhere. If you didn't mind changing all your method invocations to implementing an interface, and then providing a wrapper that did the method invocations, and used some kind of auto-generated mock-security-wrapper around it, you could avoid calls to CheckAllowed.
So a guarded No, with a "limited framework possible in future" clause.
Yes, there is a Delphi Access Control Library (lkacl) (OpenSource), JCL (OpenSource) which offers a pretty comprehensive security features, and finally if your demands would be really high the most popular commercial solution is TMS Security System.
I asked this question over on the asp.net forums, and nobody seems to know what i'm talking about. I'm not sure why that is, but I figured I'll ask here to see if there is anyone with some insight.
Back when MVC2 was released, it included a sample AccountController that wrapped the built-in Membership and FormsAuthentication classes with testable interfaces and services. I read a lot about this, and it was considered a good thing because the Membership and FormsAuthentication classes were not easily testable.
Recently, I generated a new sample project with my up to date (SP1, MVC3, Tools Update, etc..) environment and I find that the AccountController is now much simpler. Gone are the Interfaces and MembershipService and FormsAuthenticationServices. The sample now calls the Membership and FormsAuthentication classes directly.
I'm wondering if anyone knows when this happened and why? Are the testable interfaces no longer considered correct? Was there a technical reason to change this?
The best I can figure is that this happened as a part of the change to remove a possible vulnerability when passing return url's on the open url.
Any insight?
The new model resembles EF's code first approach where the AccountModel is a POCO class. Inside the new API there are no longer abstractions but direct calls to static methods such as FormsAuthentication.SetAuthCookie making this code difficult to unit test. Not something I would recommend basing your real world application code upon.
And, yes, they have fixed a vulnerability inside the LogOn method which was not verifying if the return url is a relative url before redirecting.
Personally I would recommend you using abstractions in order to weaken the coupling between your controller logic and its dependencies. This will make the code easier to unit test.
For me passing all those domain models to views without using view models are total anti-patterns and I have never bothered with them. I simply create an empty project and do the things my way. I mean in the default project they even use ViewBag for Christ sake!
The Account Controller was changed with the MVC3 tools update (When they also included the use of jQuery via Nuget)
Delphi 8 introduced Class Helpers for the purposes of mapping the VCL/RTL to the .NET object hierarchy. They allow injecting methods into an existing class without overriding the the class or modifying the original. Later versions of Delphi found class helpers improved and they were ported to Win32.
In the help it says "they should not be viewed as a design tool to be used when developing new code."
Class Helpers violate traditional OOP, but I don't think that makes them a bad thing. Is this warning warranted?
Should class helpers be used when developing new code?
Do you use them when developing new code?
Why or why not?
Per Malcolm's comments: New code means daily application development, where you have some 3rd party libraries, some existing code, and then code you are writing.
Depends what you mean by "new code".
They aren't really relevant for classes you are newly developing, so in that case, no, they probably shouldn't be used.
But even in a brand new project, you may still need to modify an existing class that you can't change in other ways (vcl class, third-party class, etc). In this case, sure, I'd say go ahead.
They're not evil in and of themselves. Like most other things, you just need to understand how they work and use them in an appropriate context.
Before embracing class helpers as a new tool for fancy code, I think you have to understand the limitations is includes. There is only possible to provide one class helper for one class. So what will happen if you provide class helpers for your classes, and your classes derives from a common class that some other have provided a class helper for?
CodeGear introduces class helpers as 'a hack' to prevent breaking things, not as a cool design feature. When you design code, design it without class helpers. I know you can. When dealing with existing code that you can control, use refactoring. When there is no other way, reach for class helpers.
Thats my opinion any way...
Microsoft based LINQ heavily around their Extension Methods. In that light you should use Class Helpers in new code if that improves your code. See What are good uses for class helpers? for some good uses.
I use them a lot. I use Remote Objects and the objects there are created by the RO engine so you cannot add to them without descending from them and then other bits of messing around. Class Helpers mean I can treat them like any other object. and while a class can only have one helper, you can descend helper classes so you get the inherited behaviour.
Sorry, can't help but be Captain Obvious for a moment: If the internal Delphi people themselves state "they should not be viewed as a design tool to be used when developing new code" then by definition they shouldn't be used. They are there for extending the VCL for their own purposes only. Who else is going to give you a better reason than the people that wrote it?
I agree with Vegar in this: class helpers as a emergency tool. When you know they are the only way to get things done in the time provided. Later, if there's time to it, remove them.
I one time forgot a parametrization thing, and if class helpers didn't exist in Delphi 2006 it would cost A ENORMOUS LOT OF TIME..... With class helpers, it took 6 hours to make thigs work right. BUT, it was an emergency situation - class helpers are an obscure language feature and it create difficulties to new developers to follow the flow of the program.
Maybe a good aproach you can use is (as I use it):
Always give preference to inheritance over class helpers, use them only when inheritance is not an option.
Give preference to Class helpers over bare global methods.
If you're going to need the extendend functionality in more than a Unit, try something else (like class wrappers).
.Net Extensions methods are way too similar and where created and supported for the exactly same reason: Make an Extention of the base classes (rather than an upgrade wich in Delphi.Net was not an option in order to try to make Delphi native code kind of "compatible" with .Net code - IMHO this was too ambitious)
Anyway, Delphi Class helpers are still quite a tool in some situations.
These sound like C# extension methods. I would say that while extension methods like these are useful when you don't have the ability to modify a class that you need to extend with functionality, they are a poor way to design your own code. When designing your own code, you'd like all the functionality to be located in the same code file as much as possible rather than spread across different classes. I'd say use them for what they were intended for -- basically as decorators to add new functionality to closed classes -- and don't use them in designing your own code.
I find myself using them more and more as a design construct.
Situations in which I use them :
In a client/server setup, I extend shared base-classes with class helpers to provide server- or client-only functionality.
To complement VCL/RTL classes (and other third party code) with handy tooling functions.
To work around differences when classes don't share the same inheritance tree (using helpers makes it possible to have have generic Count and Items properties, for example).
In fact, I wish Delphi would accept multiple helpers for the same base class - I've even filed a request for this if I'm remembering correctly.
I found this article very interesting. It deals with C++ but the main ideas are language independent. The main gist is that global routines are sometimes preferrable to methods even in an OOP environment. From this view point, there's less need for class helpers.