Mẫu hòa giải trong các câu hỏi JavaScript

Question

Tôi đang tạo một loại thư viện dựa trên người hòa giải cho công việc của mình. Chúng tôi tạo ra rất nhiều ứng dụng vì vậy tôi muốn một cái gì đó có thể dễ dàng được thực hiện và sửa đổi trên cơ sở mỗi ứng dụng. Tôi cũng muốn nó được dễ dàng, đủ để tạo ra "vật dụng" (vì thiếu một thuật ngữ tốt hơn) và dễ dàng để loại bỏ chúng mà không cần lo lắng về việc phá vỡ bất cứ điều gì. Nhiều ứng dụng trong số những ứng dụng này mà chúng tôi đưa ra cũng có thể được mở rộng bởi các nhà phát triển bên ngoài, tạo ứng dụng hoặc tiện ích cho ứng dụng.

Đó là cách tôi bắt gặp mẫu hòa giải. Tôi đã viết lên một cái gì đó mà làm việc gì đó như thế này:

//Extend 
Core.extend('widget',function(params){ 
    alert(params.message); 
}); 

//Load it 
Core.load('widget',{message:'Hello World'}); 

//Remove it 
Core.remove('widget'); 

Tôi có 3 câu hỏi tho:

1. thế nào/bạn nên đối phó với DOM thao tác trong mô hình này với Javascript? Tôi không muốn các nhà phát triển rối tung với DOM bên ngoài tiện ích của họ.

2. Làm thế nào để/bạn nên giải quyết các yêu cầu AJAX. Bạn có nên làm gì không? Nếu bạn chỉ cần cung cấp một cuộc gọi AJAX/JSONP trong thư viện (Core trong ví dụ này).

3. Câu hỏi lớn nhất của tôi, làm cách nào để bạn thực sự tương tác với các tiện ích khác? Tôi không muốn chặt chẽ đôi (rõ ràng), nhưng tôi không nhận được cách bạn muốn tương tác với một widget. Ví dụ, giả sử bạn có một hộp văn bản và khi gửi nó sẽ gửi nó đến một DB. Làm thế nào có thể một widget khác, cho phép gọi nó là "thời gian" widget, bây giờ khi nó đã được gửi và sau đó cập nhật các dòng thời gian với các văn bản từ các widget hộp văn bản?

=== CẬP NHẬT ===

tôi đã kết thúc viết này:

http://oscargodson.github.com/Core.js/

Answer 1

Widgets tương tác với các widget: Tôi chỉ xây dựng này cách đây vài ngày kết thúc. Tôi đã xem xét cách bạn đã triển khai và sau đây là một số ý tưởng bổ sung cho bạn.

Hệ thống đẩy bạn đã xây dựng rất giống với hệ thống sự kiện DOM của jQuery, nhờ đó các sự kiện tùy ý có thể được phát ra và nhận được. Tôi đã sử dụng hệ thống đó một chút để phát triển các widget không ghép đôi tuy nhiên tôi đã tìm thấy nó khá mong muốn bởi vì cuối cùng là "đẩy" (sự kiện, phát ra, bất cứ điều gì) nằm ngoài ngữ cảnh - như trong thính giả không biết ngay cả trong phạm vi những gì họ muốn cho đến khi họ thẩm vấn sự kiện.

Hãy xem xét ví dụ: nếu mọi phần tử giao diện người dùng trên trang web là một tiện ích con trong hệ thống của bạn. Sẽ dễ dàng có 30+ trên một trang. Nếu mỗi người đẩy một tin nhắn "được nạp", thì người kia phải nhận nó. Hơn nữa, như bạn đã đề cập, các nhà phát triển bên thứ 3 sẽ phát triển cho hệ thống này. Sau đó nó đặt gánh nặng lên chúng để lọc ra những tin nhắn mà họ không muốn nhận.

Cách tiếp cận tôi đã thực hiện trong hệ thống thông tin tiện ích mới nhất của tôi là phương pháp tôi gọi là "chuỗi"/"chuỗi con" (và công bằng) tôi chắc chắn ai đó đã đưa ra ý tưởng này trước tôi và có một số tên nghe tuyệt vời cho nó). Về cơ bản, bất cứ khi nào một widget "đẩy", đẩy đó được biến thành một chuỗi chứa: lĩnh vực (ngữ cảnh), loại tiện ích, ID cụ thể của tiện ích bất kể nó có thể là gì và thông điệp cụ thể.

Vì vậy, ví dụ: một tiện ích có ID 45, nhập "danh sách tweet", trong lĩnh vực "tùy chỉnh" sẽ đẩy một thông báo "được tải". Chuỗi pub sau đó sẽ hiển thị: custom.tweet-list.45.loaded.

Khi đăng ký được đặt, chúng được nhập thông qua bảng băm có thể tùy chọn chứa giá trị cho 4 thuộc tính (bạn có thể dễ dàng thêm giá trị bên cạnh trường/loại/id/msg tôi có). Nghe thì sẽ như thế nào:

listen({ realm: 'custom', type: 'whatever' }, f); // (where 'f' is a function)

Phần nghe của khuôn khổ của bạn có thể biến mà bảng băm thành một "chuỗi" đó sẽ là một biểu hiện thường xuyên thể hiện các bộ lọc mà nó đại diện:

custom\.whatever\.[^\.]+\.[^\.]+

Đó regex được lưu giữ như một biểu hiện thường xuyên biên soạn một số mảng ẩn ...

__subscriptions.push(new RegExp(subString));

Sau đó, khi có điều gì đó được đẩy (ví dụ: đã xuất bản) khung công tác cơ bản lặp qua mảng __subscriptions, kích hoạt một .test của mỗi subString được lưu trữ (regex) và thực hiện cuộc gọi lại cho subString đó nếu phù hợp.

Sử dụng hệ thống này nghe lọc không giới hạn có thể được áp dụng và người nghe biết rằng họ đang nhận được thông báo cho chỉ bối cảnh họ quan tâm đến

Ví dụ:.

// Listen for all messages by widget ID #99 
listen({ id: 99 } ,f); 

// Listen for all messages by widgets in realm clientB 
listen({ realm: 'clientB' }, f); 

// Listen for the data-received push of widgets whose type is tweet-list 
listen({ type: 'tweet-list', message: 'data-received' }, f); 

Bởi vì regex thực sự chỉ là một concatenation, regex có thể được bao gồm trong bộ lọc quá.

// Listen for any data- message 
listen({ message: 'data-[^\.]+' }, f); 

Vẻ đẹp của hệ thống này là bạn vẫn có thể giữ giao diện hiện tại của bạn để "giữ điều đơn giản" và chỉ kiểm tra một chuỗi hoặc một bảng băm cho argument[0]. Nói cách khác ..

// This 
listen('loaded', f); 

// Could be equivalent to this on the backend: 
listen({ message: 'loaded' }, f); 

Tôi biết đã lâu nhưng hy vọng nó cung cấp cho bạn một số ý tưởng.