Open GoogleCodeExporter opened 9 years ago
- Ẩn/hiện email: option này là của category hay là của 1 ads? Phần
mô tả chức năng
thì có vẻ như đây là 1 option của 1 ads chứ không phải của
category.
Bàn sâu thêm về mục đích của option này: nếu để admin "theo
dõi" hoặc ngăn cản reader
contact trực tiếp poster thì option này sẽ không hiệu quả vì
poster có thể post ngay
địa chỉ liên lạc của mình vào trong phần nội dung của ads.
Đề nghị: lúc nào cũng hiển thị mục "Contact poster":
+ đồng bộ xuyên suốt website
+ reader sẽ có "thói quen" sử dụng chức năng này hơn là lục tìm địa cỉh liên lạc
của poster trong nội dung ads.
+ có thể thêm 1 số chức năng sau này như "thống kê" các ads được reader "contact"
poster.
- "User-defined field": về mặt kỹ thuật thì user-defined field (và
tên, kiểu cũng như
số lượng field không biết trước) không phải là vấn đề đơn
giản (nếu không có sẵn thư
viện mà phải làm từ đầu). Ngoài ra nếu category có user-defined
field thì mỗi
category phải có form và cơ chế search riêng nữa.
Trước "beta" phase thì tạm thời chưa thể nghĩ tới chức năng
này được.
Đề nghị: thay "user-defined field" bằng "template". Tức là với
mỗi category, admin có
thể tạo ra 1 template. Ví dụ:
===== Test Template For "Nhà Đất" Category =====
Địa chỉ:
Đặt cọc:
Phương thức thanh toán:
Thông tin thêm: ...
===== End Test Template For "Nhà Đất" Category =====
+ Ưu điểm: đơn giản, tổng quát (có thể thêm bớt thay đổi tuỳ ý và giải quyết được
nhiều trường hợp), user có thể tự do thêm/bớt/thay đổi các
"field", hoặc nếu muốn có
thể xoá sạch template và post ads theo ý mình chứ không cần fix
vào 1 form cụ thể.
+ Nhược điểm: không tạo được cơ chế "required field/information"; không thuận lợi
cho việc thống kê/phân loại theo category (ví dụ như thống kê
số lượng ads "nhà đất"
ở Tp.HCM).
Original comment by nbthanh%...@gtempaccount.com
on 24 Jan 2008 at 2:23
- Ẩn/hiện email:
Không phải mục tiêu chính là "ngăn cản" poster đưa contact trực
tiếp mà là "bảo vệ"
poster khỏi các SPAM mail, và ẩn tên của người poster.
Với mục tiêu này thì đề nghị là vẫn để trong phiên bản
PRE-ALPHA
- "User-defined field":
Đồng ý chưa để "UDF" trước giai đoạn CLOSE-BETA
- Câu hỏi cho Phương án thay thế TEMPLATE:
Template này là do admin định nghĩa hay coder định nghĩa? Trong
truường hợp do coder
định nghĩa thì không thực tế, vì số category không định
trước được, và tùy theo từng
nhu cầu có thể phát sinh thêm.
ĐỀ NGHỊ: cho phương án với kiểu fix là "text box"
Original comment by ngo...@gmail.com
on 24 Jan 2008 at 5:00
UDF: mỗi category sẽ có 1 (optional) template, nội dung của template
do admin quyết
định. Ví dụ với category Nhà đất thì admin có thể tạo 1
template như sau:
===== Test Template For "Nhà Đất" Category =====
Địa chỉ: <<địa chỉ khu đất bạn muốn bán>>
Đặt cọc: <<yêu cầu đặt cọc nếu có>>
Phương thức thanh toán: <<thông tin về phương thức thanh toán>>
Thông tin thêm: <<nếu có>>
===== End Test Template For "Nhà Đất" Category =====
Như vậy toàn bộ template sẽ là 1 text file, admin muốn thay đổi,
thêm bớt thế nào
cũng được. Và poster cũng có thể thêm/bớt thay đổi khi post ads.
Nhược điểm của template này là: các field không mang tính bắt
buộc đói với poster.
Original comment by nbthanh%...@gtempaccount.com
on 24 Jan 2008 at 7:24
hehe...tức là mình đính kèm template (file text) khi post các ads chứ
gì.
Làm như thế hơi nông dân. Thà để nghiên cứu tính năng này ở
CLOSE hoặc OPEN-BETA còn hơn.
Nếu làm được fix kiểu textbox hết cho các trường mà admin
định nghĩa trong giai đoạn
PRE-ALPHA hoặc ALPHA thì làm trước. Để ở PRE-ALPHA hay ALPHA đây?
Original comment by ngo...@gmail.com
on 24 Jan 2008 at 9:47
Tạm thời dể implement cái template để xài thử và hình dung nó
ra sao đã :D
Original comment by btnguyen2k
on 25 Jan 2008 at 10:37
Original issue reported on code.google.com by
ngo...@gmail.com
on 24 Jan 2008 at 1:44