I have been searching for this ages for a clear solution for sending emails with email templates from embedded source files and still I haven't found a clear answer to this.
Razor views are really nice to use as a template for emails.
I am trying to to create a class library as a package that will contain views(cshtml files) and models for each view. That class library will also have a service as EmailSender.
Then that class library will be referenced in a web application to send emails. The library obviously be re-usable in other projects.
EmailSender service will have methods for each email types. The web application will pass the model and class library will prepare the email content (parse the model into view) and return the string content. That string content will be sent as htmlbody email.
I have looked at this RazorLight library. This doesnt seem to be completed or updated for core 2.0 yet.
Another solution I came cross is here. The issue with this approach is that email templates do not contain model properties. Basically, templates contain {0}, {1} etc and format is used to parse the model data into template. If there are a lot of parameters in the template it would be hard to remember which parameter is which.
I just recently seen this article ASP.NET Core 2.1.0-preview1: Razor UI in class libraries
It tells that Core 2.1.0 will enable to add views in class libraries. Would this be the solution?
Or do you have any better idea to achieve this?
I was also working on this type of problem and didn't find any solution on the web. So after some research I succeed to implement this kind of solution and wrote a blog. You can check the link below if it fits your solution.
P.S. Using Razor UI in class libraries may be a possible solution, however I haven't try it yet.
https://medium.com/#ognjanovski.gavril/net-core-email-sender-library-with-razor-templates-cshtml-contained-in-it-71c48bef1457
Related
I am new to Django and API creation. I am trying to figure out if it is better to use djangorestframework or just use JsonResponse. I got the suggestion of djangorestframework from Digital Ocean's tutorial but also found out about JsonResponse, which seems simpler given that I don't have to install another package.
Goal: I would like to be able to provide user information for both web and mobile applications.
I see that there are some reasons provided on this post for djangorestframework, which I pasted below for posteriority.
The common cases for using DRF are:
1)You're creating a public-facing external API for third-party
developers to access the data in your site, and you want to output
JSON they can use in their apps rather than HTML.
2)You're doing mobile development and you want your mobile app to make
GET/PUT/POST requests to a Django backend, and then have your backend
output data (usually as JSON) to the mobile app. Since you don't want
to pass back HTML to the mobile app, you use DRF to effectively create
a REST API that your mobile app can call.
3)You're creating a web app, but you don't want to use the Django
templating language. Instead you want to use the Django ORM but output
everything as JSON and have your frontend created by a JavaScript MVC
framework such as React, Backbone, AngularJS, etc. In those cases, you
can use DRF to output JSON that the JavaScript framework can process.
DRF basically provides you many features to make APIs that you don't have in raw django.
for example:
Serializers: a declarative way(django style like declaring models) of making serializers, when you use JsonResponse you have to tell everywhere what to serialize, with the serializer you have to import it and just use it, also this serializers can be able to save/update objects too. Also support ORM source to connect yours models(think how difficult would be serialize a model with nested relations with JsonResponse).
The Web browsable API, you can see all the availables endpoints.
Third party packages to install and use: https://www.django-rest-framework.org/community/third-party-packages/#existing-third-party-packages.
Do any of the front end frameworks (Like Vue.js) have the ability to generate a prototype form/view directly from various an Endpoints?
I am wanting to quickly knock up a few forms to capture and submit data to a set of JSON Rest Post APIs and Display pages to render data retrieved from other JSON Rest Get APIs.
I don't want to have to go through the pain of having to map each and every field out in a set of .js file, it would be great if the boilerplate could just be generated from interface in a similar way to what Apache Isis does from a Domain model.
The above would allow me/clients to generate a UI directly off the interface and interact with it using a web browser in a similar way one would using Postman, without having to install and understand Postman.
You can try one of these:
https://vue-crud.github.io/
https://github.com/dionmaicon/vue-crudgen
https://github.com/ais-one/vue-crud-x - described in https://codeburst.io/vue-crud-x-a-highly-customisable-crud-component-using-vuejs-and-vuetify-2b1539ce2054
https://api-platform.com/docs/distribution/
I recently started learning to create restful web services with spring framework.
all the course is using postman to send requests but I want to send requests from a web page, like creating a table and send firstName and lastName from the HTML file (from the view, .jsp file) and store it in the database.
everywhere I lookt, they all saying the standard file to send to or retrieve from a restful endpoint is JSON, not HTML.
and from what I see #RequestBody only accepts JSON or XML, not HTML inputs.
I tried sending data from HTML(Method = "POST") to a #PostMapping method of my restful web server, to create something and store it in the database but an exception that says "Content-type not supported" was thrown.
I have lots of questions about this, and they all point to the same thing, Not understanding the whole thing.
what's the point of creating restful web service for the back end of a website, when HTML doesn't support put and delete requests and standard file that everyone uses to get requests from the client is JSON, not HTML.
can a web page (HTML) generate it's content to form a JSON file that is being sent back from a restful server?
how can I generate a JSON file from the inputs in HTML file and send it to the restful #PostMapping method?
there are two things that I should mention here,
I don't know much about creating web pages (HTML) I have only been creating very simple HTML files to help me create and test a back end server.
I searched so many questions before I post this one, and none of them helped me.
I will try to answer your questions
First, you need to understand what rest is it is a Representational state transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services.(https://en.wikipedia.org/wiki/Representational_state_transfer)
so we follow a set of standards to make things easier.
Now coming to your actual question why JSON and not HTML because these are not only consumed from HTML these are consumed by different apps or services and json is a more lightweight and less verbose format, and it’s easier to read and write as well. In most cases, it’s ideal for data interchange over the internet
and we can use it with front end libraries like react , jquery or vanilla javascript to render the content in HTML from JSON without any changes to the API and also use a Backend web service to use this API.
https://api.jquery.com/jQuery.getJSON/
https://reactjs.org/docs/faq-ajax.html
for the other two questions basically You don't have to generate JSON file to call the rest API from HTML and render the content in HTML Instead you can use front end libraries like Jquery, React, Angular or use vanilla javascript to render content and call the rest API.
I have always worked with Web APIs, so I don't know how to handle this very basic problem in .NET Core MVC (I am only familiar with MVC conceptually). My problem:
I need a user to select an option from a dropdown on the front end and then show some data based on the option (after fetching it).
If I were writing an SPA consuming an API, I would simply make a call to the backend to get the data and then generate the html to display it on the front end.
How is this handled in MVC? Isn't the convention to return entirely new views? How are things like these handled?
I just need a pointer in the right direction conceptually - I can figure out the code.
Edit: Should I just pretend it's an SPA despite it being a view and create an API endpoint in the same app that provides the view and consume it from the cshtml?
It works exactly the same way. You make an AJAX call to fetch some data. You can either return the data directly, and utilize JS to render the HTML or return HTML directly. Either way, you use the AJAX callback to replace the appropriate content on the page.
Even in older ASP.NET MVC projects it worked this way, though you basically had to decide whether you were going to use an MVC controller or a Web Api controller to do the work. Either would work, but there were advantages/disadvantages to each approach. MVC/Web Api could always coexist in the same project.
In ASP.NET Core, the difference is purely semantic. There's really no such thing as MVC and Web Api anymore - just ASP.NET Core. A controller is a controller is a controller, so just add an endpoint and go to town.
Like some of you allready know, i'm trying to get data from facebook in JSON format and view it in a gridview or something like that.
With some help of StackOverflow, i managed to get the data i needed.
Now I want to make a List of my json string.
Do I have to make a class for every JSON object in my json string? Like the class user, location, work_info, education_info?
Is there any place where i can find the c# class files for all the facebook objects?
I think there are a lot of programers who use these classes, does everyone write the same classes again?
I have added a reference to the facebook(.web) sdk. But I don't know if I can use this for my problem.
I hope you can help me,
Thx!
The reason why there are not strongly typed classes for Facebook Schema in the Facebook C# SDK is that they usually change very frecuently. That's why the developers of the Facebook C# SDK decided not to go that way:
http://ntotten.com/2010/08/dynamic-csharp-with-frequently-changing-web-services/
http://ntotten.com/2010/09/dynamic-objects-and-the-facebook-c-sdk/
Although if read the Roadmap: http://facebooksdk.codeplex.com/wikipage?title=Road%20Map you will see that there are plans for a strongly typed Graph API objects but it looks like there is no much activity in that area.
If you need strongly typed classes for your app, you will probably only use a few that are easy to create.