There is a native framework object called HttpBrowserCapabilities. I'd like to Serialize this to XML. Any ideas of the best way to go about it?
My first thought was to create my own class that inherits it then decorate all the properties with XML and then serialize it. I was wondering if there was a simpler (magical) way to do this. :)
TIA
Unless the class is marked as being serializeable, no. However to achive the above, using a decorator, you can use IDataContractSurrogates. See http://msdn.microsoft.com/en-us/library/system.runtime.serialization.idatacontractsurrogate.aspx
Related
We are using flyweight pattern for some objects in our system. Those objects are also saved in database (mongodb). After loading the object back from db using Spring Data, there is no easy way to replace the object constructed by Spring Data with the object in the flyweight cache. For Java deserialization, there is readResolve() method. I wonder if Spring Data can add something similar to support this use case.
Is there any solutions with the current Spring Data implementation (1.4.1 release)?
They must have something otherwise enums wouldn't work either... I'd consider custom converters, e.g. here (look for the last section with PersonReadConverer):
http://docs.spring.io/spring-data/mongodb/docs/1.4.x/reference/html/mapping-chapter.html
I just hope it works when Person is a nested field inside another class - didn't get a chance to test it .
Good luck
Thanks #Pelit_Mamani for some suggestions. I did try to implement a converter and set it in mongo mapping converter and it seems to work. It works even when the object is embedded in other object.
<mongo:mapping-converter id="mappingConverter" base-package="com.mytest.domain" db-factory-ref="mongoDbFactory" disable-validation="true">
<mongo:custom-converters>
<mongo:converter>
<bean class="com.mytest.repo.converter.MyReadConverter" />
</mongo:converter>
</mongo:custom-converters>
</mongo:mapping-converter>
And the converter class:
public class MyReadConverter implements Converter<DBObject, MyObject>
Assuming that I have a Scala case class that is persisted using the Salat/Casbah/Mongo stack, I want to set up pre-persistence validation logic like I could easily do in Rails using ActiveRecord hooks or in Java using JSR 303 bean validation.
Perhaps there is a better way to think about this in a functional paradigm, but I want to accomplish something like the following:
case class SomeItem(
id: ObjectId = new ObjectId,
someProperty: String) {
#PrePersistence
def validate() = {
//perform some logic
//fail document save in certain conditions
}
}
I am having trouble finding any documentation on how to do something like this in Salat. I do see a #Persist annotation but it seems focused on serializing specific values and not creating hooks.
It seems like one option is to override the save method in the SalatDAO for my case class. Does anyone have an example of this or know of a better, built-in way to handle validation tied to a pre-persistence event?
Thanks!
Salat developer here.
Yes, #Persist is simply for ensuring that fields that aren't in the constructor are serialized - this is particularly useful for manipulating data in MongoDB. One example is where you want to ensure that all the fields are populated with a value so you can sort sensibly, but the value is an Option which may not be present.
Unfortunately, the Java driver doesn't offer lifecycle callbacks like the Ruby driver :(
But what you want should be easy enough to do. Please file an issue at https://github.com/novus/salat/issues and describe how you would like the validation to behave - we can start a discussion and I can try to get something in for you in the 1.9.2 release.
Is there any way to create a fake from a System.Type object in FakeItEasy? Similar to:
var instance = A.Fake(type);
I try to write a fake container for AutoFac that automatically return fakes for all resolved types. I have looked in the code for FakeItEasy and all methods that support this is behind internal classes but I have found the interface IFakeObjectContainer that looks pretty interesting, but the implementations still need registration of objects that is the thing that I want to come around.
As of FakeItEasy 2.1.0 (but do consider upgrading to the latest release for more features and better bugfixes), you can create a fake from a Type like so:
using FakeItEasy.Sdk;
…
object fake = Create.Fake(type);
If you must use an earlier release, you could use some reflection based approach to create a method info for the A.Fake() method. (since it's about auto mocking this shouldn't be a problem really).
This is best done using a registration handler. You should look into how AutofacContrib.Moq implements its MoqRegistrationHandler. You'll see that it is actually using the generic method MockRepository.Create to make fake instances. Creating a similar handler for FakeItEasy should be quite simple.
Looks like the class that is generated for PlaceHistoryMapper is hard-coded to use AbstractPlaceHistoryMapper as the super class.
So, I am trying to work around this by trying to replace this AbstractPlaceHistoryMapper with a custom mapper of mine using deferred binding . I am using the following rule in my *.gwt.xml:
<replace-with class="com.google.gwt.place.impl.AbstractPlaceHistoryMapper">
<when-type-is class="com.test.sampleapp.CustomPlaceHistoryMapper" />
</replace-with>
But for some reason the replace does not seem to be happening. CustomPlaceHistoryMapper is not getting kicked in and the generated class still uses AbstractPlaceHistoryMapper.
Any thoughts/pointers as to what might be resulting this behavior are much appreciated.
Note: I have also posted this on the GWT group but haven't received an answer so far.
To make the deferred binding work a class must be created with GWT.create(). However, AbstractPlaceHistoryMapper is only used as an extended class. So it will never be created via GWT.create, but always by instantiation the subclass. And therefor deferred binding won't work in this case. If you want a complete different implementation you have to implement a custom PlaceHistoryMapper, and manage the known tokens yourself. This also means you can't use the History annotations either.
As a side note the classnames in your rule should be swapped. But for the end result this doesn't matter, since it won't work in the first place.
It is absolutely possible to have custom history tokens (eg. #mail or #mail/bla instead of only #mail:inbox) using the out-of-the-box Place-related classes that GWT (2.0) provides.
Instead of replacing AbstractPlaceHistoryMapper you could instantiate the default PlaceHistoryMapper passing in it's constructor your implementation of PlaceHistoryMapper<T> or PlaceHistoryMapperWithFactory<T>.
eg.:
final PlaceHistoryHandler placeHistoryHandler = new PlaceHistoryHandler(new CustomHistoryMapper());
You will be able then to map tokens as you wish.
I personally recommend you to use an unique PlaceTokenizer in you mapper custom implementation so that I dont have to have an inner PlaceTokenizer class in each of your Places.
Hope that helps. Feel free to ask any doubts.
I use contructor injection in my solution, but this one class has a property that i do not want to pass in the constructor where i have the invariant dependencies.
Let's say i got an ILogger and it has a FileName property i want to set, while still having it set the dependancies in the contructor.
How do i go about registering the type, and at the same time pass the defaunt connection string.
I hope there is an easy way to do it - preferably without decorating the property with an attribute, but if the setup is easier with the attribute i guess that's cool :)
So the question is, how do i inject a property value on an object that also uses contructor injection - with Unity.
UPDATE: I mentioned it in the title, but i forgot to elaborate in the body of the text - i want to set these dependencies up manually (in code) as opposed to in a config file.
Ok i guess it helped to ask the question, i found out - here it is.
container.Configure<InjectedMembers>().ConfigureInjectionFor<BasicLogger>(
new InjectionProperty("FileName", #"C:\test.log")
);
If you are injecting properties you have to use [Dependency] or else manually inject that dependency.
You usually want an IConfiguration interface to be injected. This would probably have a LogFile property that you can read.
The Configuration implimentation is usually just a simple wrapper to read items from the config file.