2008-08-22 33 views
11

Tôi đang tham gia ASP.NET (C# - Tôi biết nó không quan trọng đối với câu hỏi cụ thể này, nhưng tiết lộ đầy đủ và tất cả điều đó), và trong khi tôi yêu các điều khiển kiểu asp: lưu tôi rất nhiều HTML-crafting crafting, tôi thường thất vọng với hành vi nhất định. Tôi đã gặp một đêm qua khi làm việc với Trang chính: <asp:BulletedList ID="nav">, khi được chuyển đổi thành HTML, đã trở thành <ul id="ct100_nav">.Điều khiển so với HTML chuẩn

Có các vấn đề khác - tôi nhận thấy rằng khi bạn tự động điền DataGrid, nó sẽ thêm thuộc tính vào bảng kết quả mà tôi không nhất thiết muốn ở đó.

Tôi biết rằng có một số lượng nhất định "quy ước về cấu hình" mà bạn phải chấp nhận khi bạn dựa vào một khuôn khổ để tiếp nhận một số nhiệm vụ tẻ nhạt của bạn, nhưng "quy ước" trong những trường hợp này không phải như vậy nhiều công ước được thiết lập, nhưng thay vào đó là các tính năng bổ sung không cần thiết. Tôi biết lý do tại sao ID thêm tiền tố, nhưng tôi sẽ có thể tinh chỉnh và tắt những thứ như thế này, đặc biệt là vì một số nhà truyền giáo chuẩn web, tôi không sao chép id HTML trong một trang đơn lẻ. Vì vậy, câu hỏi ở đây là dành cho những người phát triển ASP.NET dày dạn hơn tôi: trong kinh nghiệm của bạn trong việc phát triển và triển khai ứng dụng, làm thế nào để bạn tận dụng những điều khiển này? Bạn có thấy mình đang sử dụng HTML mã hóa cứng không? Bạn có sử dụng một hỗn hợp? Tôi không muốn thiết kế HTML của mình quanh những điều kỳ quặc riêng trong các điều khiển này, nhưng nếu có thể, tôi muốn tận dụng chúng khi có thể.

Cậu bé cần làm gì?

Trả lời

13

Cá nhân,

Tôi nghĩ rằng các điều khiển ASP.NET tiêu chuẩn được sử dụng tốt cho các công cụ trong nhà - nhanh chóng và dơ bẩn là tốt trong kịch bản đó. Nhưng, tôi đã từng làm việc với một nhà phát triển web cũng là một nhà thiết kế và ông từ chối sử dụng các điều khiển ASP.NET và chỉ mã trong HTML và thêm các thẻ runat = "server" khi cần thiết. Điều này đã được nhiều hơn bởi vì anh ta muốn biết chính xác cách HTML của mình sẽ được trả lại, và tại thời điểm nào, một số điều khiển ASP.NET sẽ không làm cho tuân thủ các tiêu chuẩn.

Tôi ngồi ở đâu đó ở giữa - sử dụng HTML khi thích hợp và không khi không. Bạn có thể phân loại tốt nhất của cả hai thế giới với CSS control Adapters

1

Tôi cũng đang trong cuộc phiêu lưu của mình vào ASP.NET và cũng có những thất vọng tương tự .. Tuy nhiên, bạn sớm quen với nó. Bạn chỉ cần nhớ, lý do bạn không có HTML crafting tẻ nhạt là bởi vì các điều khiển ASP.NET làm tất cả cho bạn.

Ở một mức độ nào đó, bạn có thể kiểm soát/chỉnh sửa những điều này, ngay cả khi nó có nghĩa là kế thừa điều khiển và điều chỉnh đầu ra HTML từ đó. Tôi đã phải làm điều đó trong quá khứ, nơi mà một số điều khiển đã không vượt qua xác nhận W3C theo mặc định bằng cách đặt thêm một số đánh dấu ở đây và ở đó, vì vậy tôi chỉ cần overrode và chỉnh sửa khi cần thiết (một sửa chữa quá nghĩa đen một vài phút) ..

Tôi sẽ nói tìm hiểu về cách thức hoạt động của hệ thống điều khiển. Sau đó, hãy tự mình cùng nhau, điều này thực sự đã giúp tôi giải quyết những gì đang xảy ra, vì vậy nếu tôi gặp bất kỳ vấn đề nào, tôi có một ý tưởng đi đâu.

+0

"điều khiển ASP.NET làm tất cả cho bạn" - có, nhưng * vậy * xấu – annakata

+0

Tôi sẽ không đồng ý với điều đó phần nào .. Tôi cố gắng trở thành một lập trình viên đổ lỗi cho lập trình viên chứ không phải công cụ. Tôi đã có người bình luận về cách đánh dấu sạch sẽ được tạo ra bởi một số ứng dụng ASP.NET. Nhiều người trong số các điều khiển tiêu chuẩn là tốt. Nó chỉ khi bạn dựa rất nhiều vào ViewState, và tôi ghét ViewState. :) –

2

Đối với ID trên máy chủ điều khiển: Bạn có thể tìm thấy ID thực sự sẽ được ghi vào trình duyệt bằng cách truy cập ClientID. Bằng cách đó bạn có thể kết hợp kịch bản phía máy khách phía máy chủ và vẫn không phải mã hóa _id = "ct100_nav" _

Tôi luôn cố gắng sử dụng các điều khiển được bao gồm thay vì "hacking" HTML, vì nếu có bản cập nhật hoặc một số cải tiến sau này, tất cả mã của tôi sẽ vẫn hoạt động bằng cách thay thế khung công tác và tôi không phải thay đổi bất kỳ HTML nào.

Hope this helps

0

Nếu tiền tố của ID thêm bởi ASP.NET là một vấn đề để bạn có thể truy cập chúng sau sử dụng JS hoặc một cái gì đó ... bạn có phía máy chủ sở hữu .ClientID.

Nếu phí được thêm bởi ASP.NET, bạn nên xem xét ASP.NET MVC (vẫn xem trước), nơi bạn có toàn quyền kiểm soát html được phát ra.

Tôi chuyển sang MVC vì tôi không thích tất cả những gì chất liệu bổ sung quá ....

2

@ Brian, Yup! Bạn có thể kiểm soát khá nhiều tất cả các hành vi .. Hãy cân nhắc xem xét việc tạo các Điều khiển tùy chỉnh (có ba loại). Gần đây, tôi đã đưa ra tổng quan về chúng trong câu hỏi của tôi here.

tôi sẽ mạnh khuyên kiểm tra chúng ra, có giúp tôi không có kết thúc :)

0

Tôi nghĩ hầu hết các câu trả lời ở đây đều có quan điểm của nhà thiết kế. Trên một dự án vừa và nhỏ, nó có vẻ giống như một đầu vào để đồng bộ hóa mã và CSS/HTML và làm cho chúng tuân thủ các tiêu chuẩn và sạch sẽ. Cách của một nhà thiết kế để làm điều đó là có toàn quyền kiểm soát đối với HTML được hiển thị. Nhưng có nhiều cách để có toàn quyền kiểm soát trong ASP.NET. Và đối với tôi, việc yêu cầu HTML trong tệp aspx/ascx là cách không thể mở rộng và dơ bẩn nhất để làm điều đó. Nếu bạn muốn kiểm soát kiểu dáng thông qua CSS, bạn luôn có thể đặt một lớp máy chủ thông qua thuộc tính CssClass. Nếu bạn muốn truy cập chúng thông qua JS, bạn có thể phát ra JS với các máy chủ ID bên phải một lần nữa. Nhược điểm duy nhất mà điều này cung cấp là một dev và một nhà thiết kế phải làm việc chặt chẽ với nhau. Trên bất kỳ dự án lớn nào, điều này là không thể tránh khỏi. Nhưng những lợi thế ASP.NET cung cấp vượt xa những khó khăn này. Tuy nhiên, nếu bạn muốn HTML tuân thủ tiêu chuẩn, hỗ trợ skinning và các tính năng khác để kiểm soát đánh dấu được hiển thị, bạn luôn có thể sử dụng các điều khiển bên thứ ba.

1

HTML hiển thị với các loại ID đó vì cách ngăn chặn ID của ASP.NET. Mỗi điều khiển vùng chứa, chẳng hạn như trang Chính hoặc điều khiển Thuật sĩ, sẽ thêm một "ID_" vào ID của trẻ em.

Trong trường hợp danh sách dấu đầu dòng của bạn, ListView cung cấp nền tảng trung bình đẹp. Bạn vẫn có thể liên kết nó với một nguồn dữ liệu, nhưng nó cho phép bạn kiểm soát chặt chẽ hơn đối với HTML được hiển thị. Scott Gu có một giới thiệu tốt đẹp để các ListView ở đây:

http://weblogs.asp.net/scottgu/archive/2007/08/10/the-asp-listview-control-part-1-building-a-product-listing-page-with-clean-css-ui.aspx

0

Theo Dave Phường đã đề cập, "đó là cách ngăn chặn va chạm ID ASP.NET của." Một ví dụ rất tốt về điều này là nếu bạn đang cố gắng đặt một điều khiển bên trong một điều khiển tùy chỉnh, sau đó sử dụng điều khiển tùy chỉnh đó trong bộ lặp, để HTML của điều khiển tùy chỉnh sẽ xuất nhiều lần cho trang.

Như những người khác đã đề cập, nếu bạn cần truy cập các điều khiển cho javascript, hãy sử dụng thuộc tính ClientScript để cung cấp cho bạn quyền truy cập vào ClientScriptManager và đăng ký tập lệnh của bạn lên trang theo cách này. Hãy chắc chắn khi viết tập lệnh của bạn để sử dụng thuộc tính ClientID trên điều khiển bạn đang cố gắng tham chiếu thay vì chỉ cần nhập ID của kiểm soát.

4

Câu trả lời ngắn gọn là bạn không nên sử dụng asp: ...phiên bản kiểm soát HTML tiêu chuẩn trừ khi bạn có lý do thực sự tốt.

Các nhà phát triển trẻ thường bị hút vào việc sử dụng các điều khiển đó vì chúng được bao phủ trong hầu hết các sách ASP.NET, vì vậy, giả sử rằng chúng phải tốt hơn. Họ không phải. Tại thời điểm này, sau 8 năm phát triển ASP.NET hàng ngày, tôi chỉ có thể nghĩ đến 2 hoặc 3 trường hợp mà nó thực sự có ý nghĩa để sử dụng một asp: ... INPUT kiểm soát trên một HTML tiêu chuẩn.

13

Tôi thực sự khá nhẹ nhõm khi thấy một số ý kiến ​​ở đây đồng ý với chính tôi: ASP.NET là ngôn ngữ mẫu rất kém.

Tôi chỉ muốn bác bỏ một vài trong những điểm chuyên nghiệp thực hiện ở đây (flamesuit trên!):

Dave Phường nhắc đến va chạm ID - điều này là đúng, nhưng tôi làm thế nào xấu xử lý. Tôi đã có thể ưa thích để xem các nút được tham chiếu bởi xpath hoặc bộ chọn css sâu hơn bằng cách làm cho ID có hiệu quả vô dụng ngoại trừ bằng cách trì hoãn nội bộ ASP.NET như clientID - nó chỉ làm cho việc viết CSS và JS khó hơn nhiều. Rob Cooper nói về cách thức kiểm soát là một sự thay thế cho HTML nên tất cả đều ổn (diễn giải, tha thứ cho tôi Rob) - cũng không sao, bởi vì họ lấy một ngôn ngữ hiện tại và hiểu rõ và nói "không, bạn phải làm mọi thứ theo cách của chúng tôi ngay bây giờ "và cách của họ là rất được triển khai kém. ví dụ. asp: bảng điều khiển hiển thị một bảng trong một trình duyệt và một bảng trong một trình duyệt khác! Nếu không có tài liệu hoặc thực thi, đánh dấu cho một điều khiển đăng nhập (và nhiều người khác) không thể dự đoán được. Làm thế nào bạn sẽ có được một nhà thiết kế để viết CSS chống lại điều đó? Espo viết về cách điều khiển cung cấp cho bạn lợi ích trừu tượng nếu nền tảng thay đổi html - điều này rõ ràng là tròn (Nó chỉ thay đổi vì nền tảng đang thay đổi, và sẽ không cần nếu tôi chỉ có HTML của riêng mình thay vào đó) và thực sự tạo ra một vấn đề. Nếu điều khiển sẽ thay đổi với bản cập nhật một lần nữa làm thế nào là CSS của tôi phải đối phó với điều đó?

Bác sĩ chuyên khoa sẽ nói "có nhưng bạn có thể thay đổi điều này trong cấu hình" hoặc nói về điều khiển ghi đè và điều khiển tùy chỉnh. Vậy tại sao tôi phải làm vậy? Gói điều khiển thân thiện với css có nghĩa là để khắc phục một số vấn đề này là bất cứ điều gì nhưng với đánh dấu unsemantic của nó và nó không giải quyết vấn đề ID. Nó không thể thực hiện MVC (khái niệm trừu tượng, không phải là thực hiện 3,5) ra khỏi hộp với các ứng dụng webform bởi vì các điều khiển này chặt chẽ ràng buộc quan điểm và kiểm soát. Có một rào cản về nhập cảnh cho nhà thiết kế web truyền thống hiện nay bởi vì anh ta phải tham gia với mã phía máy chủ để thực hiện những gì từng là các miền riêng biệt của CSS và JS. Tôi thông cảm với những người này.

Tôi thực sự đồng ý với quan điểm của Kiwi rằng các điều khiển cho phép phát triển rất nhanh các ứng dụng của một cấu hình nhất định và tôi chấp nhận rằng vì lý do nào đó một số lập trình viên thấy HTML khó chịu và hơn thế nữa là lợi thế của các phần khác của ASP. NET cung cấp cho bạn, yêu cầu các điều khiển này, có thể đáng giá.

Tuy nhiên, tôi bực bội về sự mất kiểm soát, tôi cảm thấy mô hình đối phó với những thứ như lớp học, phong cách và kịch bản trên codebehind là một bước wrongheaded ngược, và tôi tiếp tục cảm thấy rằng có những mô hình tốt hơn cho khuôn mẫu (việc triển khai các vi định dạng và xslt cho nền tảng này) mặc dù việc thay thế các điều khiển bằng các điều này là không tầm thường.

Tôi nghĩ ASP.NET có thể học được rất nhiều từ công nghệ liên quan trong thế giới LAMP và đường ray, cho đến lúc đó tôi hy vọng sẽ làm việc với 3.5 MVC nơi tôi có thể.

(xin lỗi đó là quá lâu </rant >)

+0

Tôi ước gì tôi đã không ra khỏi upvotes ngày hôm nay. – NotMe

+0

Tôi không nghĩ rằng tôi từng thấy một câu trả lời tồi từ bạn. –

0

Nếu bạn muốn có nhiều quyền kiểm soát HTML rendered, nhìn vào ASP.NET MVC để thay thế.

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