2009-01-07 12 views
7

Một vài ngày trước, tôi đọc một câu hỏi hỏi có bao nhiêu nhà phát triển tay mã HTML của họ/XHTML thay vì dựa vào các công cụ WYSIWYG - https://stackoverflow.com/questions/406052/do-most-web-programmers-not-designers-use-wysiwyg-editors-or-hand-code-theirTôi lãng phí thời gian của tôi bằng cách thiết kế các thành phần ASP.NET của tôi cho các công cụ WYSIWYG

Tôi có xu hướng nghiêng về phía thiết kế điều khiển máy chủ ASP.NET hơn là điều khiển người dùng để sử dụng trong mã của tôi. Tôi làm điều này để tôi có thể tái sử dụng chúng bằng cách kéo và thả vào WYSIWYG và chỉ cần thiết lập một vài thuộc tính thích hợp. Điều này có chi phí thêm một chút trong thời gian thiết kế các thành phần, nhưng đơn giản hóa mọi thứ rất nhiều khi tôi đến sử dụng chúng trong các ứng dụng lớn hơn.

Sau khi đọc rằng hầu hết các nhà phát triển dường như viết mã thay vì sử dụng WYSIWYG, điều đó khiến tôi tự hỏi: Tôi có lãng phí thời gian để phát triển các thành phần theo cách này không?

Chỉnh sửa: Để làm rõ - chủ yếu, mục đích ban đầu là các điều khiển này là để tôi sử dụng riêng. Tuy nhiên, đã có một số trường hợp khi chúng có thể hữu ích cho phần còn lại của nhóm của tôi hoặc có khả năng phát hành công khai. Tuy nhiên, giống như hầu hết mọi thứ, tôi có xu hướng nhìn thấy giá trị gia tăng tiềm năng rất lớn được cung cấp bởi công việc tương đối ít bất kể xác suất mà giá trị thêm sẽ được thực hiện.

+0

Có vẻ như một số người hiểu nhầm chủ đề ban đầu (hoặc có thể là tôi). Tôi theo giả định rằng ông đang yêu cầu hay không thiết kế điều khiển máy chủ cho sự tiện lợi của riêng mình khi làm việc với trình soạn thảo VS WYSIWYG là một sự lãng phí thời gian. – TheTXI

Trả lời

5

Không, bạn không lãng phí thời gian của mình. Cơ sở người dùng tiềm năng của bạn sẽ lớn hơn nếu người dùng WYSIWYG có thể dễ dàng sử dụng các thành phần của bạn. Nếu bạn là người dùng duy nhất của các thành phần này thiết kế chúng sao cho chúng phù hợp với phong cách phát triển của bạn. Nếu bạn thiết kế trực quan thì nó có ý nghĩa để có hỗ trợ WYSIWYG.

1

Nếu bạn cảm thấy thoải mái hơn với công việc của mình trong trình soạn thảo WYSIWYG và phát triển các thành phần máy chủ giúp công việc của bạn dễ dàng hơn, thì tôi không hiểu tại sao bạn nên cố gắng tuân theo các phương pháp dành cho nhà phát triển khác.

4

Bạn có thể tạo một UserControl và sử dụng các kỹ thuật khác nhau làm cho nó biên dịch thành một dll mà sau đó có thể được tham chiếu bởi các ứng dụng web của bạn:

Tổng quan về một số phương pháp: http://geekswithblogs.net/dotnetrodent/archive/2006/06/16/82136.aspx

phương pháp chi tiết: http://webproject.scottgu.com/CSharp/UserControls/UserControls.aspx

Tôi không bao giờ sử dụng các công cụ WYSIWYG vì nó không bao giờ trully là WYSIWYG khi bạn tạo javascript, CSS và những thứ khác. (Tôi biết VS2008 đã tốt hơn nhưng không hoàn hảo). Và các nhà thiết kế luôn luôn sooo chậm. Tôi thích viết mã bằng cách sử dụng đánh dấu.

Nếu bạn phát triển một thành phần thương mại mà bạn định bán, bạn nên dành thời gian để có IMHO đầy đủ tính năng nhất. Bao gồm cả WYSIWYG. Nếu các thành phần tòa nhà của bạn để nhóm của bạn có thể sử dụng chúng, thì bạn nên đánh giá lợi ích chi phí của thời gian cần thiết để có được các thành phần của bạn thêm bước.

+0

+1 Tài liệu tham khảo tuyệt vời mà tôi chưa từng gặp trước đây. Tôi không bao giờ xem xét tùy chọn này vì điều khiển người dùng dường như không hiển thị đúng trong WYSIWYG khi bạn yếu tố đằng sau hậu trường điên rồ như hiển thị dữ liệu động ... – BenAlabaster

+0

tôi cố gắng tránh điều khiển người dùng như dịch hạch – Shawn

+0

Tôi có một số điều khá phức tạp trang 7 tab mỗi với lưới và tất cả các loại chức năng. Chúng tôi đã chia nhỏ nó thành các điều khiển của người dùng để cho phép nhiều người cùng làm việc trên cùng một lúc và quan trọng hơn là giảm thiểu những gì bạn phải nghĩ đến khi làm việc trên đó. Sau đó, chúng tôi đã có thể làm cho ba tab sử dụng một ctrl :) – JoshBerke

2

Tôi nghĩ bạn không lãng phí thời gian của mình, đặc biệt nếu bạn muốn phát hành các điều khiển này để các nhà phát triển khác sử dụng. Nếu nỗ lực cần thiết thực sự là "thêm một chút" và bạn thấy nó giúp bạn trong các dự án lớn hơn, tôi nghĩ rằng các điều khiển của bạn được cải thiện bằng cách tương thích với công cụ WYSIWYG.

Cá nhân, tôi thường sử dụng mã HTML/XHTML nhưng thỉnh thoảng tôi thích sử dụng chức năng WYSIWYG. Tôi luôn thấy rằng các điều khiển thân thiện với WYSIWYG dễ sử dụng hơn các điều khiển dựa trên tất cả các mã được viết bằng tay.

0

Tôi đồng ý với các bài đăng trước. Tôi không nghĩ rằng bạn đang lãng phí thời gian của bạn. Kiểm soát WYSIWYG của bạn cho phép người dùng thực hiện mọi thứ theo cả hai cách, đã ném thiết kế và ném mã.Ngoài ra một số lần nó được dễ dàng hơn để khám phá những gì một điều khiển không khi bạn sử dụng trình soạn thảo tài sản, apposed để thực hiện thay đổi của bạn trong mã và sau đó biên dịch và chạy các ứng dụng.

0

Khi tôi bắt đầu chương trình, tôi yêu WYSIWYG và sử dụng nó cho hầu hết mọi thứ.

Tôi bắt đầu mã html bằng sự cần thiết, luôn có điều gì đó mà tôi chỉ không thể sử dụng trình soạn thảo WYSIWYG. Có thời gian trôi qua tôi nhận ra rằng nó đã được nhanh hơn cho tôi chỉ đơn giản là phải html hơn bằng cách sử dụng chuột để thiết lập các thuộc tính, do đó, thời gian trôi qua tôi sử dụng nhiều hơn và nhiều hơn nữa html cho đến khi không có trình soạn thảo WYSIWYG cho tôi.

Tại sao tôi kể cho bạn câu chuyện này? bởi vì kinh nghiệm cá nhân của tôi nói với tôi rằng một lập trình viên mới bắt đầu sẽ yêu WYSIWYG và nỗ lực của bạn để thực hiện các điều khiển máy chủ và một lập trình viên cao cấp sẽ không cung cấp cho bạn bất kỳ khoản tín dụng nào cho nó.

Ý kiến ​​của tôi là bạn nên làm theo ý muốn. Nếu bạn làm theo cách này để làm hài lòng người khác, đừng bận tâm nếu không có lập trình viên mới bắt đầu trong nhóm của bạn.

Đó là 5 xu của tôi;)

+0

Còn các lập trình viên tương lai có thể duy trì các ứng dụng tôi phát triển thì sao? Trong khi không có lập trình viên mới bắt đầu trong nhóm bây giờ, nó không có nghĩa là sẽ không có tuần tới ... – BenAlabaster

+0

Tôi nghi ngờ bạn có thể xây dựng lại html được tạo ra bởi các điều khiển thuật sĩ của riêng bạn. Hoặc kiểm soát lịch, cho rằng vấn đề, mặc dù tôi thực sự ghét lịch. –

+0

@joel - và làm cách nào chúng tôi tạo chúng trước asp.net? – annakata

2

Để sử dụng cho riêng bạn, bạn đã biết bạn đang lãng phí thời gian hay chưa.

[tôi đi vào nơi trú ẩn nghiệp-bom]

Đối với cộng đồng và phần còn lại của nhóm của bạn tôi sẽ đưa ra một quan điểm chống lại dòng chảy mà bạn có thể là ... cũng không lãng phí thời gian của bạn, nhưng có thể không tận dụng tối đa nó. Tôi nghĩ rất ít nhà phát triển web sẽ sử dụng các dịch vụ WYSIWYG một cách nghiêm túc, tuy nhiên nếu đa số có thể sử dụng điều khiển của bạn ở cấp mã tay và thiểu số có thể kéo và thả của họ thì bạn đã cung cấp lợi ích của sự lựa chọn. một điều xấu xa. Ngoại trừ có thể là nơi trẻ nhỏ và hành vi tốt có liên quan.

+0

Khi bạn nói "sẽ không nghiêm túc" - điều gì đó giống như GridView nơi nó dễ dàng hơn nhiều kéo và thả và thiết lập các thông số cơ bản hơn mã tay toàn bộ điều. Chắc chắn sẽ dễ dàng hơn để kéo/thả, định cấu hình và sau đó vuốt tay đánh dấu kết quả? – BenAlabaster

+0

@balabaster: GridView là một trong những ví dụ về kiểm soát có nhiều hạn chế nhất. Theo mặc định, Microsoft không hiển thị các phần tử đó theo cách bạn có thể dễ dàng tạo kiểu cho chúng. Mặc dù, đó là lý do tại sao bộ điều hợp điều khiển tồn tại. –

+0

Đó là lý do tại sao một và hai lý do tại sao tôi không thích ASP.Net như một ngôn ngữ templating. – annakata

1

Tôi nghĩ bạn phải tham gia cuộc thăm dò đó với một hạt muối. Chỉ vì hầu hết mọi người trên Stack Overflow nói rằng họ viết mã HTML của họ không có nghĩa là hầu hết các nhà phát triển web đều làm. Các công cụ như Dreamweaver và Microsoft Frontpage là các công cụ rất phổ biến, ví dụ, chủ yếu là do các tính năng WYSIWYG của chúng. Các công ty lưu trữ web thường có các nhà xây dựng trang web WYSIWYG cũng rất phổ biến. Tôi cũng tự viết mã, nhưng tôi làm rất nhiều công việc tự do làm việc với các nhà phát triển web từ các công ty khác trên toàn thế giới và từ kinh nghiệm cá nhân của tôi, tôi có thể nói rằng hầu hết các nhà phát triển web đều sử dụng WYSIWYG công cụ. Nhà phát triển web càng có kinh nghiệm thì càng ít có khả năng sử dụng công cụ WYSIWYG, nhưng những người có ít kinh nghiệm vượt xa những người có nhiều kinh nghiệm.

+0

Giả sử bạn đã nhận xét sai bài đăng: P – Gerald

+0

LOL - Cảm ơn, đã sửa ... – BenAlabaster

1

Bạn có thể đặt ra câu hỏi cho chính mình ", các nhà phát triển khác có lãng phí thời gian kiểm soát mã hóa bằng tay không?".

Tôi thường chỉ cần kéo và thả các điều khiển trên trang và thay đổi html được tạo khi cần, nếu nó chỉ được sử dụng trên một trang. Nếu điều khiển và chức năng của nó được sử dụng trên nhiều trang trong cùng một ứng dụng web, thì tôi sẽ đi đến điều khiển người dùng. Khi nó chắc chắn sẽ được sử dụng trên các ứng dụng, sau đó tôi chỉ muốn mã một lần vì vậy tôi đi đến một điều khiển máy chủ tôi có thể dễ dàng phân phối. Tôi nghĩ điều quan trọng là nó (bố trí và chức năng) đang được sử dụng ở nhiều nơi, hoặc bạn sắp sử dụng nó ở nhiều nơi. Nó chỉ là một "sai lầm" để có mã trùng lặp ở nhiều nơi vì nó đã dành nhiều thời gian hơn để phát triển mã có thể tái sử dụng cho một lần sử dụng. Thêm vào đó, nó là phần mềm, vì vậy bạn có thể thay đổi nó sau này!

+0

Đây là những gì tôi thường làm: Kéo và thả, định cấu hình, tinh chỉnh/đánh dấu đánh dấu khi cần thiết. Nó nhanh hơn và giúp giữ cho hình ảnh lớn trong tâm trí thay vì nhận được mired xuống với các chi tiết. Điều khiển máy chủ có thể tốn nhiều thời gian hơn để xây dựng, nhưng tiết kiệm rất nhiều thời gian trong tương lai. – BenAlabaster

1

Tôi nghĩ câu hỏi thực sự của bạn có thể là, "có cách nào để phát triển giao diện người dùng của tôi mà tôi nên tìm hiểu thêm, bởi vì nó có thể tốt hơn cách tôi đang làm bây giờ?. "

Xét thứ nhanh chóng được thay đổi như thế nào, đó là một câu hỏi chúng tôi đều hỏi khá thường xuyên Tôi reember lần đầu tiên tôi nhìn thấy các trang web được xây dựng với Ruby on Rails, và sau đó tôi chạy qua một hướng dẫn mà có không bước cho wysiwyging, nhưng tất cả mọi thứ đã được thực hiện với CSS và chủ đề, và nó đánh tôi rằng có lẽ Dreamweaver không phải là môi trường hiệu quả nhất cho tất cả mọi thứ, và kết quả có thể được ít nhất là không kém phần hấp dẫn.

Vì vậy, tôi nghĩ rằng ít nhất cũng đáng thử các giải pháp thay thế để tạo ra một thông minh quyết định về những gì làm việc tốt nhất cho tôi, kỹ năng của tôi và yêu cầu của tôi. Tôi muốn những công cụ tốt nhất trong bộ công cụ của tôi, ngay cả khi tôi không cần chúng cho mọi dự án.

Đặc biệt vì bạn có vẻ đánh giá cao cách tiếp cận hiện tại của bạn đang chiếm một lượng thời gian đáng kể.

0

Tôi nghĩ tôi sẽ tạo điều khiển nếu nó được sử dụng ở nhiều nơi. Ngay cả khi bạn viết mã html, nó vẫn tiết kiệm thời gian và đơn giản hóa công việc. nhưng tôi đồng ý rằng html/css mã hóa tay là hiệu quả hơn, các nhà xây dựng trang web WYSIWYG không hỗ trợ điều này rất tốt.

1

Tôi sẽ nói rằng nếu nó thực sự chỉ là một công việc phụ thêm một chút và nó cho biết thêm rất nhiều giá trị thêm nó khó để thụ thai nó có thể là một sự lãng phí thời gian. Người dùng đến phía sau bạn mà nhìn để sử dụng các thành phần của bạn trong tương lai sẽ tìm thấy nó dễ dàng hơn rất nhiều và sẽ tiết kiệm rất nhiều thời gian mà nếu không sẽ được chi tiêu mã hóa bằng tay. Chưa kể rằng nếu bạn có thể kéo và thả một thành phần bằng một cú click chuột và kéo, thì tại sao lại lãng phí các tổ hợp phím?

1

Giống như mọi thứ khác, câu trả lời thích hợp là 'nó phụ thuộc' ...

Bạn phải đo lường ROI của việc thêm chức năng này.

Đối với 'Tôi'; Cá nhân, tôi đã không bao giờ tạo ra một điều khiển web mà sẽ làm việc cho một trình soạn thảo wysiwyg, vì vậy tôi không biết bao nhiêu nỗ lực nó được.

Đối với 'R'; Nếu bạn làm việc trên một nhóm phát triển lớn, phân phối mã của bạn, sẽ tự tái sử dụng các điều khiển này trong trình soạn thảo wysiwyg, hoặc thậm chí chỉ muốn trải nghiệm, sau đó bạn chắc chắn sẽ nhận được lợi tức của bạn. Nhưng nếu làm điều này là dựa trên các lập trình viên trong tương lai; bạn có thể nghiêng một chút vào bên tối ưu hóa hơn. (IMHO)

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