2009-06-24 40 views
18

Tôi nén JS của riêng mình bằng cách sử dụng YuiCompressor, nhưng có bất kỳ lý do nào khiến MicrosoftAjax.js không được rút gọn? Hoặc là có một số thiết lập để nói chạy phiên bản nén của nó (nếu có một phiên bản nén). Hay tôi cần phải dịch ngược nó và rút gọn tài nguyên tập lệnh?Có lý do nào khiến MicrosoftAjax.js không được rút gọn?

+0

+1 Câu hỏi hay! –

+0

Cũng từ những phản hồi tôi nhận được, có vẻ như không sao để có được một phiên bản rút gọn/nén của MicrosoftAjax.js ra khỏi hộp. Vì vậy, có vẻ như DIY là con đường để đi như tôi đã đề cập trong câu trả lời tôi chọn. Như tôi đã đề cập đến Josh, trong ASP.NET 3.5, bạn có thể kết hợp các tập lệnh ngay bây giờ, http://msdn.microsoft.com/en-us/library/cc488552.aspx. Chúng tôi chưa di chuyển đến 3,5, nhưng khi chúng tôi làm, tôi sẽ kiểm tra nó. Tôi đã đọc các bài đánh giá hỗn hợp về nó. Đồng thời, tôi đã thêm jQuery vào dự án một thời gian trước đây, vì vậy tôi từ từ jQuerifying tất cả mọi thứ có thể được jQuerified. – nickytonline

+2

Nhận xét của tôi ở trên không còn đúng nữa. Câu trả lời của Dave Ward là câu trả lời hay nhất, vì vậy không có DIY. – nickytonline

Trả lời

23

Tôi ngạc nhiên khi thấy những câu trả lời sai lệch.

ASP.NET AJAX luôn cung cấp cả phiên bản gỡ lỗi và nén của MicrosoftAjax.js. Kết hợp cài đặt gỡ lỗi của web.config và kiểm soát ScriptManager's ScriptMode property tập lệnh nào được tham chiếu.

Ngoài ra, bạn có thể sử dụng the "retail" setting để buộc các tập lệnh nén bất kể.

+1

Cảm ơn Dave này. Tuyệt vời để biết. – nickytonline

+0

Rực rỡ, tôi không biết gì về cài đặt "bán lẻ", công ty chúng tôi có thói quen triển khai nội dung trong sản xuất vẫn ở chế độ gỡ lỗi, v.v. – Matt

-2

Tôi chỉ có thể giả định rằng nó đã được để lại để dễ hiểu, và như bạn đã gợi ý, tôi biết lý do tại sao bạn không thể tự nén nó, nó chỉ là JavaScript sau tất cả - Mặc dù MS có thể như bạn tin rằng nếu không, họ không rắc nó bằng bụi huyền diệu pixie để làm cho nó bất kỳ khác nhau! :)

[Và hãy đối mặt với nó; MS chưa bao giờ sợ kích thước mã của chúng, phải không?]

0

EDIT: Để bảo vệ tôi, tại thời điểm viết câu trả lời này, tôi không có kinh nghiệm với .NET 3.5; Bây giờ tôi nhận ra rằng họ đã thực hiện một số cải tiến rất cần thiết trong lĩnh vực này.


Rõ ràng, MS không cảm thấy kích thước tệp JavaScript là rất quan trọng (tức là điên). Ngoài ra, dựa trên kinh nghiệm của tôi với MS Ajax, họ cũng tiêm nhiều thẻ SCRIPT (đôi khi lớn hơn 10) vào đánh dấu. Các thẻ này mang lại các tập lệnh từ trình xử lý WebResource.axd. Vì vậy, mười hoặc nhiều yêu cầu phải được thực hiện chỉ để có được Javascript cần thiết để chạy trang! Chỉ cần thêm vào sự vô lý, họ tack vào một chuỗi truy vấn điên lên URL xử lý, có thể ngăn chặn các tập lệnh được lưu trữ bởi trình duyệt.

điên rồ này là đủ lý do cho tôi để mương MS Ajax hoàn toàn và chuyển sang jQuery, đó là thư viện tốt hơn, đặc biệt là từ Visual Studio now has Intellisense for jQuery.

+0

Ai đã bỏ phiếu cho câu trả lời này và tại sao? –

+0

Không chắc chắn, hãy bỏ phiếu từ tôi vì tôi chia sẻ quan điểm của bạn trên ASP.NET Ajax. –

+0

Tôi cũng bị downvoted - có lẽ chúng tôi có một nhân viên MS trên SO? :) Tôi muốn các cử tri bỏ phiếu sẽ giải thích lý do tại sao họ đã bầu chọn như vậy ... – CJM

1

Mà bạn thà có:

  1. MicrosoftAjax.js đi kèm nén, obfuscated rồi.
  2. MicrosoftAjax.js không bị nén và mở để bạn có thể đọc và tự mình hiểu.
+3

tại sao không phải cả hai? jQuery đến trong cả hai, phải không? –

+0

Trong khi nó sẽ là tầm thường để có cả hai phiên bản, và khá hữu ích quá, nếu bạn đang đi để có những cách dễ dàng ra, bạn nên cung cấp các phiên bản không nén. 1 vì điều này không đáng được bỏ phiếu. – CJM

+0

@Neil N. Tôi đồng ý, tại sao không phải cả hai? Khi phát triển sử dụng không nén và trong sản xuất, hãy sử dụng phiên bản được rút gọn/bị làm mờ. – nickytonline

3

Xem http://www.codeproject.com/KB/aspnet/AspNetOptimizer.aspx, bạn cần lựa chọn

enableScriptMinification="true" 

và thêm MicrosoftAjax.js vào danh sách

+0

Tôi đã đọc bài viết này trước đây, nhưng cảm ơn vì đã đăng nó ở đây. Những gì tôi đang tìm kiếm mặc dù là một trong những giải pháp hộp từ Microsoft Ajax. Có vẻ như DIY là cách để tiếp tục công việc này. – nickytonline

7

Tất cả các tập lệnh trong System.Web.Extensions đều được rút gọn - có hai phiên bản của mỗi câu lệnh, như câu trả lời tuyệt vời của Dave Ward chỉ ra. ScriptManager theo mặc định sẽ sử dụng phiên bản gỡ lỗi khi web.config đang ở chế độ gỡ lỗi. Lật nó để phát hành với các thiết lập bán lẻ hoặc debug = "false", và nhìn vào kịch bản sau đó.

Ngoài ra, các tập lệnh được phân phát qua WebResourceHandler hoặc ScriptResourceHandler thực tế được lưu trong bộ nhớ cache.Chúng được lưu trữ theo cách tốt nhất có thể - mãi mãi, vì vậy chúng thậm chí không cần đến 301 trong các lần truy cập sau này. Chuỗi truy vấn giống như nó, bởi vì nó chứa dữ liệu được mã hóa. Nó được mã hóa bởi vì nó chứa thông tin về tài nguyên tập lệnh, bao gồm cả tên assembly, và cũng vì nó ngăn chặn các cuộc tấn công tràn bộ nhớ cache.

Không tìm kiếm đại diện tại đây, chỉ muốn cung cấp thêm chi tiết.

+1

Điều cần biết về WebResourceHandler hoặc ScriptResourceHandler được lưu vào bộ nhớ cache. Vì vậy, tôi giả định khi bạn thực hiện thay đổi và triển khai lại, các tệp này được lưu trong bộ nhớ cache một lần nữa nhưng dưới dạng tệp khác vì chuỗi truy vấn được mã hóa đã thay đổi? – nickytonline

+2

Yup. Mọi thay đổi đối với tài nguyên sẽ thay đổi chuỗi truy vấn, dẫn đến một mục mới được lưu vào bộ nhớ cache. Ngoài ra, tôi cũng không đề cập đến các tập lệnh được nén gzip. – InfinitiesLoop

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