This publication is intended as a useful quick-start guide for front-end developers delving into the realm of Sharepoint development. If you do happen to stumble across any information in this book that you feel should be corrected post-haste, please don’t hesitate to email me: I will thusly research the correction in question, and assuming it passes my rigorous, time-tested set of qualifications (read: “me lazily Googling for a few minutes”), I will amend this book and credit you somewhere in kind. Furthermore, Sharepoint’s default front-end code (that is, the HTML, CSS, and JS that are used by default within a fresh install of Sharepoint) is so horrific that you’ll likely begin immediately assessing how to rewrite or overhaul the existing code in a desperate attempt to bring it in line with modern web development standards. We’ll also walk through common vocabulary used during Sharepoint development. The answer to all of these questions is “Sharepoint.” Look, I’m not a scientist.
Dreamweaver 8 template not updating pages
Understanding the lingo of Sharepoint development is a huge part of being able to communicate with the back-end devs, so let’s take a look at a list of some of the terms you might come across.
It should be noted that this is only a partial list of Sharepoint terms; realistically, there are dozens, or even hundreds, of unfamiliar terms you might hear when working on a Sharepoint project.
In general, a single Sharepoint site (of which there could be many within the whole application, remember) is composited in the following manner: That is, a list/library full of data is fed into a web part, which displays that data on a page, which is a portion of an overall site or sub-site. If you’ll recall, I mentioned that Sharepoint does bear some similarities to other CMSes you might be familiar with; for example, you’ve probably grasped that this flow of information is pretty similar to the way a CMS like Wordpress would display data via a widget that you’ve placed on the page.
If it weren’t for Microsoft having some insatiable urge to give things convoluted names like “web part” and “list/library” instead of “widget” and “database/datastore,” you probably would have grasped that even more quickly. Unfortunately, you’ll find that’s a recurring trend within Sharepoint; Microsoft loves to rename things that are already commonly-understood within the web development community.
Technically, lists and libraries don’t have the same capabilities as databases, despite their contents being stored via SQL Server.
Their capabilities and differences are a bit outside the scope of this book, but if you’re interested, you can find more information here: In an extremely general sense, that’s a brief overview of Sharepoint and how a Sharepoint application or intranet site would be constructed.
As one could reasonably presume, this means that Sharepoint runs on the Microsoft stack; that is, the tech stack comprised of the following components: Older versions of some parts of this stack may also be supported, as well as SQL Server Express, but the above list tends to be the most common configuration.
Additionally, browser support tends to be a little spotty.
It can all become quite a behemoth, as you can likely imagine.