Is it possible to somehow chain multiple converters in MVVMCross?
e.g.
"ItemsSource Items, Converter=FilterInactive,GroupByDate,SortByType"
Or will I have to create a new converter type for each chaining variant I need?
Using the Tibet Binding syntax you can do:
ItemsSource SortByType(GroupByDate(FilterInactive(Items)))
But this might not be the most efficient way to present your data.
Related
I know how to use live bindings on a form to bind one property to another property using an expression. For instance, binding a TLabel's Caption to a TEdit's text property.
I know how to create new expressions using IScope, TNestedScope, TDictionaryScope, etc. I can add my own classes and call them as scripted expressions.
What I don't know is how to take my new expression scope and make it available to the TBindExpressions in my TBindingList for use on a form when I'm doing things described in the first paragraph.
Anyone know how to do this? I've investigated, and I can't find a way to add an IScope reference to the binding expressions available to TBindingList and its sub-components.
I am trying to understand when does Orika use converters to do the mapping versus direct casting.
I have the following mapping:
Class A {
Map<String, Object> props;
}
Class B {
String bStr;
int bInt;
}
My mapping is defined as props['aStr'] => bStr and props['aInt'] => bInt
When I look at the generated code, I see that for the String case, it uses a converter and calls its convert method for the transformation:
destination.setBStr("" + ((ma.glasnost.orika.Converter)usedConverters[0]).convert(
((java.lang.Object) ((java.util.Map) source.getProps().get("aStr"),
(ma.glasnost.orika.metadata.Type) usedTypes[0]))
But, for the integer case it directly casts it like this:
destination.setBInt((java.lang.Integer)(java.lang.Object) ((java.util.Map)
source.getProps().get("aInt")))
The above line of code ends up giving class cast exception.
For fixing this issue, I was thinking along the lines of using a custom converter but if the above line of code doesn't use the converter then that wont work.
Of course, I can always do this is in my custom mapper but just trying to understand how the code is generated for type conversion.
Thanks!!
In Orika there is two stages: config-time and runtime, as optimization Orika resolve all used converter in the config-time and cache them into each generated mapper so it will be accessible directly O(1) but in the config time it will try to find in a list O(n) of registered converters which one "canConvert" between two given types, canConvert is a method in Converter interface .
So this solution offer the best of the two worlds:
A very flexible way to register a converter with arbitrary conditions
An efficient resolution and conversion operation in the runtime.
Orika by default, leverage the existence of .toString in every object to offer implicit coercion to String for every Object. The problem here is that there is no Converter from Object to Integer.
Maybe this can be an issue of error reporting. Ideally Orika should report that an Object have to be converted to Integer and there is no appropriate converter registered.
I have a number of interfaces I use to pass business objects around in my application. Using Ninject, I can do whatever I want with them without needing to know the type of the actual object; in this case, most of them are actually various Linq to Sql objects that implement the interface.
For example, I have a Linq to Sql object called Listing that implements IListing.
Where I've run into a problem is with serialization. I've tried using the built in JsonResult and JsonNet. Both of them attempt to serialize the actual Linq to Sql object, not just the properties defined in the interface type. This leads to circular reference issues, but the larger problem is that I only want the properties defined in the interface being serialized and passed around.
So, is there an elegant way to serialize just the properties defined in an instance of an interface that I pass to a serializer?
You could define a new transport type containing only the properties you need and then use AutoMapper to convert between your domain object to this type which will be used for serialization.
I have an asp.net mvc view, which is using Telerik's grid.
Html.Telerik.Grid(Model.Items)
Model.Items is IQueryable, but the Grid requires me to cast it:
For example:
Html.Telerik.Grid((IQueryable<Product>)Model.Items)
The problem is: I don't know what type is in Model.Items (it can be IQueryable<Product>, IQueryable<Book> and many others).
What I also have is Model.ItemsType, which can have following values: typeof(IQueryable<Product>), typeof(IQueryable<Book>)...
How can I cast the IQueryable to IQueryable<T>, when I don't know the type of T in advance?
Generic types need to be known at compile-time, not determined at run-time.
What is the type of Model.Items? If it's derived from IEnumerable<T> then assuming you have a reference to System.Linq then you should be able to call the AsQueryable() extension method.
You're going to need to use reflection to invoke the Grid method when you don't know the T ahead of time, because there's no way to do it at compile time. If Model.Items actually is an IQueryable, then you don't need to cast it; just pass it along as the parameter during the reflection-based invocation (which takes all parameters as type object anyway).
Perhaps you can try binding to IEnumerable. Check the 'Binding to a collection of dynamic objects with MVC3 Razor' code library entry.
I don't really see the need for element to element binding in Silverlight 3 if using MVVM. Won't having one property directly affect another proper cause that property to be untestable?
To me, it makes more sense to do a two way binding to a explicit property defined in the ViewModel.
I agree that the use of MVVM severely deflates the usefulness of element to element binding.
Still, if all you are doing is binding two elements using a ViewModel property... what can you test? You can test that setting a property in the ViewModel sends a PropertyChanged event... but thats about it. Only when something else cares about that value is it useful to test a property like that.
In the simple cases, I can see element2element binding being more efficient and less code.