I have been working with Umbraco and had some doubts how Document Type classes are woorking in Views.
I knew that when we create a DocumentType, the model builder creates a Class in the App_Data folder. Also, we can refer that class via Umbraco.Web.PublishedContentModels.DocumentTypeClassName in Views. But, it cannot be referred in Controllers.
I am curious to know what technique is making it possible to refer DocumentTypeClassName in Views? Is that using DI, Reflection or something else? Can't we use the same technique to refer the DocumentTypeClassName in Controllers as well?
I might be missing some fundamentals here but I am very curious to know what's happening under the hoods. I would be great if anyone could clarify the same.
The default behavior of models builder is PureLive so its generating the code in app_data and then building an assembly in memory and attaching it to the running umbraco instance . This is what makes it possible for umbraco to know about the models when rendering pages.
if you want to be able to reference views in things like controllers and use intellisense in visual studio then you can change the mode of Models builder (in web.config - see this page for all settings)
Dll Mode : will build the models into a DLL in the bin folder. if you refrence this in your project you will be able to use it in controllers and not have to worry about build errors.
AppData : will build the models into a folder (by default app_data) and then you can include that in your project like any other classes
Models builder generates partial classes - so you can extend without touching the .generated.cs files you can also use the Umbraco.ModelsBuilder.ModelsDirectory setting to move the models out of the appdata folder (which isn't included by default when you compile or build a site) to something else like appcode.
There is also an API mode that lets you build the models from within visual studio (with an extension).
The exact setting you choose will be dependent on how your setup up but i find AppData mode with the folder moved works quite well for simple setups (and is easy to deploy because you just have to copy the folders over when putting it on a server)
Thank you very much for the detailed response. I have read about different modes in model builder documentation. I appreciate your detailed response.
However, my doubt is "what technique" allows using a class on-the-fly. I'll breakdown that further.
My Umbraco site is Up and Running
I created a Document Type which in turn it creates a Class on the fly.
I created a View and start using that Class right away (without restarting the website)
Here, Umbraco knows about the newly created Class and that too without restarting the website. I am curious to know how it's possible to use a class which is created "just-now" and that too without restarting the application.
Is that because of Reflection or JIT? I am missing some fundamentals somewhere.
The magic that allows it to work is similar to the one that allows views to be recompiled without restarting the application.
For views, there is a view compiler that turns Razor files into assemblies, and makes sure that the proper assembly is referenced at the time of rendering the view. So, when you save a view, the view compiler knows it needs to build a new assembly and then use it.
For models, in PureLive mode, we generate code and compile it into an in-memory assembly, and then we hook into the view compiler to tell it to reference this in-memory models assembly. So basically, when the view compiler compiles a view, it knows about the temp, in-memory, model assembly.
And when models change, we tell the view compiler to kinda flush its views cache and rebuild, using the new models assembly.
This is why it works in views, and not in controllers - because controllers are compiled by another compiler which knows nothing about models, and controllers are not re-compiled as the app runs.
How @model reference in Views works?
Hello,
I have been working with Umbraco and had some doubts how Document Type classes are woorking in Views.
I knew that when we create a
DocumentType
, the model builder creates a Class in theApp_Data
folder. Also, we can refer that class viaUmbraco.Web.PublishedContentModels.DocumentTypeClassName
in Views. But, it cannot be referred in Controllers.I am curious to know what technique is making it possible to refer
DocumentTypeClassName
in Views? Is that using DI, Reflection or something else? Can't we use the same technique to refer theDocumentTypeClassName
in Controllers as well?I might be missing some fundamentals here but I am very curious to know what's happening under the hoods. I would be great if anyone could clarify the same.
Any help will be appreciated. Thank you.
Hi
The default behavior of models builder is
PureLive
so its generating the code in app_data and then building an assembly in memory and attaching it to the running umbraco instance . This is what makes it possible for umbraco to know about the models when rendering pages.if you want to be able to reference views in things like controllers and use intellisense in visual studio then you can change the mode of Models builder (in web.config - see this page for all settings)
Dll
Mode : will build the models into a DLL in the bin folder. if you refrence this in your project you will be able to use it in controllers and not have to worry about build errors.AppData
: will build the models into a folder (by default app_data) and then you can include that in your project like any other classesModels builder generates partial classes - so you can extend without touching the .generated.cs files you can also use the
Umbraco.ModelsBuilder.ModelsDirectory
setting to move the models out of the appdata folder (which isn't included by default when you compile or build a site) to something else like appcode.There is also an API mode that lets you build the models from within visual studio (with an extension).
The exact setting you choose will be dependent on how your setup up but i find AppData mode with the folder moved works quite well for simple setups (and is easy to deploy because you just have to copy the folders over when putting it on a server)
Hello Kevin,
Thank you very much for the detailed response. I have read about different modes in model builder documentation. I appreciate your detailed response.
However, my doubt is "what technique" allows using a class on-the-fly. I'll breakdown that further.
Document Type
which in turn it creates aClass
on the fly.View
and start using thatClass
right away (without restarting the website)Here, Umbraco knows about the newly created
Class
and that too without restarting the website. I am curious to know how it's possible to use a class which is created "just-now" and that too without restarting the application.Is that because of Reflection or JIT? I am missing some fundamentals somewhere.
Hope this is more clearer now.
Thanks again.
Hi
I didn't write it so i might be wrong, but i think pure live:
The magic that allows it to work is similar to the one that allows views to be recompiled without restarting the application.
For views, there is a view compiler that turns Razor files into assemblies, and makes sure that the proper assembly is referenced at the time of rendering the view. So, when you save a view, the view compiler knows it needs to build a new assembly and then use it.
For models, in PureLive mode, we generate code and compile it into an in-memory assembly, and then we hook into the view compiler to tell it to reference this in-memory models assembly. So basically, when the view compiler compiles a view, it knows about the temp, in-memory, model assembly.
And when models change, we tell the view compiler to kinda flush its views cache and rebuild, using the new models assembly.
This is why it works in views, and not in controllers - because controllers are compiled by another compiler which knows nothing about models, and controllers are not re-compiled as the app runs.
Making sense?
Thank Stephen, that's what I was looking for. That's for the detailed explanation about the internals.
Now, I know the magic!
Thanks again :)
is working on a reply...