In our application customers can design their ui on their on. For this we load the generated XAML at runtime.
We use MvvmLight as Mvvm Framework.
But I'm not sure what the best way is to get some kind of a dynamic view model.
So if the customer wants a new Datafield it should be aviable in the model.
My idea is to dynamically generated and compile a model assembly or to have converters which get their data from a Dictionary which is placed on the viewmodel.
Are there any better ideas, or some experiences and how to solve this best ?
Related
Despite I google-d for some time I couldn't find any of the Model-View-XYZ framework implementations for server-side Blazor, that is Razor Components (XYZ stand for any of the following: Controller, Presenter, ViewModel).
If anyone knows of such an implementation, no matter in what stage of development it is, please let me know. Thanks a lot in advance.
EDIT: The question is if someone has encountered, or takes part in development of such a framework.
The question is absolutely simple - has someone encountered some info on the Internet about such a framework targeting Razor Components (aka server-side Blazor), since I haven't so far.
I'm not 100% sure what your question is so I'm taking a stab at what I think you're asking.
It's important to understand that Blazor is not opinionated about how you choose to structure your code. The team have been very clear that they will not force any patterns on developers. This means that you are free to structure your code how you feel is best.
If you're interested in MVVM for example, Jeremy Likness has a great blog post covering using this pattern in Blazor apps. But if you are looking for official docs covering this then you're out of luck.
Hope this helps, if not please clarify what it is you're looking for.
Blazor itself is an MVVM framework. The HTML in your Razor Component is your View. The #functions section is your ViewModel and you can use POCO classes for your Models.
I released HanumanInstitute.MvvmDialogs as a platform-agnostic solution to display dialogs. It's currently implemented for WPF and Avalonia.
Blazor support could easily be added by copying from the Avalonia branch. If someone wants to take on that task.
After reading about it I implemented this MVVM design for Blazor Webassembly + WebApi app. A ViewModel is injected as transient into the View and the View calls the ViewModel's Initialize() which causes updates to ViewModel's properties which fires property-update events which are handled by the View to update the presentation state. The ViewModel also handles user actions that come from the View. ResourceApi is injected as singleton into the ViewModel which subscribes to resource-updated events. Model caching can be implemented at the ResourceApi layer. An action that updates a resource raises a resource-updated event which causes the ViewModel to reload the data and in turn raise its own property-changed event which is picked up by the View to update the presentation using binding.
I don't get completly the architecture of Titanium Alloy. Maybe someone can explain it better or draw me a picture? :)
What I understood is that it is a mvc architecture but not in the "basic" way... The Model is only a blueprint for the intern SQLite database. The Backbone Model also can be extended to check for correct input and duplicates. To synch with the extern the Controller is used. At least all the examples I found did that. And the View is basic with Titanium Style Sheets.
Unfortunately you have a very terse, incomplete understanding of what Alloy is, what it does, and how it does it. Fortunately for you though, there's is extensive and complete documentation that covers all this in guide form. Answers to all these high level architecture questions and more can be found here: http://docs.appcelerator.com/titanium/latest/#!/guide/Alloy_Framework
Well Alloy is indeed a framework that is based on the MVC architecture, maybe what you need is to get some insight on the design goals of MVC and how they can be achieved using the separate roles for each unit of software. Here is a very good article I would recommend: http://blog.codinghorror.com/understanding-model-view-controller/
The fact that you can specify view structures using only xml files and styling using only static properties means that Alloy is a very well implemented MVC framework as it does not allow you to mix the responsibilities of each role.
My 2 cents of understanding Alloy:
controller.js
Here place only code that handles ui element events such as clicks, taps and so on. Your controller should pick up an event and call a method belonging to some external common.js module that you should require using require(). It is fully supported in Alloy.
view.xml
Here you only specify the tree structure of your ui elements. This means what component belongs where and to which other component.
style.tss
Here you should specify anything that has to do with colors, position, layout etc.
On My project i'm using ASP.NET MVC3, and my backgound comes from traditional asp.net, my question is related "comparing with asp.net webforms" with the inheritance that is possible on codebehind.
What I intend (in mvc3) is to have a couple of extra properties available on all views of the application.
Is it possible to add my extra properties to my views or I need to use the "Helper way" as a work around?
Notes that my question is not at the model level, but for the view (UI).
Sorry forgot to mention that my viewengine is Razor
If your extra properties are meant to be UI specific, then you can define a master page and use that on all of your view pages. If they are meant to be value properties, then you can create a base model and inherit that in your model classes, which then will be available to all of your views using those models. If none of these are feasible for your purpose, then you might try extending System.Web.Mvc.ViewPage, but I am not sure if it would be a best practice.
Yes, by default MVC Views inherit System.Mvc.ViewPage. If you are using a strongly typed view, then it's System.Mvc.ViewPage<model> where your #model declaration is pass to the generic ViewPage<> class.
While it's possible to inherit from a derived ViewPage, it's not typically done. Depending on what you want to do, there is likely a better solution.
Perhaps if you clarified what you are doing, it might help us help you more.
So the way I've always worked with MVC in .Net is to create ViewModels for each View.
Now, with using Knockout, would I create my ViewModels in javascript instead of a C# class? And then have my main Model(in this case, EF generated Models) as my only C# Model classes? Or would I still go about create a C# ViewModel class along with my Knockout ViewModel?
I'm trying to set this project up DRYly, but I'm not sure of best practices in this situation.
You can create viewmodels (VMs) for the C# server side and still have them intended for the ASP.NET MVC Views. Then create VMs for the client side javascript views too. But the way I;ve liked it best is to use the MVC Views as the basis for the page, and have the Models be the basis for the JavaScript models. The only VM would then be the JavaScript VM since most of the presentation is really done client side. In other words, do the more static plumbing in MVC, then do the dynamic interaction client side.
If you are building primarily using client side JS libraries like KO I would not start with a VM for the MVC side unless you have a strong reason for it.
If you have specific questions, I'd be happy to try to help.
Create view models as you always do.
Create a HTML helper which generates a KO view model from it.
You should base your Knockout viewmodel on the view data from the server in order to at least have it initialized with data from the server without having to make a separate request to get that data.
You can optionally use the mapping plugin to map the view data to your viewmodel.
I have a custom view engine developed internally. In the same project, I would like to use Razor for some pages and my custom engine for some pages. How does MVC framework choose which engine to use? BTW, my custom engine does not require any templates, it renders pages based on meta-data from database. For my custom engine I don't want to setup any template files.
What I am expecting is there should be a way to drive framework to use certain engine based on the controller name and action name.
Is this flexibility exists in MVC3?
Your view engine should implement the IViewEngine interface. After you registered your view engine with the ViewEngines.Engines.Add() method, the MVC framework will call FindView and FindPartialView whenever it needs a view engine to render a view.
It's absolutely possible for multiple view engines to operate side by side. If you don't want your view engine to be used in a specific situation you return new ViewEngineResult(new string[0]); from FindView or FindPartialView and MVC will choose another view engine. If you do want your view engine to be used you return a valid ViewEngineResult pointing to the view class (that is implementing IView) that you want to Render the result.
There are some specifics with the useCache parameter. If you want to know more, there was an excellent presentation on building your own view engine at TechEd 2011 by Louis DeJardin. You can find the video of Writing an ASP.NET MVC View Engine at Channel9.
I think the easiest way would be to implement a IViewPageActivator, http://bradwilson.typepad.com/blog/2010/10/service-location-pt11-view-page-activator.html and http://msdn.microsoft.com/en-us/library/system.web.mvc.iviewpageactivator(v=vs.98).aspx.
I think that returning null from the Create method will make it later default to the default IViewPageActivator. You inject it in the DependencyResolver, http://bradwilson.typepad.com/blog/2010/10/service-location-pt5-idependencyresolver.html.
It might be easier to use if you are using a dependency injection framework as NInject or Unity.