I've asked this before but I was hoping for another answer and perhaps some code samples because I've been having a difficult time with this. I have an asp.net page. The user hits the "Run" button and I have code IN AN ASSEMBLY, not in the APP_CODE folder that is called and runs a long process that moves product info from a file into the database. While the user waits, I would like them to see status updates like what product the import process in on and status info. I'm assuming I'd break off into another thread and use Ajax but I have no idea how to do this. Some code samples would be very helpful, thanks.
A simpler way to do this without needing to go into multi threading (which can cause all sorts of nasty, hard to track down bugs) is to use AsyncResults in .NET and AJAX which allow you to query a process.
A good example to start you off can be found here.
found it by using HttpResponse.Flush
Related
I know this question has been asked before..a lot in fact. But I can't seem to get the wheels turning on this thing. To be honest I'm a bit lost on mating client side and server scripting and the examples I've seen are either far to simplistic or way above my head.
Goal:
My goal is to take a long running process I've writtin in VB.NET on the server, which happens to be loop based, and calculate a percentage complete (I know the range of the index values) and relay that back to the user by some means.
Idea:
As the loop iterates I want to pass back up to the client an integer of percent complete or poll it from the client.
What I've done:
Is very limited, I have little to no experience here, I've been doing a lot of googling and I've played with the UpdatePanel and UpdateProgress controls from AJAX a bit, but this method so far seems to lean towards an idicator, like GIF.
As always any help is appreciated, and if I can answer any questions I will.
Have you considered using an inline frame (iFrame) to host your long running process and report back status to the client via the Response object of the long running .aspx page?
If so, then I suggest you read Easy incremental status updates for long requests.
The example uses a button as the display for the progress after the user clicks it, but you could direct output to another DOM element if you wish.
How can I read a web site's data automatically at a special time? For example, I want my site to be able to read any newspaper's articles automatically each morning. My mean for doing so is reading any another website's data each day automatically.
Have you done enough brainstorming on what exactly you need to implement. I think you need this
Run code at specific time c#
Now google it. Where does the first three links point to??
Once you have this then you need to look into what design best suits you. You can have this timer logic in your server side code , or create a window service which pulls the news feed.
Actually you can implement this without a timer by creating a 'scheduled task in windows'.
I have been set a new project at work and have been given the code beforehand to give it a good look. Since time is limited, can anyone please give me the best way to get a good feel of the project. What are the things I should be looking for within the code?
Thanks.
Well, first I'd get the app running and get a sense of the functionality (the business functionality) of the application. If you're not familiar with the business functionality, keep notes on your questions.
Next examine the code. things like:
1. Database access methodology (ASP.NET Core, Linq2SQL, EF, NHibernate etc.)
2. Take a look at the database and the data model
3. Examine the areas you're not comfortable with in regards the ASP.NET/C# etc.
Keep a note of questions you have through this phase. If they want you to hit the ground running, you'll need your questions answered. Asking the right (intelligent) questions shows you've spent time examining the code (as they would expect)
Set a breakpoint at the page_load or init event handler of a page of interest and step through the code (F11) to see where it goes and what it does.
We are in the process of designing a web site were users can fill an application form and submit it. Once an application is created, it goes through different departments for review.After each review, the department persons log on to the website and update the status of the application. Once review is completed, the application is said to be 'approved'. Also, communication(email) is sent to the applicants updating them about the status of their application.
I am thinking of using Windows Workflow for this application, but am new to it.
Can anyone tell me if it would make sense to use WF for such an app..or would it be an overkill..I was thinking of using a State machine workflow, as each application created goes through different states. One of my major concerns is, this process also involves manual work such as reviewing the application(this could take days) and then updating the status(say by clicking a button on the website). Can workflow handle this kind of thing?
I have gone through many websites, but they talk about very basic examples where states change automatically.But in my case there is a lot of human interaction.
Any help is appreciated
Thanks!!!
Here is a sample on MSDN that describes a very similar workflow that you've described - although they use a Windows Forms client rather than a web client - but those details shouldn't matter given the use of the Workflow Runtime.
I would say that your situation would be well suited to Workflow - long-running workflows are supported by having the runtime automatically persist workflow details at certain points while it runs, so steps that take days or weeks to fulfill are perfectly fine.
"my case there is a lot of human interaction".
That's the easiest kind of thing to build. It's just transactions.
Each stage in the process is a simple web application.
Fetch all items that are waiting at this state. Display them in a list. User picks one.
Display that piece of work. User makes changes. Saves it. Some change will move it to the next state. It's still just an update.
That's it. Nothing fancy.
You just need to very, very clearly define each state.
You must have a simple query that finds work in this state.
You must have a simple update that moves work on to the next state.
The states must be very, very clear and simple definitions. One column with a state name, for example.
The state transition rules, however, may be complicated. If the work is highly manual, it may be as simple as a drop-down list of available states.
If the state transitions are complex, then, perhaps you need something more sophisticated to embody the transition rules. But since it's manual, you don't need much.
Do I need a separate workflow instance for each application created?
I don't know what this can possibly mean. Each "application" that's moving through the pipeline of manual processing steps has a "state" -- the step of the pipeline where it's waiting, right now.
Each application also has a complete history of each state change. I don't know which of this is a "workflow" that could have an instance. They're just states of being of an object.
It is a web application. So it will have some other logic such as view an appln., navigation etc. do I need to accommodate this in the workflow as well?
Yes and No. Yes, each processing stage which show the application so the user at that stage can do whatever value-add thing they do. They add information or they approve information.
Each stage in the workflow is a place where some human being makes a decision and takes an action. So each stage displays all the information the person needs to make the decision. There's no additional view required.
Navigation isn't terribly interesting. People go to pages to see their queues of unprocessed work. I guess you'll have to build a page with some URL's, but there isn't much to that.
Would it be ok to have just a part of the application based on workflow.
Sure. Why not? I'm not sure I understand the question.
Your web apps just queries a queue of stuff out of the database and present that queue of stuff to a person. The person can request details and make changes to a specific item in the queue. One change the person can make will be to move the stuff out of their queue and into someone else's queue.
This isn't very complex. It shouldn't be. What's hard is defining the allowed state changes.
I'm building a Web Page that allows the user to pick a color and size. Once they have these selected I need to perform a lookup to see if inventory exists or not and update some UI elements based on this.
I was thinking that putting all the single product data into multidimensional JavaScript array (there is only 10-50 records for any page instance) and writing some client side routines around that, would be the way to go for two reasons. One because it keeps the UI fast and two it minimizes callbacks to the server. What i'm worried about with this solution is code smell.
As an alternative i'm thinking about using a more AJAX purist approach of using HTTP handlers and JSON, or perhaps a hybrid with a bit of both. My question is what are your thoughts as to the best solution to this problem using the ASP.Net 2.0 stack?
[Edit]
I also should mention that this page will be running in a SharePoint environment.
Assuming the data is static, I would vote option #1. Storing and retrieving data elements in a JavaScript array is relatively foolproof and entirely within your control. Calling back to the server introduces a lot of possible failure points. Besides, I think keeping the data in-memory within the page will require less code overall and be more readable to anyone with a more than rudimentary understanding of JavaScript.
i'm against Ajax for such tasks, and vote (and implemented) the first option.
As far as I understand, you won't create Code smells if the JS part is being written by your server-side.
From a user point-of-view, Ajax is an experience-killer for wireless browsing, since any little glitch or mis-service will fail or simply lengthen the interaction by factors of 20(!).
I've implemented even more records than yours in my site, and the users love it. Since some of my users use internet-caffee, or dubious hotel wifi, it wouldn't work otherwise.
Besides, Ajax makes your server-vs-client interaction code much more complex, IMO, which is the trickiest part in web programming.
I would go with your second option by far. As long as the AJAX call isn't performing a long running process for this case, it should be pretty fast.
The application I work on does lots with AJAX and HttpHandler, and our calls execute fast. Just ensure you are minimizing the size of your JSON returned in the response.
Go with your second option. If there are that few items involved, the AJAX call should perform fairly well. You'll keep your code off the client side, hopefully prevent any browser based issues that the client side scripting might have caused, and have a cleaner application.
EDIT
Also consider that client side script can be modified by the user. If there's no other validation occuring to the user's selection, this could allow them to configure a product that is out of stock.