Sharepoint 2010 jQuery - Hiding unnecessary columns in Calendar

I was working on a Training calendar project where i want to hide some predefined hidden field in Calendar list, i have done this in SharePoint 2007 but when i use the same java script in 2010 it doesn't work. So the following code snippet will be helpful for you guys.

1. Enter edit mode on NewForm.aspx, by adding ?PageView=Shared&ToolPaneView=2 to your URL
2. Add the Content Editor Web Part and move it to the bottom of the page
3. Click on Source and enter the following text

01	<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"type="text/javascript">script>

02	<script type="text/javascript">

03	$(function() {

04	$('td.ms-dttimeinput').hide(); //hides the times on Start Time

05	$('span[title=All Day Event] > input').attr("checked","checked"); // checks All Day Event

06	//hide all of the check-boxes I don�t need

07	$('tr:has(span[title=Recurrence])').not('tr:has(tr)').hide();

08	$('tr:has(span[title=All Day Event])').not('tr:has(tr)').hide();

09	$('tr:has(span[title=Workspace])').not('tr:has(tr)').hide();

10

});

11

script>

You�ll need to do something similar to your EditForm.aspx:

1. Enter edit mode the same way was above, leaving the ID=x and changing the �?� before PageView to an �&� (i.e. ../EditForm.aspx?ID=1&PageView=Shared&ToolPaneView=2)
2. Add the Content Editor Web Part and move it to the bottom of the page
3. Add the same jQuery code from above, but delete the first two lines in the function (since it�s already an All Day Event, there�s no need to set it, and the times will already be hidden)

DispForm.aspx will be slightly different because the HTML is different:

1. Enter edit mode the same way you did for EditForm.aspx
2. Add the Content Editor Web part and move it to the bottom of the page
3. Add the following code to the Source

1	<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"type="text/javascript">script>

2	<script type="text/javascript">

3	$(function() {

4	//hide all of the check-boxes I don�t need

5	$('tr:has(td[id=SPFieldAllDayEvent])').not('tr:has(tr)').hide();

6	$('tr:has(td[id=SPFieldRecurrence])').not('tr:has(tr)').hide();

7	$('tr:has(td[id=SPFieldCrossProjectLink])').not('tr:has(tr)').hide();

8

});

9

script>

DTAP for SharePoint

Overview: Development, Test, Acceptance and Production (DTAP).

To implement SharePoint solutions it is a good idea to have DTAP environments. DTAP can be as simple as 4 environments but I would recommend 5 or more separate environments for SharePoint.

Development
The base development machines can be standalone VM's with self contained SQL databases, AD, FAST, and SharePoint.  Additional software would include: InfoPath, SharePoint designer, U2U, Fiddler, firefox, IE8 and more.  You should have TFS or a source control repository for all developers to check compiling code into.

Continuous Integration (CI)

This box can range from very simple to a complex complete tear down rebuild on a daily basis with unit test.  At a minimum all code should be deployed daily.  All changes to CI and subsequent environments should be deployed via wsp's and PowerShell scripts.  Sometimes it is time efficient to write administration manual steps, this should be avoided where possible and if it is absolutely required, the documentation must be explicit and testable.

Testing
This environment is a build release, it is stable so testers can perform testing against a specific build.  Bugs should be documented (preferable in tied to source control changes).

Acceptance
End users should test the system pre go-live in this environment.  This phase can also be split into 2 environments namely: Acceptance and pre-production environments.  Used for user acceptance testing.

Production
This live system is only changed once the changes have gone thru change request management and have been deployed and tested on all the environments.  Pre-production should be as close a copy of the production environment as possible.  Production and pre-production must be kept as close as possible throughout the life time of the SharePoint farm.

Summary:

• Never do changes directly on the production environment. 
• Build a formalised change control process for SharePoint. 
• Minimum of 3 environments for small farms is my base guideline. 
• Environment changes should be done using wsp's and PowerShell not the UI where possible
  .

SharePoint is not a Database!

As users of SharePoint start using lists they start taking advantage of a very intuitive and highly configurable information management tool. Users who have been using Excel or Access in the past start seeing SharePoint as a kind of rapid application development platform for building structured data applications. However, this is where SharePoint’s list architecture breaks down because simply:

SharePoint is not a database!

Part of the problem is that business users designing lists are not familiar with basic database concepts - they just want to store their information. Part of the problem is false advertising by consultants and/or Microsoft that SharePoint is a miracle platform that can do anything - it does some things well but replacing your SQL server or even Access database isn't one of them. The other problem is there is no really good way for surfacing bi-directionally data from a database into SharePoint – the business data catalogue works only in read only mode and does not allow for updates back to the underlying data store.

Here are a list of some features that a database has that SharePoint does not support - the moment you need these features you will need a real database.

• Primary And foreign keys: one of the most basic concepts in a database is the enforcement of a unique identifier (either system generated or user supplied) that can identify a record and link across table in parent child relationships.
• Transactions: if two changes are required to go together and the second change fails you want the first change to be undone (rolled back).
• SQL language: complex queries can me written in code using a standard language. Queries can be saved and repurposed.
• Stored procedures: database programmers can write complex routines that can be called as reusable code blocks.
• Indexing and query optimization: used to improve performance, indexing allows the database designer to pre-index specific fields that are frequently used in queries to improve performance. In addition, most databases have optimization engines that based on what you are trying to fetch will optimize how the data is retrieved.
• Large data and binary fields: most modern databases allow you to store large binary files such as video files, large volumes of text, images, etc. in the database. SharePoint can be made to store large files as documents but you only get one per record and a generic binary object.
• Access outside of SharePoint: lists are accessible outside of SharePoint but only through XML or programming interfaces. Lists are not great data stores to be used for line of business applications written independently of SharePoint because the integration is relatively poor in comparison to running a SQL query on a database.
• Cascading deletes: if a parent record is deleted, its children should also be deleted. In most databases, this can be configured to happen automatically or else reject the delete of the parent until the children are deleted first. This eliminates the risk of orphan child records.

These features are considered basic in databases – they have been around for decades and even the most primitive databases such as Access or FileMaker Pro have most of these features.

Lists are great for flat, changing content especially when attached to unstructured documents. At least in the current version, lists are not substitutes for databases and shouldn’t be considered so. If you need a database, then you are better off building a proper database and using SharePoint as a front-end for surfacing that data through reports, dashboards, etc. or as a host for data entry components such as InfoPath forms or custom build web parts.

SQL databases used in Sharepoint

There are quite a number of databases generated during a Sharepoint install and depending on the "Farm" configuration there might be more or less. A lot of SQL DBA's get quite annoyed when all these databases suddenly appear in their system and they have no idea what each database does or why it is there.

I have therefore decided to explain what databases get created during a MOSS install and what the purpose is behind each. A WSS install generates less databases and therefore I decided to focus on a MOSS install as this generates the most.

Below is a list of the databases generated by Sharepoint, the names may differ per deployment, but the purpose remains the same:

• Config Database for the Farm - Sharepoint_Config - stores configuration information about the servers deployed in the farm , their individual configurations settings and some security information. Without this database there is no Sharepoint.
• Content database for the Admin Console - Sharepoint_AdminContent_GUID - sharepoint uses its own technology to render the web based admin console for Sharepoint. Therefore it needs it's own content database to stored the configuration settings for the web parts used. The actual data configured using this console is stored in the config database for the farm. The name for this database is system generated and cannot be controlled during the installation process and therefore it ends with a GUID.
• Config database for the SSP (Shared Service Providers) - BPS_SharedServices_DB - during the configuration process a SPP is defined to configure all the Shared Services used by Sharepoint. All the Configuration settings for these services are stored in this database. The name of the database can be controlled during the creation process and should be descriptive of the purpose.
• Content database for the SSP Console - BPS_SSP_Content - just like the admin console the SSP also needs a web site to allow you to configure the shared services and these also use web parts and lists. Therefore the SSP also needs its own content database to store these settings.
• SSP Search database - BPS_SharedServices_Search_DB - this database is used by the Enterprise search service to store metadata about the information crawled including security information. This is typically used for information stored external from Sharepoint.
• WSS search database - WSS_Search_sps-dc1 - this database is used by the WSS core components to store metadata about content stored inside the Sharepoint web application content databases. This is created during the installation process.
• Web Application Content - Office_Content - this is the content database for the first user based web site in Sharepoint. Before the users can actually use Sharepoint a "Web Application", Site Collection and Site must be built. This database stores all the information generated within this web application.
• Additional content databases - Office_Content_2 - new content databases can be created to host additional "Site Collections" and "Web Applications" and there could be hundreds of these.