Sorry, I wasn’t very clear. We can localize strings based on a straight key (i.e. “USERNAME_KEY”) or, when we’re doing something based on reflection, like a textbox with a label, it will default to using a localized string keyed off the property.

// Inferred localized string label for textbox
< %= this.TextBoxFor(m=>m.Case.Title) %>

// Explicit localized string labelf or textbox
< %= this.TextBoxFor(m=>m.Case.Title).WithLabel(“CASE_TITLE_KEY”) %>

Only care because localization is something I’ve done a few times before and will have to work on again soon and I *hate* it.

2.) No, we have keys we ‘key’ on. Also, we can have it use properties of a given entity for things like grid header rows and such. The localization manager will look for the localized version of the “FirstName” property of the “Contact” object, for example.

3.) Getting the “choose the view” responsibility out of the controller helps keep our controllers nice and lean and reusable for multiple purposes. It allows us to use the same controller for serving up a normal page, or the same functionality in a modal pop-up. The invocation stuff handles whether it’s in a modal pop-up (and the associated callback), or if it’s in a full page (normal mode).

I wanted to ask about a few bits I still don’t get:

1) Invocation registry – Do you mean you handle all routing yourself?
2) LocalizationManager – Do you just key on the object hierarchy to get the descriptions, just interested in how your handling this to be honest.

I’d also be interested in reading more about how you seperate the preparation of the view from the actual execution of the view. Sounds cool, so far I don’t think I’ve met situations where I’ve needed such a capability but I could be wrong.

;D

< %= this.TextBoxFor( m => m.Contact.FirstName ).Width(200).WithLabel(“FIRST_NAME”) %>

to

< %= this.TextBoxFor( m => m.Contact.FirstName ).Width(200).WithLabel() %>

because LocalizationManager “knows” how to retrieve a localized string title for a class property.

And no, I don’t see us switching to the IModelBinder stuff in v5. I think our solution is still better than IModelBinder.

@Joe,

Part of the “Invocation Registry” (horrific name that I’m to blame for) infrastructure is a Fluent Interface for hooking up controller actions and views. We have a grammar for registering controller actions as JSON output in that FI.