There are some scenarios where we may need to set the value for the text box or some html control based up on the value returned from the JSON.
I had scenario where two method.
1) JSON call
2) Normal Jquery/javascript function call
My thought was that till JSON call got executed my second method wont execute, since JSON is ASYNC call it wont till it get response from JSON, it will start executing our Jquery method.
The problem starts here, i was setting few variable(global) in 1st method and using them in the 2nd method.
Since it takes time to execute the 1st method, so the values will be loaded properly.
So we need to use $(document).ready(function () {
$.ajaxSetup({'async': false});
//Method1()
//Method2()
});
This will work like synchronous and this fixed my issue.
Tuesday, December 27, 2011
Tuesday, October 11, 2011
Anti XSS
Today I came across one of the more weird issue in the production environment.
The site is developed in sharepoint 2010, and we have a search box in the page.
When user try to enter some of the javascript code ex: <script>alert('hi')</script> in the search text box, our site was broking(in the sence styles) all the times.
By default sharepoint will take care of Anti cross side scripting for the all the out of the box the control(specially with search).
But in our case it was breaking. After doing an investigation I came to know some where we are writing the text query in the page(As a title we are using this).
There we are not doing AntiXss for the that. After fixing this our page rendered as expected.
To get more information about AntiXss please follow this post.
http://ha.ckers.org/xss.html
The site is developed in sharepoint 2010, and we have a search box in the page.
When user try to enter some of the javascript code ex: <script>alert('hi')</script> in the search text box, our site was broking(in the sence styles) all the times.
By default sharepoint will take care of Anti cross side scripting for the all the out of the box the control(specially with search).
But in our case it was breaking. After doing an investigation I came to know some where we are writing the text query in the page(As a title we are using this).
There we are not doing AntiXss for the that. After fixing this our page rendered as expected.
To get more information about AntiXss please follow this post.
http://ha.ckers.org/xss.html
Saturday, July 23, 2011
Application Pages Vs Site Pages
Application Pages:
1.These are the normal .aspx pages deployed within SharePoint. Most common of them are the admin pages found in _layouts folder.
2.These are deployed either at the farm level or at application level. If they are deployed within _layouts folder or global SharePoint Virtual Directory, then they can be used by any SharePoint application (available at farm level), otherwise they can be deployed at application level only by creating a virtual directory.
3.These are typical ASP.Net aspx pages and can utilize all of the functionalities available within ASP.Net including code-behind, code-beside, inline coding etc.
4.These are compiled by .Net runtime like normal pages.
5.They can only use master pages available on file-system not within SharePoint Content Databases and for the same reason, you will notice that _layouts pages can only use Application master page deployed within _layouts folder and cannot use any of your custom master page deployed within SharePoint masterpage library.
6.If you deploy your custom ASPX pages within _layouts folder or within SharePoint application using a virtual directory, you will not be able to use SharePoint master pages and have to deploy your master page within the virtual directory or _layouts folder.
7.Application Pages cannot use contents as this concept is associated with SharePoint Page Layouts not with ASP.Net.
8.Since application pages are compiled once, they are much faster
9.Normally application pages are not web part pages, hence can only contain server controls or user controls and cannot be personalized by users.
10.Easiest way to deploy your existing ASP.Net web site within SharePoint is to deploy its pages as Application Pages within SharePoint. In this way you can convert any ASP.Net web solution as SharePoint application with minimal efforts.
11.SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages not against application pages.
12.Application pages can be globalized using Resource files only.
Site Pages
1.Site Pages is a concept where complete or partial page is stored within content database and then actual page is parsed at runtime and delivered to end-users.
2.Pages stored in Pages libraries or document libraries or at root level within SharePoint (Wiki pages) are Site Pages
3.You must be thinking why we should use such pages? There are many reasons for this. One of the biggest catch of the SharePoint is the page layouts, where you can modify page once for a specific content type and then you can create multiple pages using the same page layout with different contents. In this case, contents are stored within database for better manageability of data with all the advantages of a data driven system like searching, indexing, compression, etc and page layouts are stored on file system and final page is created by merging both of them and then the outcome is pared by SharePoint not compiled.
4.Site Pages can contain web parts as well as contents placeholders, and all of them are stored per page-instance level within database and then retrieved at run time, parsed and rendered.
5.Another advantage is they are at user-level not at web-application or farm level and can be customized per site level.
6.Since their definition is retrieved from database, they can utilize master pages stored within SharePoint masterpages library and merged with them at run time for rendering.
7.They are slower as compared to Application pages as they are parsed everytime they are accessed.
8.SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages not against application pages.
9.Since they are rendered not compiled hence it is not easy to add any inline code, code behind or code beside. Best way of adding code to these pages is through web-parts, server controls in master pages, user controls stored in "Control Templates" folder or through smart parts. If you want to add any inline code to master page, first you need to add following configuration within web.config:
PageParserPaths
PageParserPath VirtualPath="/_catalogs/masterpage/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" /
PageParserPaths
10.To add code behind to SharePoint master pages or page layouts, refer to this MSDN article
11.Since Site pages are content pages, hence all SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages.
12.Variations can only be applied against Site pages for creating multilingual sites.
13."SPVirtualPathProvider" is the virtual path provider responsible for handling all site pages requests. It handles both ghosted and unghosted pages requests as shown below:
1.These are the normal .aspx pages deployed within SharePoint. Most common of them are the admin pages found in _layouts folder.
2.These are deployed either at the farm level or at application level. If they are deployed within _layouts folder or global SharePoint Virtual Directory, then they can be used by any SharePoint application (available at farm level), otherwise they can be deployed at application level only by creating a virtual directory.
3.These are typical ASP.Net aspx pages and can utilize all of the functionalities available within ASP.Net including code-behind, code-beside, inline coding etc.
4.These are compiled by .Net runtime like normal pages.
5.They can only use master pages available on file-system not within SharePoint Content Databases and for the same reason, you will notice that _layouts pages can only use Application master page deployed within _layouts folder and cannot use any of your custom master page deployed within SharePoint masterpage library.
6.If you deploy your custom ASPX pages within _layouts folder or within SharePoint application using a virtual directory, you will not be able to use SharePoint master pages and have to deploy your master page within the virtual directory or _layouts folder.
7.Application Pages cannot use contents as this concept is associated with SharePoint Page Layouts not with ASP.Net.
8.Since application pages are compiled once, they are much faster
9.Normally application pages are not web part pages, hence can only contain server controls or user controls and cannot be personalized by users.
10.Easiest way to deploy your existing ASP.Net web site within SharePoint is to deploy its pages as Application Pages within SharePoint. In this way you can convert any ASP.Net web solution as SharePoint application with minimal efforts.
11.SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages not against application pages.
12.Application pages can be globalized using Resource files only.
Site Pages
1.Site Pages is a concept where complete or partial page is stored within content database and then actual page is parsed at runtime and delivered to end-users.
2.Pages stored in Pages libraries or document libraries or at root level within SharePoint (Wiki pages) are Site Pages
3.You must be thinking why we should use such pages? There are many reasons for this. One of the biggest catch of the SharePoint is the page layouts, where you can modify page once for a specific content type and then you can create multiple pages using the same page layout with different contents. In this case, contents are stored within database for better manageability of data with all the advantages of a data driven system like searching, indexing, compression, etc and page layouts are stored on file system and final page is created by merging both of them and then the outcome is pared by SharePoint not compiled.
4.Site Pages can contain web parts as well as contents placeholders, and all of them are stored per page-instance level within database and then retrieved at run time, parsed and rendered.
5.Another advantage is they are at user-level not at web-application or farm level and can be customized per site level.
6.Since their definition is retrieved from database, they can utilize master pages stored within SharePoint masterpages library and merged with them at run time for rendering.
7.They are slower as compared to Application pages as they are parsed everytime they are accessed.
8.SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages not against application pages.
9.Since they are rendered not compiled hence it is not easy to add any inline code, code behind or code beside. Best way of adding code to these pages is through web-parts, server controls in master pages, user controls stored in "Control Templates" folder or through smart parts. If you want to add any inline code to master page, first you need to add following configuration within web.config:
PageParserPaths
PageParserPath VirtualPath="/_catalogs/masterpage/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" /
PageParserPaths
10.To add code behind to SharePoint master pages or page layouts, refer to this MSDN article
11.Since Site pages are content pages, hence all SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages.
12.Variations can only be applied against Site pages for creating multilingual sites.
13."SPVirtualPathProvider" is the virtual path provider responsible for handling all site pages requests. It handles both ghosted and unghosted pages requests as shown below:
Friday, May 6, 2011
Creating Mysite host in moss 2007
1) Create a new web application (e.g. http://mossdev1:25000/)
2) Inspect Managed Paths for the new web application. You should already have:
(root) - Explicit inclusion
sites - Wildcard inclusion
3) Delete managed paths:
sites - Wildcard inclusion
4) Create managed paths:
personal - Wildcard inclusion
mysite - Explicit inclusion
5) End state for managed paths should be:
(root) - Explicit inclusion (thanks to imsaurabh for catching this!)
personal - Wildcard inclusion
mysite - Explicit inclusion
6) Create a site collection at /mysite/ managed path. This will use a My Site Host template:
Choose correct web application (e.g. http://mossdev1:25000/)
Title: My Site Host (doesn’t matter, really)
URL: http://mossdev1:25000/mysite (no fill-in because path is explicit in managed paths)
Template: Enterprise (tab) -> My Site Host
Specify primary and secondary administrators.
Click OK.
7) Create a blank site collection at the / managed path to enable self-service site creation:
Choose correct web application (e.g. http://mossdev1:25000/)
Title: Blank site (doesn’t matter, really)
URL: http://mossdev1:25000/ (no fill-in because path is explicit in managed paths)
Template: Collaboration (tab) -> Blank Site
Specify primary and secondary administrators.
Click OK.
8) Enable Self-Service Management. Choose from Application Management -> Application Security.
Now that you’ve created the host, here’s how to make sure it works properly in the SSP’s My Site Settings:
1) Navigate to My Site Settings (go to your SSP’s admin pages, it’s the 3rd link in the 1st section).
a) For form’s sake, inspect the Preferred Search Center entry. This URL should end in /SearchCenter/Pages/.
Set Personal Site Services to http://mossdev1:25000/mysite/. Note that this points to the URL for the explicit inclusion path and My Site Host Template site collection you created above.
b) Set Personal site Location into just personal. Note that this points to the URL (after SharePoint puts context to it) for the Wildcard inclusion managed path you created above.
c) Choose the 2nd Site Naming Format: User name (resolve conflicts by using domain_username).
d) Enable Allow user to choose the language of their personal site.
e) Disable My Site to support global deployments.
f) Default Reader Site Group: NT AUTHORITY\authenticated users.
2) Inspect Managed Paths for the new web application. You should already have:
(root) - Explicit inclusion
sites - Wildcard inclusion
3) Delete managed paths:
sites - Wildcard inclusion
4) Create managed paths:
personal - Wildcard inclusion
mysite - Explicit inclusion
5) End state for managed paths should be:
(root) - Explicit inclusion (thanks to imsaurabh for catching this!)
personal - Wildcard inclusion
mysite - Explicit inclusion
6) Create a site collection at /mysite/ managed path. This will use a My Site Host template:
Choose correct web application (e.g. http://mossdev1:25000/)
Title: My Site Host (doesn’t matter, really)
URL: http://mossdev1:25000/mysite (no fill-in because path is explicit in managed paths)
Template: Enterprise (tab) -> My Site Host
Specify primary and secondary administrators.
Click OK.
7) Create a blank site collection at the / managed path to enable self-service site creation:
Choose correct web application (e.g. http://mossdev1:25000/)
Title: Blank site (doesn’t matter, really)
URL: http://mossdev1:25000/ (no fill-in because path is explicit in managed paths)
Template: Collaboration (tab) -> Blank Site
Specify primary and secondary administrators.
Click OK.
8) Enable Self-Service Management. Choose from Application Management -> Application Security.
Now that you’ve created the host, here’s how to make sure it works properly in the SSP’s My Site Settings:
1) Navigate to My Site Settings (go to your SSP’s admin pages, it’s the 3rd link in the 1st section).
a) For form’s sake, inspect the Preferred Search Center entry. This URL should end in /SearchCenter/Pages/.
Set Personal Site Services to http://mossdev1:25000/mysite/. Note that this points to the URL for the explicit inclusion path and My Site Host Template site collection you created above.
b) Set Personal site Location into just personal. Note that this points to the URL (after SharePoint puts context to it) for the Wildcard inclusion managed path you created above.
c) Choose the 2nd Site Naming Format: User name (resolve conflicts by using domain_username).
d) Enable Allow user to choose the language of their personal site.
e) Disable My Site to support global deployments.
f) Default Reader Site Group: NT AUTHORITY\authenticated users.
Subscribe to:
Posts (Atom)