My scenario is that the user selects a number of options (for filtering records) and then he clicks a button . The result (retrieved records from DB) will be displayed in a new page .
Would you please show me the steps for that ? a开发者_如何学编程nd which method will be used to store data ? and what data I will be storing ?
Thanks a lot .
Ideally (and RESTfully) the scenario would probably work best as thus:
- Page1 has a form with the various options needed to build the filter.
- Page1's form POSTs to Page2 (which could also be Page1, but it sounds like you want it to be a separate page).
- Page2 reads POST data, performs the filter, displays the results.
For added flexibility, Page2 should check both for form elements as well as query string elements. (You'd want to decide which overrides the other, in the event that both are sent.) That way a filter could even be bookmarked or emailed to a colleague.
There's no need to involve things like session, cookies, etc. That needlessly complicates the matter and makes the scenario less portable and less RESTful.
One thing to note in this scenario is the use of the word "page." While this may be commonplace in the mindset of WebForms (which I assume you're using), you should understand that "the web" really doesn't have a notion of "pages." It's a matter of "resources."
In this case, the response for Resource1 (which is a GET request to Page1.aspx) is a form which has a POST action to Resource2 (which is a POST request to Page2.aspx), which responds with some data. For best design results, you should mentally keep the concept of "pages" and "resources and requests" separate.
Anyway, back to the examples. Page1 would have something like:
<form method="POST" action="Page2.aspx">
<input type="text" name="filterText" />
<button type="submit" name="filter" value="Filter" />
</form>
You'll note that this is highly simplified. You can use the ASP.NET server controls to build this, you can build it manually in the HTML, etc. That's really up to you. Personally I like to keep the output as lean as possible, but how much you want to use the tooling of the framework is your call. I think, for the tooling support, you'd want to look into "Cross-Page Posting" in ASP.NET, since WebForms usually assumes everything is a post-back. I think it's just a matter of setting the PostBackUrl
on the asp:button
in that case.
In the code-behind for Page2, you'd want to look at the Form
property on the Request
object. (More information here.) You'd have something like:
if (!string.IsNullOrEmpty(Request.Form.AllKeys["filterText"]))
{
// Apply your filter when retrieving from the database. Simple if your database data comes back as a delayed-execution IEnumerable.
}
As always, you'll want to do input checking, prevent any SQL injection if you're using straight SQL queries, error handling, etc. But the basic concept gets the job done.
You can pass it with a session or pass with GET. session:
Session["Some_Name"] = parameter;
----------------------------------
retrive on the new page
parameter = (casting)Session["Some_Name"];
GET:
Response.Redirect(NewPage.aspx?parm1=p1?parm2=p2); // parm1,parm2 just a name. p1,p2 are paramters
----------------------------------
retrive on the new page
p1 = Request.QueryString["parm1"];
p2 = Request.QueryString["parm2"];
note:
- When you save at session the type of the parameter Remains (you can move object).
- When you redirect with GET the paramter move as string (you can't move object).
- When you redirect with GET the paramter is visible to the user at the address.
精彩评论