public async Task <bool> ExecuteAsync(IBackloadContext context, IGetFilesRequestParam param)
{
if (param.FileStatus == null)
{
return(false); // in the case something went wrong.
}
// In this example we want the user to work with a backup file we created on file upload.
// Note: We do not need to use async/await or Tasks in this simple example. We only simulate a long running task.
// Important notes: In order to test these demos set breakpoints in all extensions at the beginning of the
// ProcessStep/ProcessStepAsync method. After changing the code always rebuild this extension or set a project dependency
// for the extension (context menu or Project menu) in your MVC project as we did, so the extension class is automatically
// rebuilded. The output build path of the extension is set to the main MVC project in this solution (folder ~/bin/extensions/).
// If you do not rebuild the extension, the main MVC application may uses the old extension.
// Demo 1: The following line simulates a long running task. We do not care about (await) the results of this task, so it
// does not block. The task runs as a background thread within the AppDomains thread pool. You should not use this technique
// with file IO, because the thread may be aborted when Backload returns. (If you do not want to await the results of a long
// running File I/O operation take a look in the StoreFile extension were we're using a separate thread).
var t = Task.Run(() => Task.Delay(System.TimeSpan.FromSeconds(10)));
// Demo 2: Uncomment the line below, set breakpoints (also in the GetFilesRequest2 extension) and rebuild the extension.
// You'll notice that debugging stops and awaits the result of the task.
// The subsequent code and extensions are not executed until the task is finished. But, the ui thread is not blocked and tied up.
// You can see this, because the web page comes back. Usually, when ececuting and debug synchronous code, the web page
// doesn't come back in long running tasks.
// await t;
// Demo 3: Comment out the await line above, uncomment the following line, set breakpoints and rebuild the extension.
// The debugging now doesn't stop here and the rest of this extensions code (and the extension handling code in the extension manager)
// are executed. Before calling the next extension whithin this extension point, the extension manager awaits the result. Note that
// the second extension below isn't called until the task is finished.
// context.PipelineControl.TaskManager.ExtensionTasks.Add(t);
// Demo 4: Comment out the ExtensionTasks.Add line above, uncomment the following line, set breakpoints and rebuild the extension.
// When debugging the application you'll see, that the second extension also can execute and finish its code, before the
// extension manager awaits at the end of the extension point (before code execution returns to the pipeline) the result.
// context.PipelineControl.TaskManager.ExtensionPointTasks.Add(t);
// Demo 5: Comment out the ExtensionPointTasks.Add line above, uncomment the following line, set breakpoints and rebuild the extension.
// Make sure you have set a breakpoint in the OutgoingResponse extension were the response for the PlUpload plugin is generated.
// The difference to the code above is, that the OutgoingResponse was called before the Pipeline waits for the result of the task.
// PipelineExtendedTasks is ultimately the last point in the processing pipeline before the Pipeline returns the results to the client.
// context.PipelineControl.TaskManager.PipelineExtendedTasks.Add(t);
// Note: we do not have mentioned PipelineCoreTasks so far. This point is reached when pipeline core ends. The core methods responsible
// for doing the GET/POST/PUT/DELETE request have done their job, but before the output was generated and the OutgoingResponse extensions
// were called. In this demo there would be no difference to Demo 4. If you're using the early extension points (e.g. IncomingRequest)
// multiple extension points are between this extension point and the end of pipeline core and may better see the difference.
return(false);
}
public async Task<bool> ExecuteAsync(IBackloadContext context, IGetFilesRequestParam param)
{
if (param.FileStatus == null) return false; // in the case something went wrong.
// In this example we want the user to work with a backup file we created on file upload.
// Note: We do not need to use async/await or Tasks in this simple example. We only simulate a long running task.
// Important notes: In order to test these demos set breakpoints in all extensions at the beginning of the
// ProcessStep/ProcessStepAsync method. After changing the code always rebuild this extension or set a project dependency
// for the extension (context menu or Project menu) in your MVC project as we did, so the extension class is automatically
// rebuilded. The output build path of the extension is set to the main MVC project in this solution (folder ~/bin/extensions/).
// If you do not rebuild the extension, the main MVC application may uses the old extension.
// Demo 1: The following line simulates a long running task. We do not care about (await) the results of this task, so it
// does not block. The task runs as a background thread within the AppDomains thread pool. You should not use this technique
// with file IO, because the thread may be aborted when Backload returns. (If you do not want to await the results of a long
// running File I/O operation take a look in the StoreFile extension were we're using a separate thread).
var t = Task.Run(() => Task.Delay(System.TimeSpan.FromSeconds(10)));
// Demo 2: Uncomment the line below, set breakpoints (also in the GetFilesRequest2 extension) and rebuild the extension.
// You'll notice that debugging stops and awaits the result of the task.
// The subsequent code and extensions are not executed until the task is finished. But, the ui thread is not blocked and tied up.
// You can see this, because the web page comes back. Usually, when ececuting and debug synchronous code, the web page
// doesn't come back in long running tasks.
// await t;
// Demo 3: Comment out the await line above, uncomment the following line, set breakpoints and rebuild the extension.
// The debugging now doesn't stop here and the rest of this extensions code (and the extension handling code in the extension manager)
// are executed. Before calling the next extension whithin this extension point, the extension manager awaits the result. Note that
// the second extension below isn't called until the task is finished.
// context.PipelineControl.TaskManager.ExtensionTasks.Add(t);
// Demo 4: Comment out the ExtensionTasks.Add line above, uncomment the following line, set breakpoints and rebuild the extension.
// When debugging the application you'll see, that the second extension also can execute and finish its code, before the
// extension manager awaits at the end of the extension point (before code execution returns to the pipeline) the result.
// context.PipelineControl.TaskManager.ExtensionPointTasks.Add(t);
// Demo 5: Comment out the ExtensionPointTasks.Add line above, uncomment the following line, set breakpoints and rebuild the extension.
// Make sure you have set a breakpoint in the OutgoingResponse extension were the response for the PlUpload plugin is generated.
// The difference to the code above is, that the OutgoingResponse was called before the Pipeline waits for the result of the task.
// PipelineExtendedTasks is ultimately the last point in the processing pipeline before the Pipeline returns the results to the client.
// context.PipelineControl.TaskManager.PipelineExtendedTasks.Add(t);
// Note: we do not have mentioned PipelineCoreTasks so far. This point is reached when pipeline core ends. The core methods responsible
// for doing the GET/POST/PUT/DELETE request have done their job, but before the output was generated and the OutgoingResponse extensions
// were called. In this demo there would be no difference to Demo 4. If you're using the early extension points (e.g. IncomingRequest)
// multiple extension points are between this extension point and the end of pipeline core and may better see the difference.
return false;
}
public async Task<bool> ExecuteAsync(IBackloadContext context, IGetFilesRequestParam param)
{
if (param.FileStatus == null) return false; // if cace something went wrongt.
// We use this extension only to demonstrate you different examples of blocked and parallel requests.
// IMPORTANT NOTE: The FileStatusSimple here is only to show, that you can create your FileStatus from scratch.
// You may use FileStatusSimple as we did here or implement your own iFileUploadStatus class if you need it.
// In this example it'll be sufficient to simply set the file.FileUrl of the FileStatus property, no need to use FileStatusSimple.
FileStatusSimple status = new FileStatusSimple();
foreach (var file in param.FileStatus.Files)
{
file.FileUrl = file.FileUrl.Replace("/Uploads", "/_Backup");
status.Files.Add(file);
}
param.FileStatus = status;
return (param.FileStatus.Files.Count > 0); // if FileStatus.files.Count > 0 we've processed the response, so we need notify the pipeline
}
public async Task <bool> ExecuteAsync(IBackloadContext context, IGetFilesRequestParam param)
{
if (param.FileStatus == null)
{
return(false); // if cace something went wrongt.
}
// We use this extension only to demonstrate you different examples of blocked and parallel requests.
// IMPORTANT NOTE: The FileStatusSimple here is only to show, that you can create your FileStatus from scratch.
// You may use FileStatusSimple as we did here or implement your own iFileUploadStatus class if you need it.
// In this example it'll be sufficient to simply set the file.FileUrl of the FileStatus property, no need to use FileStatusSimple.
FileStatusSimple status = new FileStatusSimple();
foreach (var file in param.FileStatus.Files)
{
file.FileUrl = file.FileUrl.Replace("/Uploads", "/_Backup");
status.Files.Add(file);
}
param.FileStatus = status;
return(param.FileStatus.Files.Count > 0); // if FileStatus.files.Count > 0 we've processed the response, so we need notify the pipeline
}
