Configuration and customization
Web-based configuration
SharePoint is primarily configured through a web browser. The web-based user interface provides most of the configuration capability of the product.
Depending on your permission level, the web interface can be used to:
Manipulate content and page design.
Manipulate content structure, site structure, create/delete sites, modify navigation and security, or add/remove apps.
Enable or disable product features, upload custom designs/themes, or turn on integrations with other Office products.
Configure basic workflows, view usage analytics, manage metadata, configure search options, upload customizations, and set up integration.
SharePoint Designer
Main article: SharePoint Designer
SharePoint Designer is a 'fork' of Microsoft FrontPage, used to provide a faster configuration UI for some features in SharePoint.
It provides easy to access 'advanced editing' capabilities for HTML/ASPX pages, and workflow editing.
WYSIWYG HTML editing features were removed in Designer 2013, and the product is expected to be deprecated in 2016.
PowerShell & Central Administration
Microsoft SharePoint's Server Features are configured either using PowerShell, or a Web UI called "Central Administration". Configuration of server farm settings (e.g. search crawl, web application services) can be handled through these central tools.
While Central Administration is limited to farm-wide settings (config DB). It provides access to tools such as the 'SharePoint Health Analyzer', a diagnostic health-checking tool.
In addition to PowerShell's farm configuration features, some limited tools are made available for administering or adjusting settings for sites or site collections in content databases.
A limited subset of these features are available by SharePoint's SaaS providers, including Microsoft.
Custom Development
The SharePoint "App Model" in SharePoint 2013 provides various types of external applications that offer the capability to show authenticated web-based applications through a variety of UI mechanisms. Apps may be either "SharePoint-hosted" , or "Provider-hosted". Provider hosted apps may be developed using most back-end web technologies (e.g. ASP.net, NodeJS, PHP). Apps are served through a proxy in SharePoint, which requires some DNS/certificate manipulation in on-premises versions of SharePoint.
The SharePoint "Client Object Model" (available for JavaScript and .NET), and REST/SOAP APIs can be referenced from many environments, providing authenticated users access to a wide variety of SharePoint capabilities.
"Sand-boxed" plugins can be uploaded by any end-user who has been granted permission. These are security-restricted, and can be governed at multiple levels (including resource consumption management). In multi-tenant cloud environments, these are the only customizations that are typically allowed.
Farm features are typically fully trusted code that need to be installed at a farm-level. These are considered deprecated for new development.
Service applications: It is possible to integrate directly into the SharePoint SOA bus, at a farm level.
Customization may be surfaced via:
Application-to-application integration with SharePoint.
Extensions to SharePoint functionality (e.g. custom workflow actions).
'Web Parts' (also known as "portlets", "widgets", or "gadgets") that provide new functionality when added to a page.
Pages/sites or page/site templates.
Custom Development in SharePoint
Using Visual Studio
Using SharePoint Designer
Using Visual Studio : Visual Studio provides an alternative to creating SharePoint applications through SharePoint Designer. Visual Studio promotes rapid SharePoint development by providing such features as advanced debugging tools, IntelliSense, statement completion, and project templates. Visual Studio also takes advantage of advanced .NET Framework-based tools and languages. SharePoint projects can be developed by using either Visual Basic or Visual C#.
Benefits of using Visual Studio
1.)Workflows created in Share point Designer can be exported and imported to visual studio but the other way around is not possible.
2.)When developing solutions for SharePoint using Visual Studio, there is nothing special if you are targeting SharePoint. All of your sources files are handled as they normally are when you are using a version control system.
3.)You can use Visual Studio to group related SharePoint elements into a Feature. Next, you can create a SharePoint solution package (.wsp) to bundle multiple features, site definitions, assemblies, and other files into a single package, which stores the files in a format needed by SharePoint to deploy the files to the server.
In SharePoint 2010 we can create Sandbox Solutions using SOM
and In SharePoint 2013 we can create App Solututions (Cloud-App Model)
Continue to Part 4 ...........
No comments:
Post a Comment