�ݺ�ߣ

Editor's Notes

• #6: This is Bob. Bob is the resident developer at his organization. He mainly develops web applications in ASP.NET, and he’s pretty good at it. His organization has just decided to deploy SharePoint, and Bob has been charged with developing applications on this new platform. Bob is an Accidental SharePoint Developer.Bob does some research, and he discovers that SharePoint is really an ASP.NET site, and he learns that he can leverage his existing ASP.NET skills to build SharePoint solutions. So in Bob’s mind, every development task he takes becomes a User Control wrapped in a Web Part.By approaching SharePoint development in this manner he is limiting the options available to him to build solutions in SharePoint. The solutions he will creates incur the highest cost to develop, the heaviest burden on the administrators, and the least functional user experience.
• #7: In this example, Bob has to display some SharePoint data on a page. For some reason he has to provide functionality not available in the OOB list view page. Maybe he needs to filter and sort in a specific way. Maybe he needs to provide a link to related data. Maybe he needs to show workflow data inline with the list data. Bob doesn’t know all of these use cases can be handled through standard SharePoint UI elements with some customization.
• #9: Also, custom branding solutions and farm-wide resources like jQuery or custom application pages would be good candidates for farm-based deployments
• #10: SharePoint provides a robust user experience right out of the box. List views provide dynamic as well as static filtering and sorting. Every entity in SharePoint comes with custom forms right out of the box. Complex fields like Managed Metadata and People fields come with rich functionality built in. The ECB and Ribbon provide launch points for the user to perform more advanced actions on the data.Yet, SharePoint rarely solves everyone’s unique business needs right out of the box. In particular, SharePoint’s recognition of relational, or parent-child data, is nonexistent. There is no notion of the connectedness between the items of data in the SharePoint interface. The lookup column is perhaps the most glaring weakness in SharePoint’s structure.
• #11: We have seen that Microsoft has provided a great deal of OOB stuff upon which SharePoint’s interface is based. We’ve seen that there are always shortcomings when this interface is applied to real-world business scenarios.Fortunately, Microsoft has provided “hooks” in each of the UI elements, upon which we can “hang” custom solutions. These customizations enable us to avoid re-inventing new solution, and simply extend the existing building blocks we have at our disposal to create dynamic, appealing, and functional solutions tailored to the way our customers do business.
• #12: One example of how server code can create problems that JavaScript cannot: Recently I was called in to support a SharePoint application that was encountering some bugs. When I saw the code I discovered that the entire solution consisted entirely of about 30 visual web parts – that is, custom server controls deployed to the server, written in C#.Some of these web parts were written by very inexperienced developers who, because they didn’t understand how state management worked in ASP.NET, declared some variables as static, so their values would be available across postbacks. Some of these static variables happened to be collections, and every time the page was requested, items were added to this collection. But static variables are never cleaned up, so these collections grew and grew until they halted the entire server, until the admin had to reset IIS and the problem abated, temporarily.JavaScript can never do this because it runs on the client, not the server. The very worst a horribly-written JavaScript app can do is crash the user’s browser.
• #13: The most common stuff in the box we can use to build customized, no-code SharePoint solutions. jQuery is not an OOB SharePoint item but it is a defacto standard for web development, in my opinion.
• #14: For this demo our requirements are to manage a master-detail scenario using OOB SharePoint components. We can use list views and a little custom JavaScript to make this happen.
• #15: Packaging and deployment are a critical concept to understand, but for the purposes of this talk I am just going to lightly cover them. There are two ways to build these custom solutions, the easy way and the right way.The Easy Way involves using SharePoint Designer, and essentially the development is done in Production. This is clearly a poor practice form a software development perspective, but a LOT of companies do business this way, even big ones.The Right Way is marginally more difficult that the Easy Way but requires Visual Studio and a deployment process.
• #16: ** include custom child list elements as custom-rendered html elements using CSOM to query data and add items. Expose a hyperlink to new item form alongside.
• #17: Use Case: We have a Total Invoice Field that is calculated by the sale price, shipping charge, and the tax. This isn’t displayed in a new or edit form, but we can fake it by using jQuery to manipulate the DOM and insert the calculation into the table. We also have a requirement to make the Project lookup field read-only. We can also do that quite easily with jQuery.
• #18: Lookup fields are one of the most frustrating user experiences in SharePoint. They cannot be configured at all. Using JavaScript however we can hide the OOB lookup control and display a custom interface, and implement the functionality we want. We also retain the functionality to the hidden OOB lookup control.
• #19: A common complain from clients is that you can’t show workflow task data inline with the list item data. If you know how to manipulate the DOM with jQuery though, you can easily mix and match UI components form different pages in one place.
• #20: If we consider what we’ve discussed in light of these requirements, we can see that this is all stuff we’ve already seen. View metadata and view or download the document? A standard list view does that. View related data? A Parameterized list view will do that.We know that append-only comments, workflow history, and version history live in web pages elsewhere on the site, so if we can construct the urls to fetch these pages, we can grab that markup. It turns out we CAN get those urls, so the only thing left to do is implement the techniques and figure out how to stuff all this data into one page.