Can you believe no one else has posted on here?!?!

My guess is everyone will wait until you actually finish it all up, so much for chipping in. I've been playing with NancyFX quite a bit, reminded me that maybe it would be intesting to allow for different style of models to be produced so a NancyFX flavour one as well as a MVC one, or if a team have a special way they like to create their classes/models they could write their own "model provider" I guess this is what you mean by a "factory for the models"?

I've been distracted at this end so not had chance to play around with the code anymore but I will. What might be good is some guidance on where others might be able to help, you have a roadmap in your head but some "chunks" of work that we might be able to take on would be good, that way we can dip in and help out when time/family/moving house (me too) allow ;)

Good work and keep it up, I'll keep banging the drum in the meantime.

Pete

Hey LArs-Erik,

Was not aware of that thread... glad you twitted about it. So here's what I've done at the moment with typed models. It's all internal at the moment in 6.2 and 7.0, waiting for people to discuss it. Unfortunately, I haven't found time to write about it yet. That being said:

There's an IPublishedContentModelFactory interface. And a PublishedContentModelFactoryResolver to plug an implementation of that interface. By default, none is plugged. But if one is plugged, then the content cache will pass everything it returns through the IPublishedContentFactory.CreateModel(IPublishedContent content) method. So that factory has the possibility to turn the internal IPublishedContent into whatever you want that implements IPublishedContent, ie all sorts of strongly typed models.

Note that this is done at cache level, so there's no need for mapping in controllers or views, nothing. All you need to do is implement a factory, and the cache will natively return your strongly typed models.

Then there is a factory in the core, only it's not enabled by default. It relies on the abstract PublishedContentModel class, that implements IPublishedContent. The most simple model would look like:

public Article : PublishedContentModel
{
  public Article(IPublishedContent content) : base(content) {}
}

And then the factory would pick it and make sure any IPublishedContent of type "Article" are turned into an actual Article object. If "Article" is not the proper alias then there is an attribute you can use to specify the alias:

[PublishedContentModel("myArticle")]
public Article : PublishedContentModel
{
  public Article(IPublishedContent content) : base(content) {}
}

And that basically is _all_. Of course you'll want to add properties:

public string TextBody { get { return this.GetPropertyValue<string>("textBody"); } }

And maybe special properties to return filtered children, whatever. Everything is possible.

Again, this works today (only it is internal) and I think it provides what you call "factory" and "base class". The good thing is that it comes way before MVC so we don't need a new controller... even if you're running a WebForms template and request an IPublishedContent from the cache... you'll get the strongly typed model. I really think this is the way to go: deep in the core, and not outside. I think I have everything that's needed but I might be missing things?

Now as you can see, you have to write all your models by hand, and this is where your work might bring a lot. I have ideas about that part, such as generating parts of the models automatically from Umbraco, as partial classes, then let people extend the models (with their own partial part). But no time to experiment right now ;-(

Also, I've read https://offroadcode.com/blog/1774/the-state-of-code-first-development-in-umbraco/ with interest, and I understand that a lot of ppl are also interested in code-first. Ie, writing the models first. The issue is... writing the models by hand is tedious. I guess you want to write:

public string TextBody { get; }

and not

public string TextBody { get { return this.GetPropertyValue<string>("textBody"); } }

So in code-first, I fail to see at the moment how you can write those models... Unless you write them as some sort of abstract class, and the generator writes the actual classes underneath?

OK, long enough for now, but let's discuss it here.

One very important thing to me is to keep things as modular as possible. Eg, the models/factory thing we have now is totally independent from code-first/code-last whatever. It just implements support for models right into the core. There might be different generator solutions, as packages...

Stephan

Thanks guys!

Core work is exciting, I'll try to use it before moving on.

I don't know how I managed to fog it up, but it's obviously not at all clear what my "thing" does in it's current state. :)

You can now write:

public class ADocument
{
    public string AProperty {get;set;}
}

Boot up Umbraco, and USync will get an XML file with the metadata I can "guess" from that class. The document type will have the name "A Document" with the alias "aDocument", and same for the prop. It also does media. When USync writes the XML back, the class will look like this:

public partial class ADocument : ConfiguredBaseClass
{
    // some metadata
    public ADocument(IPublishedContent content) : base(content)
    {
    }

    [DataType("Textstring")]
    public partial String AProperty
    {
        get { return Content.GetPropertyValue("aProperty"); }
    }
}

You can keep adding properties, decorating them with misc. BCL attributes, Use DataType definition names, etc. It will all roundtrip and sync nicely. (Both ways, adding in backoffice will update the class) Of course you'll have to let your classes be overwritten, so the "code-first" bit is more of an input, not the "final result".

If you don't "code-first", you can still just use it to have all the models generated like that. They're all partial, so you can add custom logic.

I use this today in a project I've got, and I add special child lists "OfType

I'm not sure I like the idea of implementing IPublishedContent instead of exposing it as a member on the base, but as long as it's easy to change the core behavior it'll be fine. (As in implement IPublishedContent as default)

What about the view template in MVC? Does it have the typed model as its CurrentDocument, or are you introducing another property?

Otherwise, I'll make it my next mission to go and look at the factory and base class in core. Would be excellent if I could just plug this in and have it working. :)

For now I'll re-emphasize: the two-way already works! go try it. ;)

• GitHub
• Wiki - completeish docs
• Package

Lars-Erik

@Pete: Yes, it's possible to swap out how every little piece is generated and parsed. You can for instance write your own property body generator, your own class decorator (description etc), and so on. If the core model factory can already pick everything up, we should be off to a great start.

@Lars-Erik: because the typed model is returned by the cache, the view template in MVC has the typed model as its CurrentDocument -- no need for another property -- but it's still exposed as IPublishedContent. Guess you'll need a generic Model to indicate that CurrentDocument is, say, an Article.

The good part about implementing IPublishedContent is that all your models then behave as normal content. You can call any method that's available on IPublishedContent and it works. At no cost. Well, other than having to inherit from PublishedContentModel -- and that's where I see some friction, because your models inherit from ConfiguredBaseClass, right?

Hmm, ok. Half the point is that I want intellitip. Will CurrentDocument be declared as the model type? In other words, is there a generic UmbracoTemplatePage?

What I've done in my project is to make a class derived from UmbracoTemplatePage, shadowing CurrentDocument with whatever you set in a generic parameter. So my views start with @inherits MyTemplatePage<TheTypedModel>. Then I can do CurrentDocument.[intellitip]. I guess adding a generic UmbracoTemplatePage with an IPublishedContent constraint on the generic parameter would be both easy and non-breaking. :) Just have to document it visibly and clearly.

I've also created a default controller that just wraps the current published content with the typed model. (What the core factory does, but these aren't part of the package yet)

And no, there's no friction. I used ConfiguredBaseClass as a name to indicate that you configure which type in your project is the base class for your typed content. :) I don't generate it, and I don't enforce anything on it, except for a requirement to expose the published content as a member and getting it through the constructor.. (I will have to add support for a namespace in another path than the generated classes). However, since the generation and parsing is completely modular, we can have support for both types of base classes. See this page: https://github.com/lars-erik/Umbraco.CodeGen/wiki/Parsing-and-Generating-code

I only generate classes for the document- and media types. Everything else is up to the user to implement. Base class, factory (for now), controller and view base. There's absolutely no dependencies.

Hmm, ok. Half the point is that I want intellitip. Will CurrentDocument be declared as the model type? In other words, is there a generic UmbracoTemplatePage?

None that I am aware of right now, but this is of course a requirement and could be added to the core quite easily. Then we'd do

@inherits UmbracoTemplatePage<Article>
@Model.Content.BodyText

About the base class: ooooh so that means I just have to configure "ConfiguredBaseClass" to be "PublishedContentModel" and it works? Great.

As for "getting it through the constructor" -- PublishedContentModel has it already.

As for "expose the published content as a member" -- this is where we differ I guess, since in my case it does not need to expose the published content, it is the published content itself.

This is a great discussion!!

Base class: yes! :)

I'm going to give implementing IPublishedContent another go. Reason I don't like it is that I unit-test my typed models. So I went and created this ugly adaption stuff. But since GetPropertyValue<T> is so tightly coupled and was the main reason to adapt, I also ended up making all my props virtual. Only thing left to make virtual then is the Children property on the base class, and then we're good to go.

Quite sure that I'll make everything fit nicely into the stuff you've made. I think I saw a "TypedContentTest" or something in the core, but that might be Morten's? (and even a trace of mine) Any place I should look for your stuff?

L-E

Stephen's work is definitely interesting too. The "only" thing I'm missing there is how to define my document types in a code-first way. What I want is my document types in version control, with automatic syncing to and from Umbraco. This is what Lars-Erik's stuff does/wants to do.

I really like the way you define the document types in CodeGen, where you set templates, tabs etc. yourself inside the model. This means they are part of the model, too, so if you need to represent your content in the same way as your document type, you have that data available.

Over to your list Lars-Erik;

I think making new attributes specific for the document/media type definitions might be a good idea, to avoid conflicts and/or confusion around what property in Umbraco they target. Maybe the fields (icon, thumbnail etc.) should be attributes as well? I know these are added from the CommonInfoGenerator if they're empty now, but perhaps they should be attributes instead? A concise way of defining the different properties are more important though. If we end up not using attributes but only fields, that's fine by me to, as long as it's consistent.

I'd also like to see some different base classes to use when implementing roots, but the current one works well enough for now.

There are more interesting discussions above, so I'll leave it at this for now!

Attributes can work for icon etc. USiteBuilder does this and uses sensible defaults if none provided (actually I think they might be Umbraco defaults) so you could borrow from that. Custom data types might be tricky, I'm not sure how you are handling those yet. Defining everything in an attribute for a datatype could get messy especially when they have so many settings like DAMP for instance.

I'm more interested in using the UI to build my document types (its what its good at) and have that meta data (icon, description, etc) stored in uSync format and keep my models clean as I don't think I'd need that boiler plate meta data in my code (possibly with the exception of the description field as a comment maybe to give context, something that is missing from all this is a way to make notes/comments for fields in the Umbraco backend for just this sort of thing.

Exciting times.

@Lars-Erik: would be great if it could work with implementing IPublishedContent. As for unit testing... there are some internal stuff that I should make public. It's a great opportunity to create whatever's required to properly unit-test IPublishedContent... if we can all agree on a definition of what we need, I'll make sure it's in the Core.

And for TypedContentTest, yes it's Morten's stuff. Which is quite interesting too BTW ;-) I think you'll find my stuff in Umbraco.Tests.PublishedContent, have a look at PublishedContentTests, PublihedContentMoreTetes, PublishedContentTestElements.

Thanks again, guys. :)

I feel I've got better direction again now, and will do some testing with @Stephen's work.

@Pete: Not sure what you mean by "defining everything for a datatype"? You'll still have to set up data types in the backoffice, but I've changed the CodeGen to use the definition name by default. (IE. [DataType("Textstring")]) Also , there's the IPropertyEditorConverter interface you can implement for your datatype to return typed values from GetPropertyValue<T>. (I think @Stephan made it :) ) Add the GUID of the editor to the TypeMappings configuration, and codegen will use your custom datatype. (IE. string[])

@Jesper: You are aware you control the base class for now? Using R# it's easy to implement IPublishedContent by delegating.. (Alt+Ins, Delegate members) ;)

And if anyone feels up to it, making the custom attributes and generators and parsers for them is up for grabs. Will pull happily. ;) (Or get to it sooner or later)

L-E

@LE: Been looking at it last night, I know have a prototype UmbracoTemplatePage<T> which allows you to write

@inherits UmbracoTemplatePage<Article>
@Model.Content.BodyText

Ie Model.Content is an Article -- strongly typed.

Needs more test then I'll push it to 6.2 as internal, so you can have a look at it.

One more thing: how do you handle doctypes "mixins" and inheritance? In my tests, a PublishedContentModel can inherit from another one, and in addition you can simulate mixins with interfaces. So here you could inherit from UmbracoTemplatePage<IContentWithAddress> and display Model.Content.ZipCode -- for all actual types that implement IContentWithAddress. Making sense?

Stephan

Nice!

I'm actually swearing at you as we speak for making IPublishedContentModelFactory internal. ;) The rest I can handle via reflection. I'd really like it if there was some other way than internalizing all the prototyped stuff. Too bad there isn't some attribute like Obsolete to indicate that stuff will break / change.

Just made another branch of 6.2 in my fork so I can fiddle a bit with it.

Reg. inheritance, all the types follow the "master" hierarchy, so if you have say a root type called Content and an inherited doctype called Article, Content would inherit the configured base class and Article would inherit Content. You could add interfaces in partials, so that should resolve nicely. I haven't looked very hard at the ResolverBase implementations, though. Not sure whether it looks up the inheritance tree? (I even suspect they will be refactored away from being service locators some time next year(s)? :P )

I'd really like CurrentPage to be shadowed and exposed as the model, though. Model.Content is fair enough, but a train is a smell even though it's just one extra cart. :)

L-E

About proto stuff being internal: I'm not a 100% happy with it either, but don't want ppl to start using that code "in production" and then complain because "backward compatibility" has been broken. We thought about having a 6.2.0-unstable branch that would have that code public, but it was abandonned at some point.

That being said, I have all the commits needed to make things public here in a local repo. Could maintain that unstable branch in a fork... would that be useful? Exact same as 6.2.0 but with proto stuff being public?

Resolvers: need to look into it to answer you.

CurrentPage: so you'd like CurrentPage to be the strongly typed content? Makes sense, soon as your going to implement a strongly typed page, you don't want the dynamic content anyway.

This leads to questions... to be honest while coding UmbracoTemplatePage<T> I wasn't so sure what the role of RenderModel is... it just seem to have two properties, Content and CurrentCulture. There are other ways to get the current culture... So why is the model not the Content itself? I need to discuss this with Shannon.

@Stephen - The original reason was that RenderModel could have held other information regarding page rendering that might be useful so that we could future proof what was being sent to the page in the model. i.e. we could add any additional properties that might make sense in the future. Now, whether that was a good idea or not is another story - who knows, it still might come in handy, i dunno :)

Regarding templates, we have UmbracoViewPage<T> which you can use - UmbracoTemplatePage simply = UmbracoViewPage<RenderModel> and includes dynamic access to IPublishedContent via the CurrentPage property. Since you want strongly typed models, you'd probably not be caring about dynamic access.

IMO for the above discussion, "CurrentPage" should not be the strongly typed 'model' on the template, we should stick to using the MVC Model property as the model. The reason CurrentPage exists on the template currently is purely due to syntactic sugar for non-devs - I wanted to put it in on RenderModel but some felt that was not easy for non-devs to learn templating. If you just use UmbracoViewPage<T> then T = your strongly typed model.

BLOODY EXCELLENT! :) It all works!

I made a few of the classes in 6.2 public and made a test web.
There's a few minor issues, but I got inheritance and mixins to work.
Only thing I have to do is to support another namespace on the base class. For now I had to derive PublishedContentModel.

Here's a gist of all the relevant files:
https://gist.github.com/lars-erik/78b7fd7bbb4a8ade669c

For your post:
I know all about the internal policy, you don't have to apologize any more, but I really hope it can be evolved to some more practical way in the future. For now I completely understand the need to hinder production on volatile APIs. For my part, I run a site in production on my own fork of 6.2 since I'm waiting for a pull request and have a couple of other changes, but I promise I won't come crying to you guys when it breaks. :) Fully aware of the concequences.
Enough 'bout that.

NVM the resolvers. A little HQ bird has just voiced his opinion about them, so I'm just speculating and hoping. (Ref. my little reset in ApplicationEvents.cs in the gist)

Yep, CurrentPage should be typed. I'll shoot myself in the foot and say that removing RenderModel will break another site of mine, but the dependency on CurrentCulture shouldn't be hard to move anyway, so ditching that and having a strongly typed Model (as it shold be) would be even better.

@Shannon: my only issue with the RenderModel is the extra train cart (.Content). Not sure whether it would be possible to decorate the typed model / published content with the stuff you need instead? Perhaps using extension methods? For that matter, why couldn't the extra data just be set on controllercontext, viewdata or some other contextual container? If it's still just there for future use, it might be an idea to just break it and remove it in 6.2 / 7.0? I'm sure the data you'll need in the future will be possible to provide through some other means.

Re-thinking about it, Having Model != Content seems fine to me. Never know if Model might contain more stuff in the future.

In a strongly typed environment, I'd want CurrentPage to be gone.

Could be replaced by a Content property that would just return Model.Content. For those lazy guys...

I think the very original plan was to have the strongly typed and dynamic model on the RenderModel, and whatever else may have made sense for the current page. At some stage the 'DynamicModel' property was removed from RenderModel and changed to 'CurrentPage' directly on the view... just a syntax choice made based on training non-devs since it would be easier to understand.

So yeah, we have this RenderModel lying around but it could really just be IPublishedContent - of course that's a breaking change and a pretty big one which would mean everyone has to re-code all of their views so I really don't think that's gonna happen. Instead what we could do is :

• Create a new page template class the way we want it
• Override the SetViewData method like we do in UmbracoTemplatePage to change the actual model on the view dynamically to what it should be. i.e. We detect it is a RenderModel and just use it's IPublishedContent instance instead

I'd rather go for UmbracoViewPage<T>, as that means Model is my model, and not a RenderModel. I've been doing it like that for a while when using other plain models passed in from the controllers. To me, using CurrentPage seems like a horrible idea. I guess that might be because I never use it, but always use either Model.Content.GetPropertyValue<T> or custom models.

Making an UmbracoTemplatePage<T> seems a bit redundant when you have UmbracoViewPage<T>, imo..?

@Jesper yup i agree! the only thing though is that to do that you'd have to implement your own custom controller to return IPublishedContent instances as the Model. Currently the default controller returns RenderModel. Of course it's easy to replace the default controller but in the core moving forward we wouldn't have to if we do what I've mentioned above which would maintain full compatibility

From a purism point of view, Model should be "the model". But I guess what's done is done, so we'll live with the RenderModel. Being able to have the typed model on any one-cart train is good enough.

BUT: I just glanced over this page: http://haacked.com/archive/2011/02/21/changing-base-type-of-a-razor-view.aspx
If I'm not mistaken, we can put a custom non-generic view base in views/web.config/pages/pageBaseType, make a derived generic one, and then just say @model StronglyTypedThing in the views. :)
I think we could even just swap it with UmbracoViewPage<T> like Shannon hints at, but it might be an issue with it directly inheriting WebViewPage<T>.

You can do the web.config thing - which is nice for devs to do anyways but we didn't want to muck around with peoples normal MVC installs. But that doesn't solve the issue of our default controller always sending a RenderModel to the view. This problem is solved by either: replacing the default controller with your own to return the model you want (perhaps IPublishedContent), or we create a new view page that has an IPublishedContent as it's Model and override the SetViewData method to change the Model to IPublishedContent from RenderModel.

The potential easy glue to make this work with strongly typed models is to override SetViewData on the UmbracoViewPage<T>, check if viewData.Model is T and if it is not then do a viewData.Model.TryConvertTo<T>. Since the IPublishedContent resolved from the factory should actually be T this will work. Then you can go ahead and set your web.config default view page to UmbracoViewPage<T> - in theory it should just work 

Maybe Umbraco could have two core default controllers and a configuration value close to the rendering engine config to select which one you want?

Not a biggie anyway. Remember my tweet? ;)
https://twitter.com/bleedo/statuses/380658960589930496

We could add yet another config value :)... but i'm pretty sure we can just override SetViewData on the UmbracoViewPage<T> to do what we want which will work for strongly typed IPublishedContent instances from the factory and for normal IPublishedContent instances. 

For example, if you have your template inherit from UmbracoViewPage<IPublishedContent> now, it will throw a YSOD saying something about expecting a RenderModel. But if we override SetViewData, check for RenderViewModel and change the viewData.Model = RenderViewModel.Content, it will just work.

Similarly if you have your template inhertif rom UmbracoViewPage<MyAwesomeModel>, and MyAwesomeModel implements IPublishedContent and is returned from the model factory, then all we have to do in SetViewData is try to cast RenderViewModel.Content to T and set viewData.Model equal to that. This should also 'just work'

With that in place we don't have to modify anything in the core or controllers and UmbracoViewPage<T> will just work for your strongly typed models returned from the default controller.

Ah, I get it. Sounds good!

@Shannon: That sounds like a plan!

Awesome, I've added a task on the tracker: http://issues.umbraco.org/issue/U4-3224

Sweet! Means I can just let go of the "supplemental" project and focus on the styles.
Thanks a lot for a fruitful discussion, guys!

@LE - see http://issues.umbraco.org/issue/U4-3224 and latest commit in 6.2.0 (I understand you're running 6.2.0, right?) ...

@Shannon - if you want to have a look at the commit and validate what I've done...

Yep, running 6.2.
Will check monday. In London over the week-end.

Hi, I'm running a 6.1.6 installations and couldn't get the package up and running.

Is the project still active? What's the current status? Do I need an other version of the package.

Hi nojaf,

I'm not dead yet. :)
If you don't mind, please make another thread in the general forum. (http://our.umbraco.org/projects/developer-tools/umbraco-codegen/general)

Tell me what you're trying to achieve and what doesn't happen. Did you try to "code-first", or do you just want typed models generated?
Do you have uSync set up beside it? What does your configs look like?
There's quite a few quirks to get right to get the stuff working, and I'm afraid I've been too lazy with the logging.

I'm currently knee deep in production sites using it on 7.0 with misc. improvements to the integration. (Using Stephane's internal prototypes)
So I haven't "maintained" the 6.x support for a while, but I'm sure we can make some files appear for your models. :)
You could also try building a debug release of the master branch to see if you can attach and see what happens.
(https://github.com/lars-erik/Umbraco.CodeGen)
It should still be 6.x compatible.

Lars-Erik

On a sidenote for anyone interested, status is currently "working seamlessly on 7.0" with a "nightly" build of usync and a hack exposure of some internals in Umbraco.Core to use the models "automagically" with UmbracoViewPage<T>.

Next up is looking into mixins, and I might drop usage of USync for now and go dirty with core content type apis. (I'll leave legacy support if possible, and hope to go back. It's a nice symbiosis. But stuff is missing from the packaging service.)

No ETA, but hopefully something nice for christmas or new year. :)

Hello Lars-Erik,

Good to hear you are still alive.

I've made a new topic as you requested, we can discuss it further over there:

http://our.umbraco.org/projects/developer-tools/umbraco-codegen/general/46536-Code-gen-general

Thanks for the quick reply.

nojaf

is working on a reply...