re:motion Team Blog

You seem to have looked into it pretty far. Like I said, re:motion mixins are not a generic AOP framework, they are not targeted at croscutting concerns. However, its implementation is similar to some AOP stuff, so we might add some mechanisms for croscutting stuff (what the EntLib guys at MS call "policy injection"). That would be nice for users who basically want the mixin stuff, but don't want to use another library for crosscutting stuff (for ease of use or performance). That's not a priority now though.

The problem with ASP.NET is that it won't call our factory methods, it just generates C# sources with "new" statements scattered all over it, then compiles it. That's bad news if you want to mix stuff into controls/pages. What we're doing is, we're precompiling the subclasses that contain the mixins in the build process (not at runtime). Then we hook into ASP.NET to modify the markup on the fly so that it references our mixed types instead of the original ones. We're using this in a product already, but it has not found its way into the framework repository yet, so it's not in the preview.

IL rewriting might be another way to handle situations where new gets called, but in the context of the ASP.NET compilation process, this would probably be a lot more complicated and fragile.

Readability has been a major concern, I'm glad for any positive feedback. After all, readability seems to be the number one problem of AOP, we just tried to deliver a tool that's more specific, and therefore easier to use.

The source code/licensing question is a bit tough, since we're about to deliver a very large code base with re:motion. Mixins were only the first part to be anounced because of lang.net. I'll keep everyone up to date on this blog.


What's LUA?

Thanks for your feedback!
- Stefan

Mihail,

I noted that you're redistributing our libraries in your ZIP file. I'd like to ask you not to do this for public downloads, as the license two-liner does not allow it. (We really don't want to look into a redistributable interim license before we've got it all LGPL'ed. In the meantime that means anyone using your samples has to do a separate download, sorry about that.)
Thank you!

The ASP.NET markup stuff already works in one project, it's just not been moved into the framework.

A few comments about your code:

1) The way you're using mixin scopes in MyHttpHandler is correct, but untypical. Usually you'd either put an [Extends] attribute on the mixin, pointing to either Page or DefaultPage, or you'd say [Uses(typeof (MyPageEx))] on DefaultPage. But if you need to make that decision at runtime, there you go.

2) Exposing protected methods via interfaces is dangerous, because it violates the intended encapsulation. Now anyone can cast to IMyPageEx and call those protected methods of Page.

3) When you use [OverrideTarget] you really should consider calling the base method, just like when using the override keyword. In your example, registered event handlers for PreInit and LoadComplete would not be fired, because that's just what those base methods do. You use "Base" (instead of lowercase "base") to call base methods of mixins, but you have to do something to make sure the type of Base has all the methods you need to call at compile time:
- Instead of Mixin<TThis>, your mixin must inherit from Mixin<TThis,TBase>, where TBase will be an interfaces that has all necessary base methods. So yes, in this case you actually need to create an interface for those protected methods. The good news is, you don't need to implement it, keeping encapsulation intact.

public class MyPageEx : Mixin<Page, IMyPageEx>
{
[OverrideTarget]
public void OnLoadComplete(EventArgs e)
{
Base.OnLoadComplete (e);
This.Title = "My New Title";
}
}

That's it. The interface is implemented automatically for you, but not exposed to anyone outside your mixin.

I'm glad to see that it's possible to get this far without much documentation though!

- Stefan