2010-02-26 28 views
9

Tôi có đoạn mã sau vào bên ASPX của tôi:ASP.Net Thay đổi MasterPage lập trình

<%@ Page Language="C#" MasterPageFile="~/masterpages/standard.Master" .... %> 
<%@ MasterType VirtualPath="~/masterpages/standard.Master" %> 

tôi sử dụng VirtualPath để truy cập các thuộc tính trong MasterPage của tôi. Cho đến nay, rất tốt.

Tuy nhiên, bây giờ tôi phải thay đổi trang chính lập trình. Tôi biết rằng để thay đổi một trang chủ, tôi phải làm trên page_init:

Page.MasterPageFile = "~/masterpages/myNewMasterPage.Master"; 

Nhưng tôi không có ý tưởng, làm thế nào để thay đổi VirtualPath.

Trả lời

2

Tôi giả sử bạn đang sử dụng MasterType bởi vì bạn cần một số tài sản (mà bạn cũng sẽ cần nếu bạn thay đổi để làm chủ khác), chúng ta hãy nói rằng bạn hiện đang sử dụng Master.MyButton, di chuyển sang dạng lớp cơ sở và sử dụng loại đó trong @MasterType khai của bạn:

public class MasterBase : MasterPage 
{ 
    public Button MyButton; 
} 

public class standard : MasterBase 
{ 
} 

Bây giờ trong trang của bạn, khai MasterType của bạn trông giống như:

<%@ MasterType TypeName="MyNameSpace.MasterBase" %> 

Bây giờ khi bạn thay đổi đường dẫn ảo của mình, không quan trọng, bạn đang truy cập các thuộc tính trong cơ sở, giống nhau cho cả hai trang chính.

0

Đã làm một số đào và phát hiện này trên Diễn đàn ASP.NET:

Để thay đổi MasterType động, bạn nên tạo một masterpage cơ sở lớp và để cho mỗi MasterPage để kế thừa từ nó.

Sau đó, bạn có thể sử dụng loại cơ sở MasterPage làm Loại chính cho trang của mình.

xem phần "Nhập mạnh mẽ cho chủ động trang" trong số link này.

Kính trọng,

Anas Ghanem

Có vẻ như một cách tiếp cận khá hợp lý, miễn là bạn có thể sống với thực hiện một số đúc.

Source


Nếu bạn muốn tiết kiệm thời gian và tránh được việc phải làm đúc trên mỗi cuộc gọi bạn có thể định nghĩa một lĩnh vực trong loại MasterPage cơ sở của bạn được gọi là 'CurrentMaster' hoặc một cái gì đó để có hiệu lực đó và sau đó sử dụng một điều kiện trên tệp MasterPage hiện tại cũng đặt 'CurrentMaster' với loại thích hợp.

MasterPage CurrentMaster; 
if (Page.MasterPageFile == "Master1") { 
    CurrentMaster = (Master1Type)Page.MasterPage; 
} 
else { 
    CurrentMaster = (Master2Type)Page.MasterPage; 
} 

Source

2

Để đặt ngay, bạn không thể làm điều đó.

Bạn thấy, thư mục "MasterType" cung cấp thông tin loại, được trình biên dịch sử dụng tại thời gian biên dịch.

Khi bạn viết một cái gì đó như Page.MasterPage.btn1.Text = "abcd", thì trình biên dịch cần biết cách xử lý phần "btn1" đó. Nó là gì? Nó là một lĩnh vực? Một tài sản? Một phương pháp? Một lớp lồng nhau? Hoặc có lẽ nó không tồn tại?

Để trả lời các câu hỏi này, trình biên dịch cần biết loại loại của biểu thức Page.MasterPage. Và đó chính xác là những gì bạn cung cấp với chỉ thị "MasterType".

Thuộc tính VirtualPath về cơ bản nói "đi biên dịch tập tin khác trước và kết quả của quá trình biên dịch sẽ là loại thuộc tính chính của trang này". Đó là cách trình biên dịch biết. Từ tất cả những điều trên, người ta có thể rút ra một kết luận: không chỉ là không thể thay đổi kiểu của một số tài sản trong thời gian chạy, nó cũng không có ý nghĩa gì cả - mã đã được biên dịch, bạn không cần bất kỳ thông tin biên dịch-thời gian nữa!

Vì vậy, câu hỏi tiếp theo nảy sinh là: tại sao bạn muốn thực hiện điều này ngay từ đầu?

Nếu bạn chỉ muốn sử dụng các thuộc tính khác nhau được khai báo trong các trang cái khác nhau, bạn có thể lấy lời khuyên của Nick Craver và Nathan Taylor và khai báo một lớp cơ sở có tất cả các trường/thuộc tính đó từ lớp cơ sở đó, và sau đó có chỉ thị MasterType của bạn chỉ định lớp cơ sở đó thông qua thuộc tính TypeName.

Tuy nhiên, tôi sẽ chỉ đi theo cách này nếu cả hai trang chính giống nhau về logic, chỉ khác nhau về thiết kế. Có nghĩa là, một trang không nên có bất kỳ thuộc tính nào mà trang kia không có. Nếu không, nó chỉ là không đúng để có hai tập hợp con của các thuộc tính/phương thức/trường trong một lớp (mà sẽ là lớp cơ sở) khi chỉ có một trong các tập hợp con được sử dụng bất cứ lúc nào. Và nó không phải là đúng để tạo ra một cơ sở chung cho hai lớp khi không thực sự là một cơ sở chung ở đó. Aka "thiết kế xấu". Trong trường hợp này, bạn nên suy nghĩ lại về thiết kế ban đầu của mình.

Nếu mục đích của bạn là một số mục đích khác - vui lòng giải thích và tôi sẽ cố gắng đưa ra một số giải pháp cho bạn.

Chúc may mắn với điều đó.

  • Fyodor
+0

Althoght bạn đã đưa ra một câu trả lời đẹp đó không phải là giải pháp. Nhưng vì nó là rất hữu ích cho khách truy cập hơn nữa, tôi sẽ đánh dấu nó là Userfull. :) – Marco

+0

Nó không phải là một giải pháp, bởi vì không có. :-) Và trong câu trả lời của tôi, tôi cố gắng giải thích một cách cẩn thận tại sao. –

Các vấn đề liên quan