Serach only word documents in sharepoint 2007 search.

Serach only word documents in sharepoint 2007 search.
There are two ways to search only word documents in sharepoint site

1. Creating Search Scope
2. Property search

1. Creating Search Scope:Navigate to "Search Settings" in Search Category.
Click on "Metadata Property Mappings" and check for "FileExtension" has check for 'Allow this property to be used in scopes' as below.

Now click on "View scopes" in Scopes category. Click on "New Scope" provide the following detailsTitle as "word docs" and select "Use the default Search Results Page" radio button and click on "ok"click on "Add rules" against to newly created "word docs" and provide following informationselect "Property Query (Author = John Doe)"select "FileExtension" from Add Property restrictions dropdown.provide "doc" value in the subsequent textbox.select "Require" radio button.click on "ok"Go back to search settings, click on 'Content sources and crawl schedules' select 'Start Incremental crawl' from'Content sources and crawl schedules'.
That's it. Go back to sharepoint site. Navigate to 'Advanced Search'.provide the keyword that you want to search in "All of these words:" and select "Word docs" from 'Result type'and click on 'Search' button to get the expected result.

2. For example if you are looking for "title" keyword in word documents.provide the information as 'title filetype:doc' in search box which yields the same results as above for this no need to set the search scope

Creating Content Types using Features

Content Type is a logical collection of site columns.(refere my last post to know more about site columns).
Any page layout you create as a template for pages on your site must be associated with a content type. Generally each column in the content type will be matched to a field control on the page layout, allowing the author to enter content to be stored in each column.

Fortunately creating content types as features is fairly simple - CAML only, no need for a feature receiver (code). Alas VSeWSS can't help us much here but don't forget to use the CAML schema intellisense in VS by ensuring the XML file we're about to write is linked to the schema at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\wss.xsd.

Initially, the part that can seem complex is the ID structure for a content type. Having been happily using GuidGen in Visual Studio every time we need an ID for something in a feature (though never trusting the first one ;-)), it comes as a surprise to have to read documentation just about IDs. As explained in Content Type IDs, the structure reflects the ancestry/parentage of a content type, meaning the parent content types can be determined very efficiently since simple string/byte matching can be used thus reducing database lookups.

The basics are:

find the ID of the content type you are deriving from. This can be done by either examining the content type in the SharePoint UI (Site Settings > Manage Content Types) and copying the ID from the URL querystring. Alternatively, search the feature files which the MS developers used to deploy the out-of-the-box content types. The former is probably simpler but the latter gives more scope for learning.
Add '00' and then a GUID you have generated (i.e. with GuidGen) to the end (suffix). You now have a valid content type ID. Note that you'll get a meaningful exception on feature activation if it's not.
For any child content types, to generate their IDs you can now add a simple ID such as '01' or '02' to the ID generated in the previous step. It's not necessary to suffix the ID with '00' and another GUID now since your unique ID is in the string. This means any ID's you generate will be different from anyone else's, so you can use the simple option and use a 2 digit number rather than another GUID. This means your content type IDs shouldn't grow too long.
The rest is fairly simple. Just add a FieldRef element for each site column the content type uses, specifying it's ID and name. Note that the approach we used to create our site columns meant that we got to specify the ID for them in CAML. We just need to dig out the IDs we specified there. So in both features, the IDs are in easily edited XML rather than being in any compiled code or similar so they are fairly loosely-coupled. Of course in many cases you'd choose to have both artifacts in the same feature, and in the future I'll post about factoring with relation to features.

You should end up with something like for each content type you are deploying:-



Note that it's not necessary to repeat the fields declared in parent content types, though I notice some of the Microsoft features do this.

So now you have your content types deployed, they can now be used in document libraries/lists or associated with any page layouts you have. So next time is deploying master pages/page layouts/CSS etc. as a feature, including having the layouts automatically bound to the content types.
Reference:http://www.sharepointnutsandbolts.com/2007/04/deploying-content-types-as-feature.html

Creation of Site Columns using features

We can add a custom column to the sharepoint list or document library. Suppose if we have column called "Department", and if this need to be present in each and every list or document library. Instead of creating custom column for each and every list/document library, we create site column once and which can be used across all the lists/document libraries. This new feature available only in Moss 2007.

The simplest way of creating site column is navigate to SiteActions->Site Settings->Modify all site settings->click on Site columns under Galleries section, shows the list of all available site columns.

We can create a column with list of available data types.

Creating Site column with feature.

We can create the Site columns with feature.xml.
Create a folder called Moss.Features.SiteColumn
Create two xml files feature.xml and Element.xml as follows.
copy the below code in feature.xml

Id="{8C41689F-F45F-4b28-85B8-44C4B5197D02}"
Title="Moss.Features.SiteColumns"
Description="Custom MySite Columns"
Version="1.0.0.0"
Scope="Site"
Hidden="false"
xmlns="http://schemas.microsoft.com/sharepoint/">

Location="Elements.xml" />



Copy the below code in Elements.xml



ID="{4C67267C-B950-4cd4-8038-DEACA9EC2F74}"
Name="MyTitle"
Group="MyColumns"
DisplayName="MyTitle"
Type="Text"
Required="FALSE"
Sealed="TRUE"
MaxLength="250">


Note: here "Type" data type. You can mention any available datatypes.

Move this folder to 12hive feature folder, and install the feature as

stsadm -o installfeature -name Moss.Features.SiteColumns

Activate the feature as

stsadm -o activatefeature -name Moss.Features.SiteColumns -url http://servername:portno

This creates new site column called "MyTitle".
You can reuse this site columns for lists/document libraries.

stay glued for content types, Page Layouts, Master pages in my next posts.

Get back to me if you have any queries.
shreecanth@gmail.com

Increasing the performance of Publishing site of Moss 2007 in Mobile Devices

Have you ever been get a chance to look at how much size each page (empty moss pages or custom webpart with no data- pages hosted on moss) takes loading in moss 2007?
It takes nearly 500kb for each page load in moss 2007 site collection.

For each request to the Moss 2007 publishing page loads following basic files

Core.css
Controls.css
Core.js
Init.js
Ie55us.js
Editingmenu.js
Spellcheck.js

and lot more...

The Read access users doesn't require of loading all these files.
These files loaded into the in page, even though if we define our custom master page without any links to the above files.

But this can be a performance problem when the moss 2007 site is requested from the Mobile PDA applications.
We need to make our master page and conent pages lighter weight so that it can be easily accessed in the mobile devices.
To remove these files we need to create one HttpModule, which does the clean up of unneccesary files.

There is a great article available for removing of these files
http://www.ie-soft.de/blog/PermaLink,guid,968b0588-f306-467b-be51-54f7a8f2079d.aspx

Happy coding...

Thanks,
Shreecanth

Power of web.config changes in Asp.net 1.1

To inherit my asp.net page from our custom developed page.
All asp.net pages are inherit from System.Web.UI.Page class
for example
namespace Myproject.web
{
public class MyCustomPage: System.Web.UI.Page
{
}
}
public class Login: MyCustomPage
{
}
Instead of this we have a better workaround for this process.
Add the following tag in our web.config entry, by doing this whenever we add aspx page to our solution it automactically inherits from "MyCustomPage"

its really works wonder....
Reference article:http://ryanfarley.com/blog/archive/2004/06/08/766.aspx

Differnce between Asp.net and Sharepoint safe mode parser

When a request is comes for an .aspx page Sharepoint ISAPI takes care about who will serve the request. Asp.net or Safemode parser(sharepoint).Before this you should know the concept of sharepoint ghosted and unghosted pages.In sharepoint some pages are lie in physical folder of server i.e, _layouts or _vti_bin folder. These pages are accessible for all applications.These pages are call ghosted pages.If we edit these pages through designer or through front page 2003 the pages become unghosted and a copy of each page is stored in the application content database. To make it clearghosted pages are those rows in the docs table which have null values for the Content column and a non-null value for the SetupPath column which points to a file on the file system itself. The referenced file essentially serves as a template and content source.Any webpart page or normal pages are ghosted by default.
The main difference between Asp.net and sharepoint pareser is, in asp.net for each first request of the page is compiled into assembly, and next request onwards the compliled page gets executed. In sharepoints safe mode parser is not compiled. They are interpretative pages. Remember its not possible to make unghosted page to its original ghosted pageSo if there is any inline server code in aspx page the safe mode parser will not allow the page to load

Limitation of enabling session state

By default in Sharepoint session state is disabled. when you open any site collection web.config file you will see below line commented in http module
'add name="Session" type="System.Web.SessionState.SessionStateModule" '
The difference between session state in sharepoint and .net
In .net session can be enabled at page level. So the pages which doen't have the session can avoid the performance hit associated with it.But in sharepoint once the sessionstate is enabled for the application, all the the unghosted(customized) page forced to use sessionstate whether or not controls on that page require session state.
For ex: Assume your SharePoint server contains mostly unghosted pages. Let’s say there are 1000 unghosted pages on the site. You create a web part that requires session state. Let’s say that web part is only used on a few select pages (i.e. 2-3 pages). Enabling session state so that 2-3 pages can use the web part suddenly slows down the performance of the 998 other pages.SSo it is advisable not to use session state in sharepoint which degrades the performance of the application