Life, SAP, Consulting, Programming, Coding, ASP.NET, Sharepoint, MVC, Javascript, PHP, WebDesign, CSS, HTML

Posts tagged ‘webpart’

Lựa chọn Webpart hay là User Control – Phần 2

Hoạt động của Webpart

Với đa số mọi người, đây gần như là cách tiếp cận duy nhất. Có nhiều bài hướng dẫn tạo ra Webpart. Các Webpart có nhiều điểm nổi trội so với những giải pháp cho vấn đề trong Sharepoint. Và trong vài trường hợp, chúng là giải pháp tốt nhất cho công việc.

Một ưu điểm lớn nhất của Webpart là mọi thứ đều có snawx. Bạn có thể thao tác với thanh công cụ, thay đổi mọi thứ theo cách của Webpart. Với control, bạn chỉ có thể thực hiện với những gì có sẵn mà thôi.

Mặt khác, điểm mạnh của User Control là điểm yếu của Sharepoint. Nó là một khái niệm mới, lạ lẫm, có thể mất thời gian để làm quen và tăng thời gian phát triển. Webpart lại có ưu điểm về hoạt động. Webpart là giải pháp có hiệu suất tối đa nhất, được hỗ trợ bởi kiến trúc khung trong cơ chế triển khai cơ sở hạ tầng Sharepoint. Tuy nhiên, như đã nói, điều này chỉ có ý nghĩa trong các tổ chức lớn, với các ứng dụng lớn đòi hỏi mở rộng. Trong thực tế, sự khác nhau là không lớn.

Đánh giá

Vì sự hiểu biết cơ bản về sự khác nhau là không đủ. Mục này sẽ đề cập sâu hơn về điểm mạnh và yếu trong các trường hợp khác nhau.

Lập trình trực quan

Một khi yếu tố quen thuộc không còn là lợi thế để cho việc lập trình nhanh chóng hơn thì tôi sẽ nghiêng về chọn Webpart. Lập trình dao diện kéo thả được hỗ trợ rất mạnh bởi Visual Studio. Cái này sẽ khiến nhiều người suy nghĩ làm thế nào tận dụng hỗ trợ kéo thả đó.Tuy nhiên, theo tôi, muốn có một giao diện linh hoạt mềm dẻo. Thì chúng ta sẽ phải dùng những cách trang trí riêng, phù hợp với những hoàn cảnh khác nhau. Hoặc khi muốn hiển thị một tập các links hoặc thay thế một chuỗi trong ouput, những lợi thế của User Control trở nên vô dụng. Trong trường hợp này, rõ ràng Webpart là sự lựa chọn hợp lý.

Đồng bộ

Một trong những ưu điểm của User Control là bạn có thể mang nó từ một trang Sharepoint vào trong một ứng dụng ASP.NET khác. Tuy nhiên, điều gì xảy ra nếu trong User Control đó lại sử dụng thư viện Microsoft.Sharepoint.dll. Tất nhiên là không thể dùng nó ngoài Sharepoint được nữa rồi. Vì thế lợi thế sử dụng lại biến mất khi bạn sử dụng trực tiếp các tính năng trong Sharepoint. Trong trường hợp này, nếu giao diện là được giản thì hợp lý hơn là code bằng Webpart. Webpart có sự đồng bộ cần và tích hợp sâu vào Sharepoint.

Hoạt động

Mặc dù hiệu suất hoạt động của một ứng dụng luôn nằm trong đầu của người lập trình. Tuy nhiên, ngày nay, một cái Server có giá khoảng $5000, trong nhiều dự án, nó chỉ có giá trị rất nhỏ so với lương trả cho lập toàn bộ nhân công. Vì thế ngày nay, vấn đề hoạt động rất ít khi được chú ý nhiều.

Tuy nhiên vẫn có những trường hợp mà hiệu suất hoạt động được đặt lên tiên quyết. Những thành phần thường xuất hiện trên mọi trang tốt hơn nên dùng Webpart. Ngay cả với những trang có lượng truy cập thấp. Một ví dụ khác, khi xây dụng một thành phần có chức năng lấy các đường dẫn tương đối và tăng khả năng tạo cache hợp lý. Nó sẽ được tạo ra nhờ Webpart chứ không phải là User Control. Vì nó được load ra ít nhất 2 lần trong một trang – 1 trong header và 1 trong footer. Thành phần core này được sử dụng để đảm bảo hiệu suất hoạt động của Site mặc cho sử dụng một User Control sẽ dễ dàng hơn.

Cơ chế tích hợp

Xem xét cuối cùng là Webpart phải dựa vào cấu hình của mẫu thiết kế. Nói cách khác, chúng ta nên tạo ra một ứng dụng cho phép lấy nội dung từ URL hơn là tạo ra từng Webpart riêng biệt cho từng URL được gọi đến. Cấu hình cơ bản này rất hữu ích trong việc giảm code trùng lặp vào nâng cao giải pháp tổng thể.

Với Smartpart(Xem phần 1), có một vấn đề đó là quản lý cách thức mà thông tin được đẩy vào cho User Control. Giải pháp đó là tạo một đối tượng để chứa Control hoặc là tạo ra lớp con của SmartPart để thêm vào khải năng đẩy thông tin vào thuộc tính từ Sharepoint, Câu truy vấn từ URL hay là từ FORM POST. Điều này cho phép bạn cân bằng các tính năng của SharePoint và không cần tạo ra các liên kết trực tiếp giữa Control và Sharepoint.

Ví dụ, User Control có một thuộc tính Public để chứa ID của bản ghi (record) hiện tại. Những trang nào mà có ID cho bản ghi hiện tại lấy ra từ Sharepoint sẽ lấy được nó vì đó là thuộc tính Public. Nó có thể đẩy ID đó vào thuộc tính public của User Control. Điều này cho phép User Control không bị dính chặt với Sharepoint mà vẫn tận dụng được các tính năng của Sharepoint.

Kết luận

Như vậy, hầu hết những quan điểm cho rằng viết một chức năng cho Sharepoint là phải dùng Webpart là sai. Thích hợp hơn là chúng ta sử dụng ASP.NET user Control để tân dụng chúng trong Sharepoint bằng những kỹ thuật như là SmartPart.

Advertisements

Lựa chọn Webpart hay User Control – Phần 1

Mình đã làm quen với sharepoint được một thời gian rồi. Cứ nghĩ là kiểu gì cũng phải dùng webpart để Customize. Mình nghĩ có nhiều người có suy nghĩ giống thế. Hôm nay đọc được bài này, viết lại để mọi người cùng suy xét.

Các chuyên gia khuyến cáo người dùng không nên sử dụng Webpart nếu không thật sự bắt buộc. Điều đó đi ngược lại với hầu hết mọi người tin rằng để làm việc với Sharepoint thì phải thông qua Webpart. Điều này chỉ đúng một phần . Sharepoint chỉ hiển thị Webpart trên một trang. Tuy nhiên, có nhiều phương tiện (shim) cho phép bạn tạo ra User control và hiển thị nó như là Webpart. Theo cách nhìn của Sharepoint, Phương tiện đơn giản là 1 User Control trong .NET 2.0

Khi phải ra quyết định là cách nào để đưa nội dung vào một Webpart Sharepoint trên một Portal, câu hỏi đặt ra là lúc nào bạn nên sử dụng một Webpart, lúc nào thì sử dụng User Control. Để hiểu được vấn đề này, chúng ta cần phải hiểu được những điểm mạnh và yêu của mỗi phương pháp.

Sức mạnh của User Controls

Khả năng triển khai một User Control như là một phần của triển khai Sharepoint là rất hữu hiệu. Đó là 1 công nghệ mà những người lập trình đã quen thuộc với và được hỗ trợ từ rất nhiều công cụ trong Sharepoint.

Ưu điểm

Có 3 ưu điểm chủ yếu của User Control khi bạn làm việc với Sharepoint. Đó là sự quen thuộc, khả năng sử dụng lại, và tốc độ phát triển.

Sự quen thuộc : Cái này thì chắc chắn là đúng rồi. Những ai đã lập trình với .NET thì chắc chắn đều biết về User Control. Khi chuyển qua nền tảng mới là Sharepoint, khái niệm này cũng không thay đổi. Đó là chìa khó để học hỏi cái mới thông qua liên kết với cái cũ.

Khả năng sử dụng lại User Controls không gắn liền với Sharepoint. Khi tạo một Project để viết một User Control thì bạn vẫn có thể dùng nó cho những nền tảng ngoài Sharepoint với sự chỉnh sửa tối thiểu.

Tốc độ phát triển Với User Controls, bạn có thể trực tiếp Debug trong VS mà không cần phải thông qua Sharepoint. Một điều nữa đó là User Controls, người phát triển có thể tận dụng tối đa các công cụ hỗ trợ kéo thả, các Control có sẵn của VS. Quá nhiều cái có sẵn.

Yếu điểm

User Control không phải hoàn mỹ nếu không thì sẽ không có những bàn cãi sử dụng Webpart hay User Control. Có một vài chỗ mà User Control không phù hợp, không phải là giải pháp.

Hiệu suất hoạt động User Control có thể dùng cho những site thông thường. Còn những site cực kỳ lớn thì nên xem xét đến vấn đề hiệu suất bị ảnh hưởng khi có quá nhiều Webpart thực ra lại là các User Controls. Thực tế không có nhiieeuf vấn đề khi lựa chọn User Control hay Webpart với hiệu suất của Sharepoint, tuy nhiên lại có sự phản đối mạnh mẽ trong các tổ chức lớn về vấn đề này.

Cài đặt Việc cài đặt User Control là khá rắc rối. Không giống như biên dịch một site thành một file DLL hay tạo ra một project với hàng loạt các User Control. Cơ chế nhúng User Control của Sharepoint hoàn toàn khác hẳn. Mọi người vẫn xem đó là một Smartpart. Mặc dù đó là một thách thức nhưng lại có nhiều công cụ thực hiện điều này dễ dàng.

Keep your SharePoint rich text editor toolbar in view

Recently a client was finding it difficult to edit HTML in a publishing page when the HTML was lengthy and went over a page in the browser. Basically the floating toolbar of the Rich Text Editor (RTE) in SharePoint went out of view as the page scrolled down.

 

I could think of three possible solutions…

Enable the PopupEditorMode of the RichHtmlField control.

Write some script to keep the floating toolbar in view

Change the CSS so that the HTML editor didn’t grow over a certain size and a scroll bar appeared.

Enable the ‘popup mode’ of the HTML editor

 

This is relatively straight forward and solves the problem. Basically you have to set the PopupEditorMode property on your RichHtmlField.

<PublishingWebControls:RichHtmlField id=”Content” PopupEditorMode=”true” FieldName=”…

 

There are a few problems with this approach. Firstly you have to visit every PageLayout to change the declaration of the RichHtmlField control. This can be a pain when you have 20-30 layouts in your publishing site.

 

Secondly, it slows down the page editing as you have to wait for the dialog to display each time you want to edit a field on a page. And lastly the WYSIWYG experience isn’t as good as with floating toolbar.

 

In order to save visiting every layout and so that you can try changing the behavior without all the effort I have created a javascript file which reverses the PopupEditorMode property. Adding this javascript file to your master page will cause every HtmlFieldControl to display a popup, unless the PopupEditorMode is True.

<script src=”/switchHtmlPopupMode.js”></script>

 

Upload the javascript file to your site and add the SCRIPT tag to your .master page. Ensure the SRC attribute points to the location of the uploaded .js file. All your editors should now popup.

Keep the floating HTML editor toolbar in view

 

Unfortunately this is not available OOTB and so I had to write some javascript to enable this. You can download the javascript for this solution and add it to your master page…

<script src=”/scrolltoolbar.js”></script>

 

When added to your master page or layout it will ensure that any HTML editor toolbar will stay in view even when your page scrolls. This means that as you are editing your page the floating toolbar will move down with you as you type, ensuring you always have access to its functionality.

 

To add this to your page simply copy the scrolltoolbar.js up to your site (using SharePoint designer) and add the SCRIPT tag above to your .master layout…ensuring that the SRC attribute points to the correct location.

 

Adding this script file also has the benefit of ensuring the floating toolbar is always visible when you try to edit HTML at the bottom of the RTE editor and the top of the RTE is scrolled out of view.

Changing the CSS of the editor

 

This I have to say was not my favorite of the solutions. I think that getting this to work correctly in all situations would be very difficult and as such have not tried it.

 

I have asked a ‘CSS guru’ to have a look at this when he has a spare five minutes. If he comes up with anything I will post it here.