SharePoint configuration files and deployment files are of an XML format. The SharePoint Object Model is typically the tool set used to manipulate SharePoint, however using Data View web parts offering up jQuery is one way to sidestep the Object Model. This is Middle Tier development, I believe. In it, one uses XSLTs to transform list definitions, fields, content types, and list instance creations which are all, again, driven from XML.
When creating a list in SharePoint one will end up with a folder that has an Elements.xml within it and also a Schema.xml within it. There is also a global, application-wide Elements.xml. In a second step in creating a list, FieldRef elements (which define columns) need to go into Elements.xml (either in the global file for access across numerous lists or in a list-specific list for a bounded context). It is then typical to create (within the global Elements.xml) content types which hold collections of FieldRef elements and thus act as canned templates of common list columns. One may make content types inherit from other content types. One will further define columns in the Schema.xml file for a list.
When creating a new global Elements.xml for a SharePoint project, right-click on the project in the Solution Explorer in Visual Studio 2010 and select: Add > New Item... Then pick the "Empty Element" type from SharePoint > 2010 types. Only this will create an appropriate folder to house a global Elements.xml file. If you merely create a folder and make an Elements.xml file in it as much will not work. At the "Features" folder in Visual Studio 2010, right-click and pick "Add Feature" which will allow you to add the Elements.xml file to a deployable feature.
Views constrict what columns may be seen in a list based upon various factors and can act sort of as pseudosecurity in forbidding certain varieties of users from seeing certain things. You may also use Views within web parts to cosmetically/aesthetically style lists and break them up into subsections.
Every time you create a content type a "hidden" mirrored content type is also created. Femi recommends that when using spmetal (LINQ to SharePoint) that one interface with the "hidden" content types.
Feature Explorer allows one to put stuff into (and take stuff back out of) a feature. Feature collections are ASP.NET packages of a .wsp file type. One may rename a .wsp to a .cab to look inside of it in much the same way one may rename a .docx file to a .zip file.
Over 62 million SharePoint 2010 licenses have been sold. Moreover, SharePoint is a for-profit offering from Microsoft and is making the company money. It is not Silverlight or something comparable that Microsoft is just going to flake out on.
Within a SharePoint farm will lie n number of "web apps." Within a web app will live n number of site collections which correspond to spsite objects in C#. Site collections can have n number of "webs" which are actual web sites and correspond to spweb objects in C#. So a spsite is not a web site, a spweb is. This one of the common distinctions that SharePoint developers are asked about in interviews to ensure they are not noobs. The term "site" is often used to refer to an spweb just to make things a little bit more confusing. An spsite (site collection) is a collection of security concerns (permissions, etc.) that may bridge a series of spweb objects. What is the difference between a "web app" and the spweb objects? The "web app" is sort of supersite containing the webs. The default SharePoint site on a server and the SharePoint administrative site are examples of "web apps." A typical url will show the hierarchal arrangement like so: https://www.example.com/site/specificspsite/specificspweb/ ...where herein the second to last chuck of the route references a specific spsite and the last chunk of the route references a specific spweb. A spweb will have SPList (list) and SPFolder (folder) objects. A SPFolder may hold SPFile objects and other SPFolder objects.
When one creates a new SharePoint site in Visual Studio it will be, by default, of ASP.NET 3.5. One may click on the project in the Solution Explorer and press F4 to set the "Site URL" property. This will define where in a URL (within a web app) a spweb will be published to when one right-clicks on the project in the Solution Explorer and picks the "Deploy" option.
There is a way for administrators to go to: Site Actions > Site Settings ...in the UI to then have the option to open a spweb in SharePoint Designer (a free download) to allow for FrontPagesque administration.
One may make a hidden web part and put jQuery within it. This is an ideal place to incorporate jQuery.
No comments:
Post a Comment