I wrote a small REST server with the REST datasnap in delphi XE2.
There is a default mapping between HTTP methods (POST, PUT etc.) and the functions defined in delphi, this is done by a delphi component.
This wiki entry describes the URI mapping but also notes that the default mapping can be override by the programmer.
The mapping pattern can be overridden. The user can override the mapping for each type based on class name and method name parameters.
But I didn't find any explanation how to override the mapping.
How can I change the default mapping?
The TDSHTTPService component has events where you can specify the mapping for each type. These events are called RESTMethodNameMapDELETE, RESTMethodNameMapGET, RESTMethodNameMapPOST and RESTMethodNameMapPUT.
This is also explained in the white paper on REST by Marco Cantù, which explains a lot about REST and Datasnap.
I was wondering the same thing, and did some experiments. It seems to be at least partially possible to control the url. Specifically I tried changing the class name part of the url.
Essentially if you are using a TComponent decendant you can name the class anything. This doesn't work if you decend from TDataModule though. In this case you can create and alias class which you can name what you want which decends from your TDataModule.
You need to do some cleanup in the client binding when trying to bind to this, but it seems to work, at least for simple tests.
See more on the Embarcadero forums.
https://forums.embarcadero.com/thread.jspa?threadID=77624&tstart=0
Related
To set a ServletResponse ContentType you can, for example, implement this ServletResponse.setContentType('text/plain') or ServletResponse.setContentType('text/html') for HTML. But this statement should be replaced by using the ESAPI library like ESAPI.httpUtilities.setContentType() to address potential vulnerability. According to the org.owasp.esapi APIs document (as I understood), the org.owasp.esapi Interface HTTPUtilities setContentType() doesn't allow you to switch from 'text/plain' to 'text/html' programmatically. Is there an ESAPI example or tutorial to show me how to use the ESAPI.httpUtilities.setCurrentHTTP() to change the content type from 'text/plain' to'text/html' programmatically?
Looks like the answer to this is no:
The reference implementation doesn't allow for programmatic access, it's hard-coded:
https://github.com/ESAPI/esapi-java-legacy/blob/develop/sac/main/java/org/owasp/esapi/reference/DefaultHTTPUtilities.java
The "setContentType" method is programmed only to pull the property
value defined in esapi.properties:
Using UTF-8 throughout your stack is highly recommended. That
includes your database driver,
container, and any other technologies you may be using. Failure to do this may expose you
to Unicode transcoding injection attacks. Use of UTF-8 does not hinder internationalization.
HttpUtilities.ResponseContentType=text/html; charset=UTF-8
If you want to add that capability you can submit a pull request with your changes at github, or you can write your own one-off for your organization. I'm not a big fan that the original owners hardcoded this, but that part of the library was written back in 2007.
To do what you want to do, you would have to subclass the reference implementation DefaultHTTPUtilities to add a setContentType(String headerValue) method. You'd then need to configure ESAPI to use that class instead by changing the 'ESAPI.HTTPUtilities' property in your ESAPI.properties class to reference your custom class.
Furthermore, calling ESAPI.httpUtilities.setContentType() is probably overrated unless you have customized an ESAPI Authenticator interface and are using that custom implementation. (The reference implementation for it is just a toy example.) Then you would to call Authenticator.login() to get much of a benefit from calling ESAPI.httpUtilities.setContentType(value). Of course, you'd have to change the HttpUtilities interface as well to add a new method that takes a header value.
As to whether there is any decent documentation on this? Probably not, at least not that I'm aware of.
For instance I have this bit of code
public class ProductService{
private IProductDataSource _dataSource = DependencyManager.Get<IProductDataSource>();
public Product Get(int id){
return _dataSource.Select(id);
}
}
I have 2 different data source:
XML file which contains the informations only in 1 language,
a SQL data base which contains the informations in many languages.
So I created 2 implementation for IProductDataSource, for for each kind of datasource.
But how do I send the required language to the SQL data source ?
I add the parameter "language" to the method "IProductDataSource.Select" even if I won't use it in the case of the XML implementation.
Inside the SQL implementation I get the language from a global state ?
I add the language to the constructor of my SQL implementation, but then I won't use my DependencyManager and handle my self the dependency injection.
Maybe my first solution is not good.
The third option is the way to go. Inject the language configuration to your SQL implementation. Also get rid of your DependencyManager ServiceLocator and use constructor injection instead.
If your application needs to work with multiple languages in a single instance I think point one is a sensible approach. If the underlying data does not provide translations for a request language then return null. There is another solution in this scenario. I'm assuming that what you have is a list of products and language translations for each product. Can you refactor your model so that you do not need to specify or asertain the langauge until you reference language specific text? The point being a product is a product regardless of the language you choose to describe it. i.e. one product instance per product, only the product id on the Datasource.Select(..) method and some other abstraction mechanism to deal with accessing the correct text translation.
If however each instance of your application is only concerned with one language set I second Mr Gloor.
First of all I need to point out that you are NOT injecting any dependencies with your example - you are depending on a service locator (DependencyManager) to get them for you. Dependency injection, simply put, is when your classes are unaware of who provides the dependencies, e.g. using a constructor, a setter, a method. As it was already mentioned in the other answers, Service locator is an anti-pattern and should be avoided. The reasons are described in this great article.
Another thing is that the settings you are mentioning, such as language or currency, seem to be localization related and would probably be better dealt with using the built-in mechanisms of your language of choice (e.g. resource files, etc).
Now, having said that, depending on how the rest of your code is structured you have several options to solve this while still using Service locator:
You could have SqlDataSource depend on some ILanguageProvider which pulls the current language from somewhere. However, with more settings like these (or if it is difficult to get current language in an isolated way) this can get messy very fast.
You could depend on IProductDataSourceFactory instead (or, if you are using C#, Func<IProductDataSource>) which would return the concrete implementation with the correct settings. Again, you need to be able to get the current language in an isolated way in order to use this.
You could go with option 1 in your question. This would be a leaky abstraction but would be the simplest to implement.
However, if you decide to get rid of service locator and start using some DI container, the best solution would be using option 3 (as it was already stated) and configuring container accordingly to provide the correct value. Some good ideas of how to do this in an elegant way can be found in the answer to this question
I am putting together a built-in script capability using the excellent Pascal DWScript. I have also add my own Delphi-side class definition (TDemo) to DWScript using:
dwsUnit.ExposeRTTI( TDemo.ClassInfo )
This just works and is a great way of quickly adding properties and methods.
I also wish to add an existing instance in a similar way, so I have created my instance FDemo of type TDemo and then performed:
dwsUnit.ExposeInstanceToUnit( 'Demo', 'TDemo', FDemo );
This looks a promising routine to call but I get an AV from an uninitialised unit table. I've also looked in the unit test code of the SVN source to see the use of this function but to no avail. Can anyone point me at what I should add / change?
ExposeInstanceToUnit has to be used from within the TdwsUnit table initialization, see RTTIExposeTests/ExposeInstancesAfterInitTable for some sample code. It allows directly exposing dynamic instances.
The other approach is to use the Instances collection of a TdwsUnit component, you get design-time support, and more controls over your instances and their lifetime.
Also keep in mind you have to make sure the instances you expose will properly behave even if the script misbehaves, f.i. when the user attempts to manually destroys an instance you exposed, and that instance shouldn't be destroyed. By default ExposeRTTI will map the destructors, so you may want to restrict that by specifying eoNoFreeOnCleanup.
edit: a last approach recently added is to use the TdwsRttiConnector, which basically allows exposing and connection to anything that's reachable through RTTI. That's very lightweight in terms of code to setup, but the downside is you don't get any form of compile-time checks.
I am trying to make a taglib to represent an object (to read and display at the UI). When creating an object (save method in the controller), I see the domain class and association are created by the auto assignment of parameter
def Book = new Book(params)
It also maps complex types (for eg: joda time). I wonder about the naming convention necessary to facilitate this mapping. Out of curiosity, can someone also point where in the grails source code I could see how grails handles this mapping. I'm still learning Spring and probably this would be a good exercise.
Thanks,
Babu.
AFAIK the naming conventions are rather straightforward. If there's a field params.foo and the object you are binding to has a field foo, it will bind the value, assuming the type conversion works properly. If there's a params.bar.id set with an Long value and your object has a complex property of type Bar, it will lookup this instance and inject it.
If you need more control over the binding process, you might want to use bindData.
If you are interested into the details of the binding process, have a look at Java's PropertyEditor as this is what is being used in the background. I wrote a blog post on how to create and register PropertyEditors a while ago, maybe it helps you getting started with that stuff.
This is pretty much a duplicate question but instead of using Castle Dynamic Proxy I'm using LinFu Getting underlying type of a proxy object
I'm using automapper to create proxies of interfaces that I'm sending to my viewmodel in Asp.net MVC. My problem is from what I can tell that MVC's default MetadataProvider find the properties and metadata by calling .GetType() on the model.
So what happens is EditorFor() and DisplayFor() templates don't generate any fields. What I need to do is find the proxy target type and then generate my templates. I know I can just parse the name and use GetType( "thename" ) but was wondering if there was an easy way.
LinFu.DynamicProxy doesn't directly expose the underlying object of a proxy. It simply redirects each method call to an IInterceptor implementation instance. In order to access the underlying object, you'll have to figure out whether or not the current interceptor instance actually has a target class instance, or not.
If you're working with AutoMapper, AFAIK, they use LinFu.DynamicObject to do a lot of the duck taping, and calling GetType() on a dynamic type generated by LinFu.DynamicObject won't even get you the actual type in your domain model--it will just get you an object that has been literally duck-taped together by LinFu itself.
get latest AutoMapper - it uses Castle Dynamic Proxy, and you already know how to get this from there :)