Tag

Chỉ là một suy nghĩ chơi, có thể trùng với chỗ nào đó rồi.

Liệu chúng ta có nên nhìn một số kiểu input và property dưới dạng tag. Hãy lấy một ví dụ cụ thể. Tôi có một hệ thống quản lí test case và feature với những thuộc tính như:

  • Mỗi test case có một status, như new, abandoned, finished.
  • Mỗi test case có thể ứng (liên kết) với nhiều feature.
  • Mỗi test case có thể có nhiều tập tin đính kèm.
  • Mỗi feature có thể ứng (liên kết) với nhiều test case
  • v.v

Để ý rằng những tính chất này khá là động, theo nghĩa nó có thể thêm vào bớt đi tùy nhu cầu của người dùng hay người phát triển, và mỗi người dùng lại muốn một cách thiết lập khác nhau.

Chúng ta có thể nhìn các khái niệm trên như sau:

  • Mỗi test case hay feature đều là một sự vật, và đều được mô tả bởi các tính chất.
  • Mỗi property của test case hay feature, như status hay tập tin đính kèm, đều là những tính chất.
  • Các property đều có giá trị, tập giá trị có loại là vô hạn (như text), có loại là cố định (như một tập các check box). Những giá trị này là những “tính từ” mô tả tính chất.
  • Mỗi người dùng hay nhóm người dùng có thể tạo các tập property khác nhau. Ta sẽ coi như đây là các ngôn ngữ khác nhau. Mỗi ngôn ngữ có một bộ từ vựng riêng.

Trước hết, cần hiểu rằng mỗi sự vật đều có tính chất. Nhưng mối quan tâm và cách mô tả sự vật của mọi người đều khác nhau, nên phải tách tính chất chủ quan ra khỏi bản thân sự vật. Trong trường hợp này, chúng ta phải thiết kế để test case hay feature giữ những thuộc tính tối thiểu, và những tính chất cũng test case hay feature sẽ được giữ ở một nơi hay module khác.

Lúc này ta có thể tìm cách xây dựng một cấu trúc chung cho tất cả các property với tập giá trị hữu hạn (vô hạn cũng có thể, nhưng tạm lấy hữu hạn cho dễ nói). Những giá trị này giống như tag (nên tôi đặt tên bài viết là tag). Trong đó mấu chốt là xây dựng tính từ sao cho nó có thể đại diện cho mọi loại đối tượng, cụ thể như:

  • Những tính từ mà người dùng thoải mái thêm vào, như status của test case (new, abandoned, v.v).
  • Những tính từ ứng với đối tượng trong hệ thống. Ví dụ như property thể hiện các feature được liên kết với test case. Mỗi feature chính là một tính từ, cho nên tính từ được sinh ra theo đối tượng.

Khi ta xây dựng được một loại tính từ có thể đại diện cho mọi loại đối tượng, thì việc viết các input cho giao diện cũng sẽ được quy về những loại chung, chẳng hạn:

  • Input cho tối đa n giá trị, n từ 1 tới vô cùng.
  • Input dạng check box, radio, drop down list. Nói chung là dạng mà mọi giá trị được liệt kê.
  • Input dạng search, người dùng sẽ tìm kiếm tại chỗ các tính từ mà họ muốn, đặc biệt là những tính từ ứng với đối tượng trong hệ thống.

Điều này cũng sẽ giúp ta đơn giản hóa việc xây dựng một engine cho việc query dữ liệu. Ví dụ ta có thể đưa ra một cú pháp chung là “<property> has value <adjective>”. Việc query chỉ thực hiện trên tập tính chất và tính từ, nên ta sẽ không phải viết code để xử lí cho từng thuộc tính riêng.

Cuối cùng, chúng ta cần khả năng tách biệt giữa các loại ngôn ngữ và từ vựng, để đảm báo người dùng sẽ có được sự tự do khi làm việc với hệ thống, và người phát triển sẽ không phải nghĩ nhiều về việc người dùng cần gì.

About these ads
  1. Chưa có phản hồi.
  1. Tháng Bảy 28, 2013 lúc 12:09 sáng

Gửi phản hồi

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s

Theo dõi

Get every new post delivered to your Inbox.

Join 29 other followers

%d bloggers like this: