TRUNK IS SAFE AGAIN

Coordinator
May 30, 2011 at 12:39 AM

Sorry for the inconvenience. We've got everything fixed. We've got a new RegEx-based ViewLocator and ViewModelLocator now. We had some glitches making sure that we had all the pre-existing conventions supported. That's all taken care of now.

May 31, 2011 at 4:08 PM
Edited May 31, 2011 at 4:26 PM

Hi Rob,

I have an issue with the trunk: The simple view location that looks for the view with no more "Model" in the name does not work. My model is called MainWindowModel and the view is MainWindow. Both are in the same namespace. I'm digging in the code but I can't understand the new convention, please give me some advice.

 

BTW: the changeset breaking this ( simple ) functionality is the 837da930a77b.

Coordinator
May 31, 2011 at 5:11 PM

You will need to add a custom RegEx mapping to make that work. We'll try to get some documentation on that soon.

May 31, 2011 at 5:14 PM

Thank you Rob for the fast reply. Ok till now I bound the old locator, I will try to get myself how to add the regex ( but having the doc would be nice :) ). Anyway, should'nt that rule apply as a default ?

Coordinator
May 31, 2011 at 5:15 PM

In the mean time, if you are having a problem with the RegEx piece, you can just override the Func and replace it with the simple mapping code we used to have.

May 31, 2011 at 5:23 PM

Yes thanks,y I did use the old locator, just asking why the old behavior is not mantained as a default :)

May 31, 2011 at 5:24 PM
felixpollan wrote:

Hi Rob,

I have an issue with the trunk: The simple view location that looks for the view with no more "Model" in the name does not work. My model is called MainWindowModel and the view is MainWindow. Both are in the same namespace. I'm digging in the code but I can't understand the new convention, please give me some advice.

 

BTW: the changeset breaking this ( simple ) functionality is the 837da930a77b.

Hi felix,

The standard conventions are:

  • Namespace.MainPageViewModel => Namespace.MainPageView
  • Namespace.ViewModels.MainPageViewModel => Namespace.Views.MainPageView
  • Namespace.CustomerViewModel => Namespace.CustomerView
  • Namespace.ViewModels.CustomerViewModel => Namespace.Views.CustomerView

You can add this custom convention code to your bootstrapper to handle your case:

ViewLocator.NameTransformer.AddRule("WindowModel$", "Window");

This custom rule looks for any type ending with "WindowsModel" and returns a type ending with "Window".

This new name resolution mechanism is very stringent in terms of where string patterns are located (i.e. end of type names, within namespace names, etc.) but allows for greater control of custom transforms because of it. However, one trade off was that the standard, built-in transforms required more consistency in the naming conventions, and only a few name transforms were considered standard conventions.


May 31, 2011 at 6:06 PM
Edited May 31, 2011 at 6:08 PM
EisenbergEffect wrote:

In the mean time, if you are having a problem with the RegEx piece, you can just override the Func and replace it with the simple mapping code we used to have.


I looked at the older version, and the relevant code was this line:

var viewTypeName = modelType.FullName.Replace("Model", string.Empty);

I'm not sure what the intended transforms this was supposed to cover, but it does cover the case that felix has in his project. However, as I mentioned before, this is a "greedy" transform since it doesn't care where "Model" is found in the string. These are the kind of side-effect transforms that would occur:

  • ModelTrainViewModel => TrainView
  • Namespace.Models.MainWindowModel => Namespace.s.MainWindow

What we can do is add one more rule to the standard:

ViewLocator.NameTransformer.AddRule("Model$", String.Empty);

This rule would need to be added first, so that it serves as the transform that occurs if the name falls through all other (more-specific) rules. While this rule is less-specific than the current standard rules, it will at least limit the transforms to names that end with "Model" rather than having "Model" anywhere in the namespace name or in the type name.

Coordinator
May 31, 2011 at 6:10 PM

I can easily add that at the top of the list. Would we need to add something to the ViewModelLocator as well then?

May 31, 2011 at 6:50 PM
EisenbergEffect wrote:

I can easily add that at the top of the list. Would we need to add something to the ViewModelLocator as well then?

You need to add this as the first rule in the ViewModelLocator.

            NameTransformer.AddRule(
                @"(?<fullname>^.*$)",
                @"${fullname}Model"
                );

This will tack on "Model" to the name if it falls through all other rules.

Coordinator
May 31, 2011 at 7:12 PM

Thanks. I'll get those two in soon.

May 31, 2011 at 7:36 PM

Thanks to all, very much,

I'm just in a trouble because I supposed the behavior used by my project was actually the default in the previous version in order to me, so I'm just asking if I was always wrong or not...

Coordinator
May 31, 2011 at 10:42 PM

Ok. I've committed the fix. Try it out and let me know if you have any problems.

Jun 1, 2011 at 8:15 AM

Thank you Rob,

Now works like a charm.

Jun 1, 2011 at 9:00 AM
Edited Jun 1, 2011 at 9:48 AM
EisenbergEffect wrote:

Ok. I've committed the fix. Try it out and let me know if you have any problems.

Thanks Rob, as I said now it works like a charm. But... a question: Since in NameTransformer rule order is critical, and rules are added in two different static constructor:

ViewModelLocator and ViewLocator, can we always trust the order will be the same even in future version of CM ? And, it would be nice to have some external InsertRule as well,
for the same reason ( forcing the order ) to the external user.
I'm interested in opinions about that.
Coordinator
Jun 1, 2011 at 1:36 PM

I'll add an InsertRule method.

Coordinator
Jun 1, 2011 at 1:54 PM

I made some improvements that will allow you to have complete control over the NameTransformer like a normal collection.

Jun 1, 2011 at 2:51 PM

That would be really usefull. Tnx