I've found a workaround, but I had trouble earlier this week working with FluorineFx, where I had a Linq-to-SQL–generated object I wanted to send over the wire to Flash. This object contained a property that Flash didn't need:
[Association(Name="User_UserEntry", Storage="_UserEntries",
ThisKey="UserID", OtherKey="UserID")]
public EntitySet<UserEntry> UserEntries { ... }
But Flex couldn't handle reinflating this type, throwing:
ArgumentError: Error #2173: Unable to read object in stream. The class flex.messaging.io.ArrayCollection does not implement flash.utils.IExternalizable but is aliased to an externalizable class.
Now I didn't need to send the property over the wire, so I tried the steps that Marc Gravell suggested in issue 456624, firstly adding attributes to it using the MetadataTypeAttribute in System.ComponentModel.DataAnnotations (found from JasonW's comment on issue 393687:
[MetadataType(typeof(UserMetadata)]
public partial class User { }
internal class UserMetadata
{
[FluorineFx.Transient]
public EntitySet<UserEntry> UserEntries { get; set; }
}
Unfortunately it seems that FluorineFx doesn't support metadata attributes yet (which isn't very surprising, tbh, they are quite new).
What I ended up having to do was create a dedicated DTO, with all the properties that Flash cared about and none of the properties it didn't. Not the most elegant of solutions.
So, have other people come across this problem and have you found more-elegant ways of solving it?
I use the Transient attribute and it works fine. I do work with the latest FluorineFx release from SVN.
Related
I'm trying to use Groovy mixin transformation on a spring-mvc controller class but Spring does not pickup the request mapping from the mixed in class.
class Reporter {
#RequestMapping("report")
public String doReport() {
"report"
}
}
#Mixin(Reporter)
#Controller
#RequestMapping("/a")
class AController {
#RequestMapping("b")
public String doB() {
"b"
}
}
When this code is run .../a/b url is mapped and works but .../a/report is not mapped and returns HTTP 404. In debug mode, I can access doReport method on AController by duck typing.
This type of request mapping inheritance actually works with Java classes when extends is used; so why it does not work with Groovy's mixin? I'm guessing it's either that mixin transformation does not transfer annotations on the method or that spring's component scanner works before the mixin is processed. Either way, is there a groovier way to achieve this functionality (I don't want AController to extend Reporter for other reasons, so that's not an option) ?
You can find below the responses I got from Guillaume Laforge (Groovy project manager) in Groovy users mailing list.
Hi,
I haven't looked at Spring MVC's implementation, but I suspect that
it's using reflection to find the available methods. And "mixin"
adding methods dynamically, it's not something that's visible through
reflection.
We've had problems with #Mixin over the years, and it's implementation
is far from ideal and bug-ridden despite our efforts to fix it. It's
likely we're going to deprecate it soon, and introduce something like
static mixins or traits, which would then add methods "for real" in
the class, which means such methods like doReport() would be seen by a
framework like Spring MVC.
There are a couple initiatives in that area already, like a prototype
branch from Cédric and also something in Grails which does essentially
that (ie. adding "real" methods through an AST transformation).
Although no firm decision has been made there, it's something we'd
like to investigate and provide soon.
Now back to your question, perhaps you could investigate using
#Delegate? You'd add an #Delegate Reporter reporter property in your
controller class. I don't remember if #Delegate carries the
annotation, I haven't double checked, but if it does, that might be a
good solution for you in the short term.
Guillaume
Using the #Delegate transformation did not work on its own, so I needed another suggestion.
One more try... I recalled us speaking about carrying annotations for
delegated methods... and we actually did implement that already. It's
not on by default, so you have to activate it with a parameter for the
#Delegate annotation:
http://groovy.codehaus.org/gapi/groovy/lang/Delegate.html#methodAnnotations
Could you please try with #Delegate(methodAnnotations = true) ?
And the actual solution is:
class Reporter {
#RequestMapping("report")
public String doReport() {
"report"
}
}
#Controller
#RequestMapping("/a")
class AController {
#Delegate(methodAnnotations = true) private Reporter = new Reporter
#RequestMapping("b")
public String doB() {
"b"
}
}
When you map requests with annotations, what happens is that once the container is started, it scans the classpath, looks for annotated classes and methods, and builds the map internally, instead of you manually writing the deployment descriptor.
The scanner reads methods and annotations from the compiled .class files. Maybe Groovy mixins are implemented in such a way that they are resolved at runtime, so the scanner software can't find them in the compiled bytecode.
To solve this problem, you have to find a way to statically mixin code at compile time, so that the annotated method is actually written to the class file.
Here is the scenario, discovered while trying to troubleshoot the same issue in the self hosted designer. Create a library project with a type in it. Mine is this.
namespace RaceEventLibrary
{
public class Registration
{
public string Name { get; set; }
public int Age { get; set; }
public string EventName { get; set; }
}
}
Now create a Workflow 4.5 console app (or service, it doesn't seem to matter). Reference the library project. Put a sequence on the designer and then make an InArgument of this library type, Registration in my case. All is fine, the designer is happy.
Next create another identical project, reference the same library. Now simply open the xaml file from the first project. Boom, it can't find the types.
System.Xaml.XamlException: 'The type ‘InArgument(r:Registration)’ of property ‘registration’ could not be resolved.'
This in the xaml is:
<x:Members>
<x:Property Name="registration" Type="InArgument(r:Registration)" />
</x:Members>
preceded by
xmlns:r="clr-namespace:RaceEventLibrary;assembly=RaceEventLibrary"
With the self hosted designer I have been finding many variations of this issue and have tried various ways to get the library assembly loaded into the designer, but no joy.
Any suggestions of how to correct this?
WF4 has it own ways of loading assemblies that is not always exactly the same as the standard .NET framework. Ron Jacobs did an interesting number of posts on that, see here for a start.
You don't mention how you actually load the workflow into the WorkflowDesigner. There are several ways of doing this. When using the ActivityXamlServices.CreateBuilderReader() you can specify using the XamlSchemaContext what assemblies are required. That should let you load the workflow.
Anyone know if the Moq functional syntax supports setups for Non-Public properties? I noticed that it doesn't work.
NOTE: This is for the functional syntax.
public class Foo
{
public virtual int FooProperty { get; protected set; }
}
This doesn't throw an error, but fails to mock FooProperty
Mock.Of<Foo>(x => x.FooProperty == 1);
The regular syntax works fine.
var mockFoo = new Mock<Foo>(); mockFoo.SetupGet(x=>x.FooProperty)
.Returns(1)
It might be worth looking at the Pex/Moles tool from Microsoft Research. Moles is used to create accessors for non-public stuff.
It will support mocking of internal properties if you add an assembly attribute to the assembly containing the class under test (add to AssemblyInfo.cs):
// This assembly is the default dynamic assembly generated Castle DynamicProxy,
// used by Moq. Paste in a single line.
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
(You would also have to add an InternalsVisibleTo entry for your test project, of course.)
If you do this, you can mock any internal property in the assembly to which this is added. If you want to mock private or protected properties, I'm pretty sure there's no way to do that directly. If they're protected, you could create a Dummy inheritor and give it public methods or properties that access/manipulate its protected members. For private, there's really nothing you can do, I believe.
ASP.NET 3.5
Classes throughout our solution referenced ConfigurationManater.AppSettings[""] to get appSettings (from web.config).
We decided we weren't happy with that. Folks were mistyping appSetting key names in code (which compiled fine), and it was cumbersome to track usages. And then there's the duplicated strings throughout the codebase as you reference the same appSettings all over the place.
So, we decided that only one class would be allowed to reference the ConfigurationManager, and the rest of the solution would reference that class when it needed the value of a certain appSetting. ConfigurationManater.AppSettings[""] was static, so we exposed a bunch of static read-only properties off of our single Settings class.
public class Settings {
public static string Foo {
get {
return ConfigurationManager.AppSettings["Foo"];
}
}
}
That worked pretty well, until we needed to mock the settings in our tests. We created an interface to enable our mocking (was this a mistake of any kind?).
public interface ISettings {
string Foo {
get;
set;
}
}
public class Settings : ISettings {
public string Foo {
get {
return ConfigurationManager.AppSettings["Foo"];
}
}
}
And now we're injecting the ISettings instance as a dependency of the objects which use settings values (the class/interface are in a project that everyone can reference without problems).
In places where we can't inject an existing instance (e.g. Global.asax), we construct a new instance into a static field.
Given all of that, what would you recommend we change, and why?
Using an interface to represent configuration is a good idea. But your implementation looks a little off.
Joshua Flanagan wrote about writing application configuration code in a way that specific configuration sections can be injected into your code. This is a good idea, as it really decouples your code from worrying about details behind configuration. Have a read.
I think this will address the issue you are having re. testability.
I am having more than a little difficulty trying to debug why MVC is not binding correctly in a given case I have...
Basically, I have my action which receives a complex object which in turn has a complex child object - Activity.Location.State (Where Activity is the complex object that the action expects, Location is a complex child object and State is just a string).
Now I set up a test project which as far as I can tell exactly mimics the actually scenario I have, in this test case the binding works... But in my actually project, the binding to Activity works but not to Location... By putting break points within the Locaiton property I can tell that MVC is retrieving the complex Location object from the Activity, but its not setting any of the properties...
I am trying to debug the issue but I need access to the MVC v2 preview 2 symbols which I can't seem to track down... I would like to see what it is actually doing once it pulls out the location object (for some reason I think it might be failing internally but swallowing the exception).
Any ideas on what I could do here...
Cheers
Anthony
UPDATE:
Ok I did what J.W. suggested and directly reference the MVC project...
I found the problem and there was one very small difference that I overlooked... As I result I found out that MVC does not currently support multiple levels of INTERFACE inheritance when it comes to model binding... See the following...
//MODEL
public class Location : ILocation
{
...
}
public interface ILocation : ILocationCore
{
...
}
public interface ILocationCore //In my sample I didn't have this second level interface
{
...
//MVC doesn't find any of these properties
...
}
public class Activity : IActivity
{
...
}
public interface IActivity : IActivityCore
{
ILocation Location { get; set; } //MVC finds this and reads its meta type as an ILocation
//Also the implementation of this Location within Activity will always return a instance - our IoC takes care of that, so MVC should never have to create the instance
}
public interface IActivityCore
{
...
}
//CONTROLLER
public ActionResult Create(Activity activity)
{
}
Hence what I have found is that MVC finds the Location and reads its meta type as an ILocation, but when GetModelProperties is run within the DefaultModelBinder the following occurs -
protected virtual PropertyDescriptorCollection GetModelProperties(ControllerContext controllerContext, ModelBindingContext bindingContext) {
return GetTypeDescriptor(controllerContext, bindingContext).GetProperties();
//This return no properties
}
protected virtual ICustomTypeDescriptor GetTypeDescriptor(ControllerContext controllerContext, ModelBindingContext bindingContext) {
return new AssociatedMetadataTypeTypeDescriptionProvider(bindingContext.ModelType).GetTypeDescriptor(bindingContext.ModelType);
//bindingContext.ModelType - is ILocation
}
Hence I am assuming at this point that TypeDescriptionProvider doesn't support this style of inheritance, which i am quite surprised by. Also looking at the v1 source it looks like this was introduced with v2 - but v1 mightn't have been able to support what I am trying to do anyway.
I wouldn't say that this is really a bug, but I tried replacing my the interfaces with concrete classes and it worked fine. Hence the behavior isn't really what I would expect and is a little inconsistent.
Any thoughts??? I would have thought that this inheritance was not fairly standard but would occur often enough to be catered for. Thanks for the reply.
Cheers
Turns out this behavior is by design due to how interface inheritance works. Interfaces do not define implementations, thus ILocation doesn't "inherit" the properties of ILocationSource. Rather, ILocation only defines what a concrete implementation must implement.
For the full details including the section of the CLI (Common Language Infrastructure) spec which defines this behavior, check out: http://haacked.com/archive/2009/11/10/interface-inheritance-esoterica.aspx
I would simply reference to the asp.net mvc2 source code published in codeplex. I did that, it's very straightforward.
It will give you much better understanding when you debugging through the source code.