ASP.NET Extreme: การนำทางเพจ (การแปล)

Rob Howard

ตอนที่ฉันยังเป็นเด็ก ฉันใช้เวลาไม่กี่สัปดาห์ทุกปีไปเที่ยวกับครอบครัวใหญ่ของฉัน เมื่อยังเป็นเด็กอเมริกัน ฉันรู้สึกทึ่งกับรถไฟฟ้าของเนเธอร์แลนด์ ซึ่งเป็นสิ่งที่ฉันไม่เคยเห็นมาก่อนในดัลลัส รัฐเท็กซัส ซึ่งเป็นบ้านเกิดของฉัน ลูกพี่ลูกน้องพาฉันนั่งเรือชมรถไฟที่แล่นผ่านไปมา เมื่อนั่งบนผืนน้ำใกล้กับราง คุณจะได้ยินเสียงรถไฟที่กำลังใกล้เข้ามา เหมือนเสียงนกหวีดเบาๆ ข้ามราง จนกระทั่งรถไฟแล่นผ่านจุดไคลแม็กซ์อย่างช้าๆ ฉันอดไม่ได้ที่จะนึกถึงสิ่งนี้เมื่อนึกถึง ASP.NET 2.0 ASP.NET 2.0 ใกล้เข้ามาแล้ว และพวกเราส่วนใหญ่ต่างตั้งตารอคอยการเปิดตัวในเร็วๆ นี้มากพอจนเราได้ยินเสียง "วู้" ว่าการเปิดตัวยังคงดังขึ้นเรื่อยๆ แล้ววิธีเขียนซอฟต์แวร์ของเราก็จะเปลี่ยนไปอีกครั้ง

เป้าหมาย ASP.NET 2.0 ของ Microsoft คือการมอบประสิทธิภาพ 50% ให้กับนักพัฒนา อย่างไรก็ตาม การปรับปรุงประสิทธิภาพจริงดูเหมือนจะเกินความคาดหมาย คุณสมบัติการปรับแต่งส่วนบุคคล การเป็นสมาชิก และการจัดการบทบาทใหม่ ช่วยลดภาระของนักพัฒนา ในขณะที่คุณสมบัติอื่นๆ เช่น การผูกข้อมูล ก็ถูกทำให้ง่ายขึ้นเช่นกัน ตัวอย่างเช่น ไวยากรณ์ที่คุ้นเคยและยังคงได้รับการสนับสนุน:

<%# DataBinder.Eval (Container.DataItem, "FirstName") %>

ใน ASP.NET 2.0 สามารถทำให้ง่ายขึ้นเป็น:

<%# Eval("FirstName") %>

ไม่เพียงแต่มีฟีเจอร์ใหม่ที่น่าประทับใจมากมายเท่านั้น แต่ยังมีการควบคุมเซิร์ฟเวอร์ที่มีประโยชน์มากมายอีกด้วย โมเดลการเขียนโปรแกรม ASP.NET จะมีประสิทธิภาพมากยิ่งขึ้นใน ASP.NET 2.0 เนื่องจากการบูรณาการการเป็นสมาชิกเข้ากับการควบคุมเซิร์ฟเวอร์ เช่น การควบคุม <ASP:login> และแหล่งข้อมูลใหม่และการควบคุมเซิร์ฟเวอร์การควบคุมข้อมูล

จำนวนไลบรารีคลาส System.Web เพิ่มขึ้นเกือบสองเท่าใน ASP.NET 2.0 - ครอบคลุมมากจนต้องใช้คอลัมน์นิตยสารด้วยซ้ำ เพื่อให้เข้าใจขอบเขตของการเปลี่ยนแปลงเหล่านี้อย่างแท้จริง คุณจะต้องมีหนังสือ ASP.NET 2.0 ใหม่ ฉันวางแผนที่จะเขียนคอลัมน์บางส่วนที่นี่เพื่อเน้นคุณลักษณะใหม่ที่สำคัญบางประการของ ASP.NET 2.0 เดือนนี้ฉันจะมุ่งเน้นไปที่การนำทางและการไหลของหน้า โดยเริ่มจากคุณลักษณะที่เป็นที่ต้องการอย่างมาก นั่นก็คือ ความสามารถในการส่งไปยังหน้าอื่นๆ

การส่งข้ามเพจ

ข้อร้องเรียนที่ใหญ่ที่สุดที่ฉันได้ยินจากนักพัฒนาที่ย้ายไปยัง ASP.NET คือโมเดล postback ของเพจ เพจ ASP.NET สามารถมี <form> เดียวและสามารถโพสต์ HTTP กลับไปที่ตัวเองเท่านั้น ดังนั้นการประมวลผลทั้งหมด ตรรกะทั้งหมดจะทำงานบน หน้านี้

นักพัฒนาจำนวนมาก โดยเฉพาะผู้ที่คุ้นเคยกับ ASP และต้องการควบคุมองค์ประกอบ <form> จะรู้ว่าใน ASP คุณสามารถสั่งให้ <form> ตำแหน่งและวิธีการส่งข้อมูลเนื้อหา (HTTP Post หรือ HTTP Get) และ หน้าเดียวกัน ปริมาณของ <form> แต่เมื่อเทียบกับ ASP แล้ว ASP.NET อนุญาตให้เพจมี <form runat=server> ได้เพียง 1 รายการเท่านั้น และสามารถโพสต์กลับไปยังหน้านั้นเองได้เท่านั้น สิ่งนี้อาจทำให้หงุดหงิดมาก นี่คือตัวอย่างของสิ่งที่ถูกส่งไปยังเพจอื่นใน ASP.NET 2.0:

<%@ Page MasterPageFile="~/Site.master" Language="C#"
CodeFile="Source.aspx.cs"
สืบทอด = "แหล่งที่มา" %>

<ASP:Content ID = "เนื้อหาหลัก"
ContentPlaceHolderID = "หลัก" Runat = "เซิร์ฟเวอร์">
ใส่ชื่อของคุณ:
<ASP:TextBox ID="NameBox" Runat="server"></ASP:TextBox>
<ASP:Button ID = "Button1" Runat = "เซิร์ฟเวอร์" Text = "ส่ง" / >
</ASP:เนื้อหา>

มาสเตอร์เพจใช้เพื่อควบคุมโครงร่างเพจ โดยมีบล็อก <ASP:content> และตัวควบคุมเซิร์ฟเวอร์บางตัวเพื่อยอมรับอินพุตของผู้ใช้

หากคุณวางแผนที่จะส่งเนื้อหาไปยังเพจอื่น คุณสามารถใช้โค้ดเซิร์ฟเวอร์ที่คล้ายกับดังต่อไปนี้:

Response.Redirect("Target.aspx?Name= " +
HttpUtility.UrlEncode(NameBox.Text));

ปัญหาของเทคโนโลยีนี้คือเมื่อผู้ใช้คลิกปุ่มเพื่อส่ง เซิร์ฟเวอร์จะยอมรับคำขอและส่งการตอบกลับเพื่อเปลี่ยนเส้นทางเบราว์เซอร์ไปที่ Target.aspx ปัญหาง่ายๆ ดังกล่าวได้ผลมาก!

งานสามารถทำให้ง่ายขึ้นได้หรือไม่? ใน ASP.NET 2.0 คำตอบคือใช่ ถัดไป สาธิตโค้ดที่ได้รับการปรับปรุง:

<%@ Page MasterPageFile="~/Site.master" Language="C#"
CodeFile="Source.aspx.cs"
สืบทอด = "แหล่งที่มา" %>

<ASP:Content ID = "เนื้อหาหลัก"
ContentPlaceHolderID = "หลัก" Runat = "เซิร์ฟเวอร์">
ใส่ชื่อของคุณ:
<ASP:TextBox ID="NameBox" Runat="server"></ASP:TextBox>
<ASP:ID ปุ่ม = "Button1" Runat = "เซิร์ฟเวอร์" Text = "ส่ง"
PostBackUrl="~/Target.aspx" />
</ASP:เนื้อหา>

หมายเหตุแอตทริบิวต์ PostBackUrl ใน <ASP:ปุ่ม> คุณลักษณะนี้จะบอกปุ่มไม่ให้ทำการ postback เริ่มต้น แต่จะส่งข้อมูลโดยตรงไปยัง Target.aspx

คุณอาจสงสัยว่าสิ่งนี้ทำงานอย่างไร โดยเฉพาะอย่างยิ่งถ้าคุณคุ้นเคยกับ ASP.NET ViewState วัตถุ. แต่นั่นอยู่นอกเหนือขอบเขตของบทความนี้ เมื่อใช้คุณลักษณะการจัดส่งข้ามหน้า ฟิลด์ที่ซ่อนใหม่จะถูกเพิ่มลงในเพจ:

<input type="hidden" name="__PREVIOUSPAGE" id="__PREVIOUSPAGE"
value="p1-dFHlCpgH2alr1vkr3G21UIR7jOuzn074led6lbGf1KQ47_F25GwG0" />

คล้ายกับสถานะมุมมองที่สร้างโดยแผนผังควบคุมเล็กน้อย แต่เป็นส่วนย่อยของสถานะมุมมองที่ตรวจสอบความถูกต้องของเพจสำหรับการส่งข้ามเพจ คุณรู้ไหมว่าเมื่อเพจถูกโพสต์ข้ามไปยังเพจอื่น เพจที่ได้รับจะต้องสามารถเข้าถึงอินสแตนซ์ของเพจที่โพสต์ได้ ในกรณีนี้หมายความว่า Target.ASP สามารถเข้าถึงรายละเอียดของ Source.aspx ได้ ที่จริงแล้ว วิธีที่มีประสิทธิภาพมากกว่าคือการเข้าถึง API จาก Source.aspx ไปยัง Target.aspx ผ่านตัวจัดการที่พิมพ์อย่างเข้มงวด เพื่อเข้าถึงหน้าการจัดส่ง (หน้าก่อนหน้า) ASP.NET2.0 ให้แอตทริบิวต์หน้าสำหรับการจัดส่งข้ามหน้า: PreviousPage

PreviousPage ส่งคืนอินสแตนซ์ของเพจการจัดส่ง และยังมีคุณสมบัติที่ใช้ในการตรวจสอบว่าเป็นการจัดส่งข้ามเพจหรือไม่: IsCrossPagePostBack คุณสมบัตินี้คล้ายกับ IsPostBack ที่มีอยู่ แต่จะคืนค่าจริงเฉพาะเมื่อมีการโพสต์ข้ามหน้า

คุณสมบัติ PreviousPage สามารถทำงานแตกต่างออกไปได้ ค่าเริ่มต้นจะส่งคืนอินสแตนซ์ของเพจก่อนหน้าเป็นประเภทเพจ อย่างไรก็ตาม โดยการใช้คำสั่งใหม่ คุณสามารถให้คุณสมบัติ PreviousPage ส่งคืนอินสแตนซ์ที่พิมพ์อย่างรุนแรงเพื่อเข้าถึงสมาชิกสาธารณะของเพจ ตัวอย่างเช่น เพิ่มรหัสต่อไปนี้ใน Target.aspx:

<%@ PreviousPageType VirtualPath="~/Source.aspx" %>

ตอนนี้คุณสามารถใช้คุณสมบัติ PreviousPage บน Target.aspx เพื่อเข้าถึงข้อมูลของ Source.aspx อย่างไรก็ตาม ในการเข้าถึงตัวควบคุมเซิร์ฟเวอร์ เช่น NameBox บน Source.aspx คุณยังต้องเขียนโค้ดต่อไปนี้:

TextBox

nameBox = PreviousPage.FindControl("NameBox") เป็น TextBox;

เข้าถึงแผนผังการควบคุม เหตุใดเซิร์ฟเวอร์จึงควบคุมค่าเริ่มต้นเป็นตัวแปรสมาชิกที่ได้รับการป้องกัน เพื่อให้เข้าถึงองค์ประกอบของเพจก่อนหน้าได้อย่างง่ายดาย คุณจะต้องเปิดเผยคุณสมบัติหรือวิธีการบน Source.aspx เป็นแบบสาธารณะ จากนั้นโค้ดต่อไปนี้จะใช้งานได้: กล่องข้อความ nameBox = PreviousPage. NameBox;

Cross-page delivery เป็นคุณสมบัติที่ยอดเยี่ยมของ ASP.NET มีบทความบางส่วนที่กล่าวถึงรายละเอียดทางเทคนิคของ cross-page delivery โดยละเอียด หากคุณสนใจเกี่ยวกับวิธีการทำงานของ cross-page delivery ออกการตัดของ Dino Esposito ในคอลัมน์ MSDN Magazine Edge ฉบับเดือนกันยายน (โปรดดูคำแปลของฉัน: แบบฟอร์ม ASP.NET (การแปล)) นอกจากนี้ คุณยังอาจพบว่าหากคุณมีความเชี่ยวชาญใน ASP.NET คุณจะยังคงใช้โมเดล postback ของหน้ามาตรฐานเป็นส่วนใหญ่ต่อไป (ผู้แปล: ความหมายก็คือ ถ้าคุณเป็นผู้เชี่ยวชาญ คุณจะดูหมิ่นคุณลักษณะนี้)

ตัวควบคุมตัวช่วยสร้าง

สามารถสร้างฟังก์ชันการนำทางที่ซับซ้อนสำหรับแอปพลิเคชันผ่านการจัดส่งแบบข้ามเพจได้อย่างง่ายดาย อย่างไรก็ตาม คุณลักษณะนี้ไม่ได้ทำให้การสร้างอินเทอร์เฟซผู้ใช้แบบวิซาร์ดง่ายขึ้น ส่วนติดต่อผู้ใช้แบบวิซาร์ด ไม่ว่าจะเป็นแบบเชิงเส้นหรือไม่เชิงเส้น มักได้รับการออกแบบเพื่อให้บรรลุผลสำเร็จ มันมอบวิธีที่เป็นมิตรกับผู้ใช้ในการดำเนินขั้นตอนที่ซับซ้อนให้เสร็จสิ้น ซึ่งแต่ละขั้นตอนจะถูกแบ่งออกเป็นส่วนๆ

ใน ASP.NET 1.x ตัวช่วยสร้างมักถูกนำมาใช้โดยใช้เทคนิคบางอย่าง: วางตัวควบคุมเซิร์ฟเวอร์ <ASP:panel> หลายตัวไว้ในหน้าเดียวกัน และสลับการมองเห็นตามตำแหน่งของผู้ใช้ การเขียนตัวช่วยสร้างใน ASP.NET ไม่ใช่เรื่องง่าย นักออกแบบจำนวนมากละทิ้งตัวช่วยสร้าง และการจัดการกระบวนการขั้นตอนก็ทำให้เกิดความสับสนเช่นกัน

ความสามารถในการจัดส่งแบบข้ามเพจใหม่ใน ASP.NET สามารถใช้เพื่อแก้ปัญหาตัวช่วยสร้างได้ แต่ก็เป็นความท้าทายเช่นกันเมื่อจำเป็นต้องมีการนำทางที่ไม่ใช่เชิงเส้น ตัวอย่างเช่น ขั้นตอนที่ 1 ขั้นตอนที่ 2 ข้ามขั้นตอนที่ 3-5 ขั้นตอนที่ 6 ขั้นตอนที่ 3 ขั้นตอนที่ 2 ขั้นตอนที่ 6 ตัวควบคุมตัวช่วยสร้าง ASP.NET 2.0 จะช่วยแก้ปัญหาเหล่านี้ส่วนใหญ่ได้ นอกจากนี้ องค์ประกอบอินพุตทั้งหมดของวิซาร์ดการนำส่งข้ามหน้ายังสามารถเข้าถึงได้อย่างต่อเนื่องผ่านโมเดล Postback ของหน้า

ฟังก์ชันการทำงานของตัวควบคุมตัวช่วยสร้างนั้นใกล้เคียงกับวิธีการซ่อนแผงใน ASP.NET 1.1 มาก อย่างไรก็ตาม ตัวควบคุมตัวช่วยสร้างจะแสดงชุดของ <ASP:WizardStep> ซึ่งสามารถมีจำนวนตัวควบคุมลูกเท่าใดก็ได้ อย่างไรก็ตาม แต่ละตัว <ASP:WizardStep> จำเป็นต้องมี ID เฉพาะของตัวเอง ดูรูปที่ 1 หน้าควบคุมวิซาร์ดจัดการการนำทางทั้งหมด รองรับการนำทางเชิงเส้นและไม่ใช่เชิงเส้น และรองรับเวลาออกแบบเต็มรูปแบบ รูปที่ 2 สาธิตการควบคุมวิซาร์ด ด้านซ้ายคือการนำทางแบบไม่เชิงเส้น และด้านขวาล่างคือการนำทางด้วยปุ่มเชิงเส้น จากเมนูงานที่เปิดขึ้น คุณจะไม่เพียงเห็นงานทั่วไปเท่านั้น แต่ยังรวมถึงรายการขั้นตอนที่ช่วยให้สามารถสลับระหว่างขั้นตอนต่างๆ ในเวลาออกแบบได้

รูปที่ 2 ตัวช่วยสร้างใน Visual Studio

องค์ประกอบที่มองเห็นได้ทั้งหมดของตัวควบคุมตัวช่วยสร้างสามารถกำหนดค่าได้ ลิงก์ที่ไม่ใช่เชิงเส้นสามารถแทนที่ได้ด้วยปุ่มหรือลบรายการ และองค์ประกอบการนำทางเชิงเส้นก่อนหน้า ถัดไป และที่สมบูรณ์สามารถเปลี่ยนเป็นปุ่มรูปภาพหรือลิงก์ได้ ในความเป็นจริง ทุกแง่มุมของการควบคุมสามารถกำหนดค่าได้ผ่านเทมเพลต

ปัญหาประการหนึ่งในการเขียนตัวควบคุมวิซาร์ดใน ASP.NET 1.1 คือการจัดการตำแหน่งที่ผู้ใช้ควรอยู่ ตัวควบคุมตัวช่วยสร้างทำให้งานนี้ง่ายขึ้นโดยการเปิดเผยคุณสมบัติ ActiveStep คุณสมบัติ ActiveStep สามารถสอบถามและกำหนดขั้นตอนที่ใช้งานอยู่ในปัจจุบันได้ โฟลว์ตามธรรมชาติของวิซาร์ดจะดำเนินการตามที่ประกาศไว้โดยการใช้งาน และโฟลว์สามารถเปลี่ยนแปลงได้ตลอดเวลาผ่านเมธอด MoveTo ขั้นตอนใดๆ ก็สามารถตั้งค่าเป็น ActiveStep ได้ด้วย MoveTo เพื่อช่วยในการนำทางและดำเนินการ จึงมีเหตุการณ์ต่างๆ มากมายให้ดูที่ รูปที่ 3

ตัวควบคุมตัวช่วยสร้างใหม่มีประโยชน์มากเมื่อรวบรวมข้อมูลผู้ใช้ คุณไม่ต้องการเขียนโครงสร้างพื้นฐานทั้งหมดใน ASP.NET 1.1 ที่ได้ทำงานทั้งหมดให้กับคุณ ตัวควบคุมวิซาร์ดมีประโยชน์มากจนทีมงาน ast.net ใช้เป็นคลาสพื้นฐานสำหรับตัวควบคุม CreateUserWizard ซึ่งใช้ในการสร้างผู้ใช้โดยเป็นส่วนหนึ่งของฟังก์ชัน Membership

ส่วน

การโพสต์ข้ามเพจและตัวควบคุม <ASP:Wizard> ช่วยให้นักพัฒนา ASP.NET มีตัวเลือกใหม่มากมายสำหรับการควบคุมโฟลว์การนำทางในแอปพลิเคชันของตน การนำส่งข้ามเพจมีประโยชน์ในสถานการณ์ที่คุณต้องการใช้ Response.Redirect หรือ Server.Transfer ในปัจจุบัน การควบคุมวิซาร์ดเหมาะอย่างยิ่งสำหรับการสร้างคอลเล็กชันข้อมูลที่ซับซ้อนซึ่งจำเป็นต้องมีการรวบรวมข้อมูลทั้งแบบเชิงเส้นและไม่เป็นเชิงเส้น

-
รูปที่ 1 ขั้นตอนของวิซาร์ด

<ASP:Wizard runat="server">
<ขั้นตอนของตัวช่วยสร้าง>
<ASP:WizardStep ID="Step1">
ยินดีต้อนรับ!
</ASP:ขั้นตอนตัวช่วยสร้าง>
<ASP:WizardStep ID="Step2">
คุณชื่ออะไร: [TextBox1]
[ปุ่ม1]
</ASP:ขั้นตอนตัวช่วยสร้าง>
<ASP:WizardStep ID="Step3">
ขอบคุณ [TextBox1.Text]!
</ASP:ขั้นตอนตัวช่วยสร้าง>
</ขั้นตอนของตัวช่วยสร้าง>
</ASP:ตัวช่วยสร้าง>

------------------------------------------------ --- ----------
รูปที่ 3 เหตุการณ์การนำทาง คำ