Moving at snail's pace I started creating sample MVC app for printing website like vistaprint. I created a database with three tables, Client, JobType, Job.
Client table has ClientId, Name, Address
JobType is a look up table with types LetterPrint, CardPrint.
Job has clientId and jobtype id and fileformat.
Then created a EDMX file with all the table.
Now trying to create controller. How many controller do I need assuming that I will need to create a Client, and a Job. Job Type table will be updated using sql script?
I guess 1 controller for Client and Job each .
How many views I will need?
I think 3 for each of client and job. List, Create(update), Delete(readonly mode).
Am I going in right direction?
Thanks in advance.
In suggestion that there be a some person (administrator or someone) who will create clients and create jobs asked by client I'll build such views:
Jobs:
List of jobs. Can be filtered to show jobs asked by one client. One view, filtering happens in model/controller. There must be additional usually empty string about criteria of filtering. Of course, paging and another features should be enabled.
Create job. Client id can be setuped before rendering view (when it was linked from some client). If not setuped, we must provide autocomplete search by client names. How it looks: admin types client name and in down, in some div with ajax list of clients loaded. So there must be one another action that returns filtered list of clients in JSON.
Edit job
Remove job.
Clients:
List of clients. Paging, sorting, filtering. At each client must be link to jobs asked by client and link to create new job;
Create client
Edit client
Remove client.
If client can login and ask for creating new job, there are must be additional views:
Register page
Login page
After login client must see only his jobs and their status and perhaps dunno about possibility (and have no such possibility) to reset filter. Perhaps, there can be special view for that, but I guess that there is need only in different filter setting in index action of jobs controller.
Special administrative actions must be marked with AuthorizeAttribute. Of course, there are a lot of possibilities to done it, but I think that this is nicest. Questions?
Related
Based on the examples from the Internet I made this database, but I have some problems using it
How should I add ExtraItem to the order?
For example if I put in my orders a food item then I send a POST request to the server which returns a new created entry. What should I do next in order to add an Extra to that order? I have FoodItemExtraId but I don't know the OrderFoodItemId to make a POST request to OrderFoodItemExtra table.
Or maybe this schema is not correct?
I started to develp a new project with CQRS/ES. As I understand, one command raised a new event. So, I developped a web api with one action mapped to one command.
List of api action :
[Route("api/user/create"), HttpPost]
public Task<IActionResult> Handle(Commands.Create command)
=> HandleCommand(command);
[Route("api/user/update/name"), HttpPost]
public Task<IActionResult> Handle(Commands.UpdateName command)
=> HandleCommand(command);
In my IHM project developped with Blazor, how to communicate with the web api ?
Foreach change in a textbox, i send a http post ?
it's not really a best solution.
I prefer to add a submit button and send one http post. For this solution, how do I communicate all of user's action to web api ?
I would strongly suggest you to take a look at concepts like DDD. The first thing you have to do is get a clear understanding of your Domain.
Let's say that you're working on a Product Inventory system. In your Blazor app you might well have a "create product" page, containing a form with all the relevant fields (eg. "title", "description", "price" and so on).
The backend would expose a POST endpoint /products accepting a CreateProductDTO (check what a DTO is if you're unsure). The DTO would then be mapped into an immutable command, which will then get sent to the relative handler.
The idea is not to send every single user interaction to the server. You have to make a map of the possible actions exposed by your Domain and work your way up.
I have a simple asp.net web application project. Which has an order.aspx page showing different items. I have managed to show those items by outputting in
page_load event.
Now I am using JQuery to load item details from the database and show when the user clicks on the items.
This is the JQuery I am using
$(".item").click(function(){
$.post("Lookup.asp",
{
Id: $(this).id
},
function(data, status){
alert("Data: " + data + "\nStatus: " + status);
});
});
Now I want to know how and what is the best way to setup the backend part to provide the data. Currently I am thinking that Lookup.aspx page on its page load event will receive the id from request object, I query the db populate the data and send it back through the response object. I am not sure if this is the right way of doing it.
I have not set this yet, because I was thinking if we create a separate page to do this then I will have to create more pages for other type of queries (I will have different queries like checking for status of an item in db).
Another problem I was thinking with this approach will be that there will be pages which are just serving the data and we dont want to show them to the public. If someone will have the name of the pages they can access them which we dont want.
And I am using Entity Framework it that matters in anyway.
For the Web Service part. The best and easiest way to go is WEB API. Just write a controller method and it becomes a web service which returns json or xml.
Using Web API with ASP.NET Web Forms
Now about the second part is tricky.
IF your users are not logged in then , the method has to be public in order for someone to have access . So either through ajax either from just having the url someone will and must be able to access the method.
A way to tackle this , is to encrypt-decrypt your product ID's .
Or use authentication on web api.
https://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api
I am working on a web app (using webForms not mvc) that takes user input and adds it to a database table. This app will be available to users in a dev, qa, and production environment hitting each environments own database.
Currently, I have a promote button that works by connecting to the QA database from Dev or the Prod database from QA inserting/updating the data there and then redirecting to the QA/Prod version of the app.
Instead of doing it this way I would like to save myEntity in a variable and send it with the redirect. I'm thinking something like this:
MyEntityType myEntity = UserInputData();
Response.Redirect("myQAurl", myEntity);
Then in my QA Page_Load have something like:
If( fromDev ){
loadPageWithMyEntity();
}
By doing it this way I hope to prevent QA/Prod database connections directly from dev --> QA or QA --> Prod.
If passing an Entity wont work I could also use an array, list, etc.
When doing a redirect:
Response.Redirect("myQAurl", myEntity);
The way that works is that the server basically tells the browser to make a GET request to the supplied URL. Which means that any information sent over that redirect has to be in the query string on that URL. So you would have two options:
Include a bunch of key/value pairs in the query string which can be used to re-construct the entity on the other end.
Serialize the entity to a string and have one key/value pair with that as the value, then de-serialize to the entity on the other end.
If the entity is large, this could be problematic. There's a reasonable limit to the size of a URL in most web servers.
For large entities, to truly transfer from one system to another where they don't share any back end you would likely need a POST request. Which can't be done with a redirect. Instead, you would show the user a form (which could be entirely hidden and invisible, so not necessarily shown) and the user would have to post that form (which could be done with JavaScript, so not necessarily the user posting it).
Beyond those, you're likely looking at a back-end hand-off, such as storing the data in a temporary database location on one system and consuming it on the other.
Please consider the following scenario,
There are two web applications App1 & App2. A user would submit his information on App1 though a form. On click of a specific button/link on App1, the same data should be posted to a page on App2 and the user should also be redirected to the same page on App2.
I would like some help in finding out the best way to implement this functionality.
One of the approaches that I have already tried out is by creating a temporary HTML form at runtime, setting the action attribute of the form to the App2 Page and get the form posted by using javascript submit. The data can then be fetched on App2 page by using the response.form object.
This approach works well, but i was still wondering if there is any other way to implement the required functionality.
I would really appriciate if you can give some insights on using RESTful webservices to implement this, or else, using some HttpModule to intercept requests at App1 and modify redirect response to app2 or any other approach that you might find fit for the purpose.
Edit:
Using querystring isnt an option for me.
I've had a need to do similar things with feed agregation and building rss feeds from web page content on different domains.
User Gets app1 page, fills in details and submits then on the server for app1 I have a method that looks like this ...
HTMLDocument FetchURL( string url )
{
WebClient wc = new WebClient();
string remoteContent = wc.DownloadString(url);
// mshtml api is very weird but lets just say you have to do things this way ...
HtmlDocument doc = new HTMLDocument();
IHTMLDocument2 doc2 = (IHTMLDocument2)doc;
doc2.write(new object[] { remoteContent });
return (HTMLDocument)doc2;
}
This function does 2 things of use ...
It gets the page of content at "url"
It parses that content in to a HTMLDocument object
Once you have this function you can then call it passing it the url to the remote page and get back a html doucment.
The functions in the HTMLDocument object will allow you to do javascript like dom queries such as :
docObject.GetElementById("id");
I then have different functions that do different things with this object based on the page / site i'm returning data from.
There is however one fatal flaw here ...
This is likely to work really well with sites that don't change much in structure and are built by code but not so well on less dynamic sites.
With stackoverflow for example its easy to pull out a question and the accepted answer for that question so I could use this code to pull and publish content from here on my own web site.
However ...
This is not going to help you for user / login related details as this sort of information is not shared to generally everyone.
It's bit like me going and trying this to link facebook profiles to my own website, I would have to go through some form of api that asked the user to authenticate their details before making the request.
simply pulling a web page based on a url only will give the other site no authentication information unless that site accepts the user login details in the quesrystring and you already have them.
You may however be able to chain requests by ripping apart my sample method, requesting the login page parsing the results, filling in the form, then posting back using the same web client instance to login then requesting the url.
The idea being that you would have a form that asks the user to put in their login details for the remote site on your site then you go and find their profile page based on that.
This would be best farmed out to a class rather than just a simple method like i have here.
In my case though i was only after something simple (the bbc top 40 uk charts) which i pulled information from not only the bbc but places like amazon, google, and youtube, then i built a page :)
It's neat but serves no functional purpose other than pulling all your other fave sources of info on to 1 page.
If you are already committed to using javascript, then why not an ajax post, and change the window.location based on the response?
You can use HttpServerUtility.Transfer this will preserve your form contents and transfer the user to the new page.
http://msdn.microsoft.com/en-us/library/system.web.httpserverutility.transfer.aspx
I have built something like what you are describing, and I found that using a <form> tag to POST to app2 is the most reliable way... basically, the way you found that worked well.
If App2 is residing on a different domain, it's usually best to create your own interface for the submission, and have that interface handle the posting from App1 to App2.
(Browser) -> Submits form to App1 ->
(App1) -> validate input
-> stores local info
-> creates an HttpRequest/POST object
-> posts to App2
(App2) -> handles the post
<- returns the response
-> confirms the results of App2
<- returns the results to the browser.
In essense, you want to control and proxy requests from your Applications domain to any outside interfaces as much as possible.
Note: I'm answering my own question
just to have a correct answers marked
against it. All the suggestions
provided by various members here are
correct in their own way, but they
were not apt for my requirements.
Hence, I cant accept any of them as
correct.
The way I have Implemented is by creating a custom control which would have a configurable property containing the URL to post data and another one accepting a dictionary object as the data input to be posted.
This control would internally create a HTML form with action attribute set to the URL specified by the user and have the data feilds created out of the dictionary object. This form would then be posted on the button click event on the page hosting this control.