Is there any way to access session on view page by creating common method in controller also want to access session in controller by common method in ASP.Net MVC.
are you using razor view engine?
View:
#{ var sessionVar = Session["key"]; //it's object }
Controller:
public ActionResult Method() {
var sessionVar = this.Session["..."]; //
}
the common way to call this object is: HttpContext.Current.Session
I don't know what you meant by 'common'. the provided session object is common for user session no matter where you will call for it.
But in fact you shouldn't try to use session it's ugly - try to do some search about ViewBag / ViewData and then try to search why you shouldn't use them as well. :)
Am new to MVC but I think I know what you're trying to do. You don't need to create a 'common' method to achieve that. #trn Solution should work but it might throw Null reference exceptions if accessed in "View" without using "HttpContext.Current.Session" object for two possible reasons:
Session["key"] is null.
incorrect reference to Session["key"] in View and/or Controller.
Using "HttpContext.Current.Session" object is great way to achieve what you're looking for and make sure the Session["key"] is not null. For example:
View:
#{
var sessionVar = Session["key"]; // might throw a NullReferenceException
}
Alternative for View:
#{
var sessionVar = HttpContext.Currrent.Session["key"]; // assuming correct reference to Session["key"]
}
Controller:
Public ActionResult someMethod()
{
var sessionVar = System.Web.HttpContext.Current.Session["key"];
}
Related
I have created my own customization for the AuthorizeAttribute inside my asp.net mvc web application, and to be able to return the user to the current URL after login , i am trying to save the current URL inside a TempData and then redirect to the login action method ,as follow-
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
if (!_authorize && !filterContext.HttpContext.Request.IsAjaxRequest())
{
var viewResult = new RedirectResult("/Account/Login");
TempData["returnUrl"] = filterContext.HttpContext.Request.Url.PathAndQuery;
filterContext.HttpContext.Response.TrySkipIisCustomErrors = true;
filterContext.Result = viewResult;
}
but seesm that i can not reference TempData in this case, because the above code will raise the following error:-
The name 'TempData' does not exist in the current context
Can anyone advice please?
Thanks
Try using controller base,
filterContext.Controller.TempData["returnUrl"] = filterContext.HttpContext.Request.Url.PathAndQuery;
Also TempData may behave unexpectedly in Authorize attribute as it lives only on one request cycle. If so use Session instead.
public class XYZController : Controller
{
public ActionResult Index(ODataQueryOptions<Security> options = null)
{
var xyzs= GetXYZs().AsQueryable();
var results = options == null ? xyzs: options.ApplyTo(xyzs);
return View(xyzs);
}
}
This results in "No parameterless constructor defined for this object" error.
I essentially want to pass odata compliant parameters in to a regular controller.
Can this not be done?
I temporarily (until regular controllers can use ODataQueryOptions) solved this through the use of Linq2Rest (NuGet: install-package Linq2Rest)
This quite powerful library allowed me to accomplish what I am looking for with one line of code:
using Linq2Rest;
public ActionResult Index()
{
var filteredSource = GetXYZs().AsQueryable().Filter(Request.Params);
return View(filteredSource);
}
Now you can hit this Controller's Index Action like this:
xyz.com?$filter=something eq 'foo' and another gt 3&$orderby another
ODataQueryOptions<T> is only supported with web API now. That said, this is an interesting scenario. I have opened this issue on codeplex to track it.
How does the ASP.NET MVC's ViewBag work? MSDN says it is just an Object, which intrigues me, how does "Magic" properties such as ViewBag.Foo and magic strings ViewBag["Hello"] actually work?
Also, how can I make one and use it in my ASP.NET WebForms app?
Examples would be really appreciated!
ViewBag is of type dynamic but, is internally an System.Dynamic.ExpandoObject()
It is declared like this:
dynamic ViewBag = new System.Dynamic.ExpandoObject();
which is why you can do :
ViewBag.Foo = "Bar";
A Sample Expander Object Code:
public class ExpanderObject : DynamicObject, IDynamicMetaObjectProvider
{
public Dictionary<string, object> objectDictionary;
public ExpanderObject()
{
objectDictionary = new Dictionary<string, object>();
}
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
object val;
if (objectDictionary.TryGetValue(binder.Name, out val))
{
result = val;
return true;
}
result = null;
return false;
}
public override bool TrySetMember(SetMemberBinder binder, object value)
{
try
{
objectDictionary[binder.Name] = value;
return true;
}
catch (Exception ex)
{
return false;
}
}
}
It's a dynamic object, meaning you can add properties to it in the controller, and read them later in the view, because you are essentially creating the object as you do, a feature of the dynamic type. See this MSDN article on dynamics. See this article on it's usage in relation to MVC.
If you wanted to use this for web forms, add a dynamic property to a base page class like so:
public class BasePage : Page
{
public dynamic ViewBagProperty
{
get;
set;
}
}
Have all of your pages inherit from this. You should be able to, in your ASP.NET markup, do:
<%= ViewBagProperty.X %>
That should work. If not, there are ways to work around it.
The ViewBag is an System.Dynamic.ExpandoObject as suggested. The properties in the ViewBag are essentially KeyValue pairs, where you access the value by the key. In this sense these are equivalent:
ViewBag.Foo = "Bar";
ViewBag["Foo"] = "Bar";
ViewBag is used to pass data from Controller Action to view to render the data that being passed. Now you can pass data using between Controller Action and View either by using ViewBag or ViewData.
ViewBag: It is type of Dynamic object, that means you can add new fields to viewbag dynamically and access these fields in the View. You need to initialize the object of viewbag at the time of creating new fields.
e.g:
1. Creating ViewBag:
ViewBag.FirstName="John";
Accessing View:
#ViewBag.FirstName.
ViewBag is of type dynamic. More, you cannot do ViewBag["Foo"]. You will get exception - Cannot apply indexing with [] to an expression of type 'System.Dynamic.DynamicObject'.
Internal implementation of ViewBag actually stores Foo into ViewData["Foo"] (type of ViewDataDictionary), so those 2 are interchangeable. ViewData["Foo"] and ViewBag.Foo.
And scope. ViewBag and ViewData are ment to pass data between Controller's Actions and View it renders.
ViewBag is a dynamic type that allow you to dynamically set or get values and allow you to add any number of additional fields without a strongly-typed class
They allow you to pass data from controller to view.
In controller......
public ActionResult Index()
{
ViewBag.victor = "My name is Victor";
return View();
}
In view
#foreach(string a in ViewBag.victor)
{
.........
}
What I have learnt is that both should have the save dynamic name property ie ViewBag.victor
public dynamic ViewBag
{
get
{
if (_viewBag == null)
{
_viewBag = new DynamicViewData(() => ViewData);
}
return _viewBag;
}
}
[HttpPost]
public ActionResult Create(FormCollection collection)
{
UpdateModel(collection);
context.SaveChanges();
return RedirectToAction("Index", new {controller = "Home"});
}
The action succeed, but there was no recored inserted into the database. Why?
I do not want to manually create a object by getting each value from each field in form collection.
UpdateModel(collection);
context.SaveChanges();
You didn't made any changes to the context in order to expect something to get saved. Entity Framework (assuming this is what you are using) works with objects. So you need a model and persist this model into the database. So your controller action could look like this:
[HttpPost]
public ActionResult Create(Product product)
{
_repository.Create(product);
return RedirectToAction("Index", new {controller = "Home"});
}
where the _repository variable is some interface which defines the operations on your models. Using an interface here allows you to separate your data access logic from your controller logic. In the implementation of this repository you could be using any data access technology you like such as EF or NHibernate, it's just that your controller shouldn't know about it.
Are you sure the context is open and it's the same from which your object has been extracted ? is the object is still connected to the context ?
usually you create a new context in each call, you need to attach the object to the context change it state to modified and than use SaveChanges.
Otherwise, nothing is done.
context.Customers.Attach(myCustomre);
context.ObjectStateManager.ChangeObjectState(myCustomre, System.Data.EntityState.Modified);
context.SaveChanges();
and for insert:
context.Customers.AddObject(newCustomer);
context.SaveChanges();
I am currently developing an application with the new ASP.NET MVC2 framework. Originally I started writing this application in the ASP.NET MVC1 and I'm basically just updating it to MVC2.
My problem here is, that I don't really get the concept of the FormCollection object vs. the old Typed object.
This is my current code:
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(FormCollection collection)
{
try
{
Member member = new Member();
member.FirstName = collection["FirstName"];
member.LastName = collection["LastName"];
member.Address = collection["Address"];
// ...
return RedirectToAction("Details", new { id = member.id });
}
catch
{
return View("Error");
}
}
This is the Code from the MVC1 application:
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(Member member)
{
try
{
memberRepository.Add(member);
memberRepository.Save();
return RedirectToAction("Details", new { id = member.id });
}
catch
{
}
return View(new MemberFormViewModel(member, memberRepository));
}
What are the benefits of switching to FormCollection in MVC2 and more importantly - how is it used properly?
You had the FormCollection object in v1 as well. But it is more preferred to use a typed object. So if you are already doing that, then continue doing so.
By using FormCollection, you wind up manually matching your post data or query string key/values into values to use in your code using string typing (resulting in stringly-typed code), when instead the built-in Model Binding can do this for you if you use form models, aka "typed objects."
I think by using the FormCollection, you would probably also lose the ability to use the handy Data Annotation (slash Validation) attributes on your model objects as well, which are designed for use with typed object model binding.
Additionally, unit testing can become much more cumbersome once you start touching your controller.Request.Form. You might find yourself having to mock and setup an HttpContextBase, and an HttpRequestBase just to have that mock request's .Form property return the NameValueCollection that you are wanting your test to see. Contrast this to letting model binding do the work for you such as:
// Arrange
var myModel = new MyModel( Property1 = "value1", Property2 = "value2");
// Act
var myResult = myController.MyActionMethod(myModel);
// Assert
// whatever you want the outcome to be
In summary, I would recommend against using FormCollection to the maximum extent possible.