I am building an app that consists of a number of plugins. The app and the plugins are built around the service stack framework including the razor engine.
One of the problems I have is that I have to set all of the files to copy always, the final app ends up with a mashup of files from all the plugins. It works but doesn't make it easy to add/remove plugins - ultimately I would like to do this whilst the app is running.
I found razorgenerator which looks like it addresses part of my problem and would precompile the microsoft razor pages into the dll. Has anybody done anything like this with the service stack razor files?
It wasn't really designed for it, but here's an example of using ServiceStack to render stand-alone razor pages.
You could also use another tool like razorgenerator or RazorEngine though this is disconnected and doesn't have anything to do with the Razor support in ServiceStack.
Related
I want to create a progressive web app with ASP.NET CORE 2.0 using Razor Pages preferably because I like the code behind architecture of Razor Pages.
Please recommend me a tutorial or docs or any course where I can begin to learn this. I already know ASP.NET CORE so I don't need to learn that, but actually I want to learn and create PWA but at server side I want to use ASP.NET CORE 2.0 and Razor Pages (if possible). And then I will be hosting them in Azure.
The courses I've searched so far on the web, all of them are with node.js or any other server side technology. Which is a problem because I don't want to use JS, except on the front end, where I don't have a choice.
According to your description, I assume that you could refer to the following tutorials for getting started with PWA using .NET Core:
Yeoman PWA Angular 4 & .NET Core
PWA-Asp.NetCore
Building Progressive Web Applications (PWA) with Visual Studio
This is a very common misconception...that the client-side is tightly coupled to the server-side. They are not.
Your ASP.NET application renders pages/html on demand, at run-time, on the server. The site will work with or without the client-side code, that is why it is progressive....
Your PWA/Service Worker code is only concerned with stuff in the browser. You need to think about it as a stateless concern on the client. The service worker can add a proxy layer to the client-side where you can cache and really perform the task ASP.NET or Node Or PHP, etc perform, just in the browser, before the network must be used.
My advice, to learn the concepts, is to create a static version of your site or a test site. Get comfortable with how to make a PWA and a simple caching service worker, then apply it to your ASP.NET site.
There is nothing in ASP.NET itself your service worker needs to know about, well short of your routes. And your routes are independent of ASP.NET.
We should make a decision in our company what architecture to use in new web project. We've already successfully used DevExpress' WPF components and thinking of buying their web products, but don't have enough experience with them. So, the next question is for people who have some experience with DevExpress' web components.
Could we start the solution as standard MVC project built in VS 2013 and then add DevExpress' MVC extensions such as data grid etc. and DevExtreme components (jQuery or AngularJS) as well? If we can do that, could you explain, please, what could be possible difficulties?
I think it isn't a good idea to mix up server-side DevExpress Mvc Extensions and client-side DevExtreme Widgets. If you are comfortable with asp.net mvc and want to use client-side javascript technologies, look at DevExtreme Mvc Wrappers.
It supports a convenient razor syntax to configure widgets. And you can use javascript to handle events, implement client-side templates etc.
To see how it works in action, refer DevExtreme demos.
VS2013 update 5, MVC5 using Areas
I have a stand-alone function programmed for a website. The functionality is a specific user interface to collect survey responses in a particular way. It has several controllers, a model and a group of views. The functionality is completely contained in an Area of the project, except for the Shared _Layout file that provides the main menu for consistency.
'Is it possible for me to' / 'how do I' compile this Area into a single or set of .dll file(s) that I could then add conveniently to other websites? I'm assuming creating something for transfer/download is very standard functionality. For example, I used Elmah.MVC for this site. What I want to do is pretty much create a package that can be downloaded in a similar way to how we integrate Elmah.MVC into a site. (Be certain I'm not talking about creating error logging software, I'm only using Elmah.MVC as an example of software that is easily integrated into other website applications.)
I've never compiled any website functionality into a .dll(s) for use elsewhere and would appreciate either some specific guidance, or perhaps what would be easier is to provide a link with a good step by step tutorial or explanation for how to do this. Most of what I've found on the web describes bits and pieces of doing this, but it's not enough for me to feel confident with it.
It seems to me there are a lot of 'moving parts' to taking a particular piece of an MVC application and turning it into something that is easily added to other projects.
A particular issue I don't quite grasp is the difference in downloaded packages between getting code and getting just the .dll(s). For instance, when I download an MVC5 site, I get controllers, models and views, but when I download Elmah I get a .dll and no code files. Also, I do understand the concept of transforms, but I'm just struggling right now with even getting from my programmed application into a 'package' regardless of the transforms that make it easy to integrate into another website.
These are just some of my questions I have about how to perform this particular process in developing deliverable and/or shareable software.
What you are looking to do is create a portable MVC Area project. A Portable Area is a set of reusable multi page functionality can be dropped into an application to provide rich functionality without having to custom build functionality that is literally the same in every application. An MVC Portable Area is really just a dll that contains the views, controllers, scripts, etc… needed to use in a website that is either a Web Forms website or an MVC website. A developer can use them for a reusable widget or a complete engine. I have actually used them for both. Here is a link with some basic info to get started. http://elegantcode.com/2012/04/06/mvc-portable-areas/
I have used several solutions like Berkelium project, CEfSharp, awesomium.net, The Web application i built constitutes of Javascipts, xml, CSS. When I used these solutions for files published on server they properly work out but when i give path like (file:///path) it stops responding.
Depending on your needs as alternatives to file:// maybe look at either:
Implementing a SchemeHandler as showcased by both the CefSharp.WinForms.Example and WPF ditto.
Maybe even an OWIN married with CEF implementation, like Harley
or see this other answer: Ajax not working in CefSharp based WebView with local files
I´m learning kohana for the first time and need to know some basic facts about the mcv principle.
Up until now i´ve only used Javascript frameworks (ext, openlayers etc) which are referenced in the headers of html pages. The classes are then extracted and used in applications. I can have as many separate applications referencing one Ext.js framework installation as I like.
Kohana,as an mvc framework, is obviously different, but which purpose does it fullfill? Is it used to create web applications inside the Kohana installation ie. one web application...or is it used to create an endless number of applications? As far as I can see, one downloads the kohana framework, and adapts/extends the framework to make an application..e.g. a web cms. Am I on the right lines?
cheers,
Rob
The Kohana framework is typically used to build a web application. You would normally use one Kohana install and work with that to make a web application.
You could if you wanted, install Kohana centrally in somewhere like /usr/share/Kohana
Then you would move the application folder out and set the update the paths in index.php to the right places (there is a system path, module path and application path).
MVC allows is a design pattern for separation of business logic (model), controller (uses the model to get data and pass it to the view) and the view normally is what is outputted to the browser (HTML). You can read more here
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Yes, typically each web application has its own copy of a library. So, one copy of Kohana is extended to one web app.
MVC is a pattern that is common in web frameworks. It leads to better code reuse and lose coupling among different parts of the app.