I've got a Page, a GridView using an ObjectDataSource with a SelectMethod and a DropDownList. The SelectMethod, among other things, gets a string-array containing several IDs (to filter the Data) - but I also need it as DataSource for the DropDownList.
Alas, I cannot DataBind the DropDownList inside the SelectMethod since it's null.
An Idea would be to bind this string[] to a Session-Variable, but then I'd have to either re-set it upon every Page_Load or remove it from Session on every other page if I want it to update in case something on the Database changed.
What I'm looking for is some kind of variable that is available both in Page_Load and my ObjectDataSources SelectMethod, but that removes itself upon leaving the page (i.e. navigating to any other page on my Web-Application (preferably without having to call a method on EVERY other Page).
I hope you could understand my problem.
Thanks,
Dennis
As I understand the need to fetch the string array arises from the performance hit that a separate roundtrip will cause. To work around this you may create a separate object to feed your object data source. This object will have two methods one for getting the string array and another for getting the data for the grid (i.e. the select method)
You may then put an object like this in your page and fetch the data in it in a lazy manner. If the object makes a call for any of the data it stores the other part in a field. You can then use the ObjectDataSource ObjectCreating event to pass this object on your page to the ObjectDataSource
protected void odsSomething_ObjectCreating(object sender, ObjectDataSourceEventArgs e)
{
e.ObjectInstance = YourInsntanceAlreadyInThePage;
}
This way you will avoid the roundtrip.
Also consider making two web service calls at the same time using the asynchronous client calls so that you can make both calls for the same time. If this is viable depends on the flow of your logic.
What I'm looking for is some kind of variable that is available both in Page_Load and my ObjectDataSource's SelectMethod, but that removes itself upon leaving the page (i.e. navigating to any other page on my Web-Application (preferably without having to call a method on EVERY other Page).
In a similar situation, I've used the Items property of the current HttpContext. It's an IDictionary (non-generic), so can hold arbitrary objects keyed by arbitrary objects, and its lifetime is precisely the duration of the current request, so will go away as soon as the request is ended. To use:
// Where you first get the data
HttpContext.Current.Items["SomeKey"] = new [] { "string1", "string2" };
// Where you want to to use the data
var strings = (string[])HttpContext.Current.Items["SomeKey"];
Related
I have a list of class object that I created as a variable in my deafault.aspx.cs page
List<BoldGauge> boldGauges = new List<BoldGauge>();
I create my object in nessacary function and then add the newly created object to the list so I can retrieve it later as needed.
When I attempt loop through the object later the boldGagues count = 0. I assume I need to either add the List to a session variable or session state.
Does anyone know the best approach for this? There could be numerous different types of controls in multiple lists, so if someone could please recommend an approach that is least expensive, and efficient I would appreciate it.
To persist the list across postbacks, you'll need to store the list somewhere.
You can store it in the Session, but a more applicable place might be the ViewState.
ViewState.Add("GaugesList", boldGauges);
then get it back later
List<BoldGauges> boldGauges = ViewState["GaugesList"];
Note that this is scoped to the page, so if you need the list across pages, use the Session.
foreach(var boldGaug in boldGauges)
{
//do something..
}
I have a DropDownList control which is databound via a SqlDataSource whose query returns 3 fields (Label, Value, and Active) - Is there a way to access the databound dataset programatically to check whether the Active flag is true or false?
I know that this can be done DURING the databind, but I need the Active flag to checked during PreRender phase as the control may need to select a value where Active=false if loading an old record where this selection had been made. (During PreRender, I'm removing all Active=false items, unless it's the value that I'm setting the DropDownList to).
I have this working perfectly by populating a DataView with a SqlDataSource. Select and comparing/removing items based on this, but hitting the database twice to get this info a second time for each control seems inefficient.
Also, I can't write a piece of reusable/generic code for all controls as my current method only works when the SqlDataSource doesn't require any SelectArguments. If I can access the databound data directly, this would bypass this problem too.
Any advice is much appreciated!
I think the main problem you're having comes from using a SqlDataSource as your data-access. SqlDataSources are easy to set up and give you instant results, but they are extremely inflexible and require reuse across pages.
I would create a function that grabs the data from the database and stores it in an List or IEnumerable. If the data is in a List then you have access to it programmatically and validation is much easier to achieve.
Here is a sample below that uses the Entity Framework to access the database
Mark up
<asp:DropDownList ID="ddlTest" runat="server"></asp>
Code Behind
public List<Record> GetAllRecordsByUserName(string credentials)
{
List<Record> recordList;
using (CustomEntities context = new CustomEntities())
{
IQueryable<Record> recordQuery = from records in context.Records
where records.UserName == credentials
select records;
recordList = recordQuery.ToList<Record>();
}
return recordList;
}
public void ValidateAndBind(string username)
{
List<Record> recordList = GetAllRecordsByUserName(username);
// Do validation here
ddlTest.DataSource = recordList;
ddlTest.DataBind();
}
protected void Page_Load(object sender, EventArgs e)
{
ValidateAndBind("test.username");
}
You can use whatever data-access method you desire, but setting it programmatically allows you to reuse it across pages. In the methods above I created it in the page for terms of space. In practice, you should create a class that handles specific data retrieval, which is usually called a Data Access Layer.
I have a question concerning Monotouch.
The situation: I have 2 ViewControllers. The first (let's call it VC-A) looks similar to the contacts edit screen, meaning it has a TableView with multiple Sections each containing Buttons and TextFields. Now when the user clicks one of these Buttons, he will get to the second ViewController (VC-B), which displays a TableView containing data from the database. When the user clicks on any of these rows, VC-B will be closed and i want to display the selected database entry (string) as the title of the Button (in VC-A) which opened VC-B in the first place.
When I did an objective-C project last year, I managed to send data back down the stack by using delegates, but I haven't found a way yet how this works in Monotouch.
I have read several questions here on SO about using the AppDelegate or using singletons, but I'm not sure that this is the right way of returning data from a subview.
You can kind of copy the delegate pattern. Add a C# delegate to your VC-B that takes one parameter, some data structure.
In VC-B's "ViewWillDisappear", call the delegate it it is not null and pass the data on to it.
This way, your calling VC can get acces to the data but you don't need tight coupling between the two controllers. All it has to do, is register a delegate-method in VC-B.
As MonoTouch is .NET4 you can use Func<MyDataStructure> or Action<MyDataStructure> and don't need to use full qualified delegate types.
I have a static singleton class that I use to store "state" type data about my app - current settings and selections that are needed in many different places in the app. That's one way to approach this.
You could also pass VC-B a reference to VC-A when you create VC-B, so that it can explicitly access it's parent view and pass back values that way.
I actually prefer to use TinyMessenger for cross container calls I find this to be very very useful when you don't want to keep references to your heavy viewcontrollers around which could potentially result in memory leaks!
var messageHub = new TinyMessengerHub();
// Publishing a message is as simple as calling the "Publish" method.
messageHub.Publish(new MyMessage());
// We can also publish asyncronously if necessary
messageHub.PublishAsync(new MyMessage());
// And we can get a callback when publishing is completed
messageHub.PublishAsync(new MyMessage(), MyCallback);
// MyCallback is executed on completion
https://github.com/grumpydev/TinyMessenger
I am having some trouble saving the state of my current view.
Currenly I have several selectlist calling their own Action method on the controller that returns the Index view with the filtered model based on the values of the selectlist.
I have also written a little FileResult action that creates a csv file based on the current model. But I am only covering one selectlist right now as I only save the value of selectList1 into the session and access it with Session["SelectListValue1"]
What are the best practices in this situation?
Should I redo the entire (each action for each SelectList) part?
Should I save each SelectLists value into the session and check if it's null?
Or should I just save the Lambda Expression into the session and modify it during every call?
Well, generally in MVC we don't directly save to Session, it's not considered a best practice b/c of impact to your app's performance. Generally, it's a best practice to make each request as stateless as possible.
Each form should follow the POST-Request-GET pattern where possible, so you're not going to do what you did in WebForms as a rule (where you keep posting back to the same form/action).
So you should consider what the state is that you're trying to capture represents. THe list of possible values is one thing, drawn possibly from a database and stored as a list or enumerable in the cache perhaps (in some scenarios; could look it up every time in others). The value that's selected probably represents a property on osme other object, though, so you should use that as your means of getting out the selected value.
If it's something that's not a part of a persistent object, then you can either just read the post values each time and set the viewstate again (probably the best practice) or, if you need to persist that value across a redirect, then use the TempData bag (which works much like session; in fact uses session under the hood) but values get garbage collected after one the next request, so you don't have to worry as much about the memory bloat.
It doesn't sounds like you need to be using the session at all. Can't you pass the values of your select lists via the query string or in a form?
I am currently using a number of query string parameters to pass some data from one page to a second page (the parameters hold confirmation/error messages to display in the second page), that due to a third party product can no longer work correctly in the production environment. The user completes an action on the first page, and is then transferred to the second page. What are the possible alternatives to use instead of a query string and GET - session variables, POST data, or something completely different?
Thanks, MagicAndi.
You could create public properties in a source page and access the property values in the target page when using a server transfer. You could also get control information in the target page from controls in the source page by referencing the Page.PreviousPage property.
Both of these methods are oulined here: http://msdn.microsoft.com/en-us/library/6c3yckfw.aspx
Both POST data and session variables would work just fine. POST data has the drawback that it can be changed by the client and session variables take up memory, so you can choose based on that. I personally don't think that you should pass such messages to the client for the reason stated above but I guess you are already doing that, so...
you can use this if you use window.open("openTheotherPage",...etc)
so form the opened page you can do something like this
var valuefromCallerPage = window.opener.document.FormNmae.textbox.value
or button or anything on the caller page