I'm new to SharePoint 2010 development and I was wondering if it was possible to add the new "Visual Web Part" to a masterpage. In 2007, I would create a user control and put the ascx reference in the masterpage. Should I continue to do the same thing for 2010 or I can I use the Visual Web Part prototype to do the same thing?
A Web Part is just a control that can be placed on a page (via a Web Part Zone) by an end user rather than a developer. But it's still a control. So, as a developer, if you want to place it on a page (or master page) at design time, you can do that.
However, if this web part is only going to be used on the master page, then you might want to continue using a custom user control like you did in SharePoint 2007. There is no need to have the extra overhead of making it available to end users if it is only meant to be used once on the master page.
Related
I want to customize the SharePoint 2013 online(office 365) "About me" linked page (personimmersive.aspx) to a custom look and feel.
Even clicking on any SPUser name, for ex in a list item modified by is "John Smith" if we click on it goes to about me page.
This page resides under mysite but I cannot see this page is SharePoint 2013 designer to edit, but modifying SharePoint pages in designer is not always the best way.
Can I just create a new page and redirect all Profile page request to that custom page?
IF I create app parts and edit the page I cannot edit the top portion of the page.
redirecting may not be a feasible approach, specially on the online versions
you can try to take advantage of web parts and css to do what you can
The biggest change is that you can’t edit the entire top portion of
the page. These used to be in a web part zone, and you could choose to
add/remove the web parts. Now they are fixed, with no ability to move
them around or change the parts.
We had removed the Activity Feed web part previously because we were
using Yammer newsfeeds and group feeds embedded throughout the site,
and this part always showed “No activities”. Now this is back again,
with no way to remove it, short of editing the page in SharePoint
Designer.
There are still web part zones on the bottom, but really the problem
is no control over the display of most of the top of the page.
http://weshackett.com/2014/04/office-365-new-profile-page/
There is personImmersive.aspx in SharePoint Designer, you should be able to find it in All Files. Just make sure you connect to [your_domain]-my.sharepoint.com instead of [your_domain].sharepoint.com.
you can't customize the page completely.However you can add custom web part and custom css to change the look and feel to a great extent.
#tiago duarte you can still remove the activity web part.This can be done using script editor webpart and hiding the complete block/div.
I am an experienced .NET Developer acting as interim SharePoint Developer, and am new to SharePoint. After determining that I need to go with an application page instead of a site page for a new project due to it's complexity and need of custom code behind. Before developing the entire solution, I wanted to tie up the loose ends of my understanding of application page deployments. I need to add this page as a URL on the left side of a Site Collection page (kind of like what happens when adding a subsite to a site page.) I have read about the modules, which seems extremely hacky to me. There must be a better way to develkop a custom page on top of SharePoint without the page being accessible to anyone on the entire site.
EDIT
The application I am wanting to develop on top of SharePoint exists purely for data entry and reporting purposes.
Have you considered using a Webpart?
With a visual webpart which is essencially a usercontrol wrapped in a webpart you can add as much complexity as you want and you also have code behind to hook to events etc.
The benefit of using a webpart is that you can then drop it on a page, and use all OOB sharepoint access controls.
You mention that you want to develop a data entry reporting app. So something you can do is to create a subsite. Look all access to modify pages except to owners. Create all your screens by adding pages to the subsite and dropping webparts on it with the logic you require for each screen.
Also make sure you deploy the werbparts via a web feature that only is activated in your subsite, this way the webparts are only available in that particular subsite.
I'm taking over a SharePoint portal and noticed the previous developer used SharePoint Designer for all of the development whereas I use Visual Studio custom solutions/features for development.
NOTE: Site Publishing Features are enabled on a Team Site template for some web applications.
The issue I've noticed is the v4.master content type was changed from "Master Page" content type to "Page Layout" content type. This must have been done through the "Edit Properties" on the publishing site. When opening the site in SP Designer, the v4.master shows up in Page Layouts instead of Master Pages.
The v4.master also has the blue icon next to it meaning the page is customized and content is stored in the database which is causing performance issues. SharePoint is so slow that users are very frustrated. Also there are script tags in the masterpage pointing to jquery in the top level scripts directory. Personally, I would of created a delegate control for this instead of customizing the v4.master. NO Copy was made. (I totally dislike SP Designer, this tool gives too much power to inexperienced power users that like to put sharepoint developer on their resumes. I am definitely disabling SP Designer)
So, with all that said, what are the best practices or suggestions if any in fixing this issue?
What issues will this cause for future applications or site collections?
Should I develop and deploy a custom master as a feature then "Reset to Site Definition" on the v4.master?
Why does SharePoint allow users to change the Content Type on a Master Page to "Page Layout"? Why is this even an option, it doesn't even make sense?
All you need to do within the SharePoint Designer is publish the master page in the page layouts folder and approve it in the Master pages and page layouts in site settings. The master page will appear in the master pages section in SharePoint designer.
Apologies if this has been answered, but I could not find a similar question:
I am developing a webpart for MOSS 2007. I am using WSPBuilder to built a visual webpart (ascx) and everything works fine, but the development/debug cycle is just painfully slow, so I'd like to know if it is possible (without being too painful) to develop the user control faster using an .Net Web Application project with all of the nice F5 debugging, then import the final product into my SharePoint visual webpart.
The user control interacts with a LOB system (SQL) and does not reference the SharePoint API at all. (The reason I am building this as a webpart is because I don't need another web app to run this one page, so putting it into a webpart on a new webpart page on my existing site is the best solution IMO.) I would obviously need to import (reference?) my data access classes into my "temp" web app, but think that would not be too much trouble.
I realize this will be extra effort to get this set up, but am thinking the payoff will be reduced development time of the actual user control using a little web application vs having to use the compile/build WSP/deploy WSP/reset ISS/test/make a change/repeat cycle that MOSS requires. (I guess SP2010/VS2010 has spoiled me with the native SharePoint tools available.)
Update:
I have successfully built a simple web app with one page and loaded up my UC on the page. (I had to comment out all of the Sharepoint Import and register statements that WSP Builder added to the UC for me when I created the webpart.) I added references to my utility classes (which I left in the obj\Debug folder in the original SharePoint project). It took me a while tinkering with everything to get it to work, but the steps ended up being pretty simple and I think I can replicate the steps quickly for future projects. Once it was set up, I was able to rapidly design the UC and build in the UC functionality using the typical F5 debug cycle. Unless someone can show me why this is not a good idea, I plan to repeat this for future projects! Thanks to everyone for thier input.
.
Update 2
Well, I am not sure what I did but moving the UC back into SharePoint proved to be troublesome. The first time I did it, I spent several hours getting it to work in SharePoint, making me question whether it was worth it. However, I am stubborn and tried it again. This time, I only copied and pasted the markup below the "header section" (the part with all of the <%# . . . %> statements) in the ascx file and everything went perfectly. I think I must have changed something inadvertantly the first time. I think I will continue this pattern as it is so much faster to build and test the UC in an ASP.NET web app. (Again, this only works if you are not referencing the Sharepoint API anywhere in the UC.)
The answer here is the SmartPart. It is perfect for just the scenario you are describing. Very easy to create a Usercontrol using "vanilla" ASP.NET and have it work as a webpart in SharePoint. I've outlined the steps to migrate from ASP.NET webpage to statically bound SmartPart on my blog.
What you intend to achieve is surely a nice idea.
Just remember to strong name your user control, drop it in your Server's GAC, update SafeControls section of your SharePoint 80's web.config.
All these setps are one off, after each successive builds (of your web control), you have to just deploy the control (used forcede deploy) in GAC and reset IIS.
You can add this control to toolbox in VS by selecting 'Choose Items' and selecting ther assembly you just deployed.
In addition you can create a test ASP.NET page to test the functionality of your control.
I have a requirement to select some data from a table in a database (SQL Server) and display it on a page in a SharePoint site (MOSS 2007).
I have a little bit of experience of MOSS, so I know I have a couple of options:
BDC
SSRS
or possibily even a custom ASPX page.
I've never really worked with any of these. Can anyone advise on the +/-'s of each?
It all depends on what functionality is required once the table is displayed in SharePoint. Do you need extra bells and whistles or is a dump of the data adequate? (Think about the future as well.) Here's some thoughts...
Business Data Catalog (BDC)
If you want to nicely integrate the SharePoint look and feel with your data as well as get some cool functionality, BDC is a good solution. There is no need to program anything and these are the features you get. However if this data will only be used once in one way then it is probably overkill.
You would need to roll your own XML description of the data so SharePoint knows how to pull it from the database (or use something third party like Lightning Tools). As Colin mentioned it requires the Enterprise license of MOSS.
SQL Server Reporting Services (SSRS)
If Reporting Services is already available for use then this is the quickest and simplest solution. It works well but can get painful as more advanced features are required in your reports.
You should be able to use the Report Designer wizard to point to your table and set everything up for you. There are SSRS web parts that can be used within SharePoint, or indeed you can run SSRS inside SharePoint using SharePoint integration mode.
Application Page
This method Steven mentioned lets you integrate an ASP.NET application into SharePoint (such that it can be accessible by a URL within your SharePoint site). This allows anything that ASP.NET does, and the code-behind will be aware of SharePoint so you can tap into that if needed as well. The cons here are code access security and deployment.
See this webcast for how to do it.
Web Part
Similar to developing an application page but much more integrated with SharePoint. A custom web part is very powerful and allows you to integrate ASP.NET code on a SharePoint page. As you would know web parts can be dragged to whatever location and give a consistent properties pane. Again, code access security and deployment needs to be considered.
If you like designer view in Visual Studio then be aware this isn't the approach that Microsoft push. You can however use something like SmartPart where you would develop your custom app as a user control and the SmartPart wraps it into a web part. I'm used to doing it the MS way now and actually prefer the additional control this gives, however it can take more time.
Page Viewer Web Part
If you don't want to touch your SharePoint installation at all then have a look at this web part. It takes a URL as parameter and displays an IFrame containing the page that would be your report, either in SSRS or standard ASP.NET.
The downside from this lack of integration is problems with sizing the IFrame, and possible security warnings from the browser if accessing the URL in a different domain.
Don't forget the DataView Webpart. It has a pretty small developement footprint and works really well as a first "cut" if you are unsure as to how hardcore you need the final result to be.
It renders using XSLT, giving you full control of the final HTML, so it can do some pretty things with Javascript and co.
For a very simple example of charting.
Have you ever used the .NET Framework do develop webpages?
MOSS 2007 uses this framework for master / template files.
So your best choice would be to create an ASPX template file to display the results on the webpage.
BDC is the way to go if you want to keep it "strictly Sharepoint". The problem is, it is only included in the Enterprise edition of SharePoint. If you have the Standard edition, you could go for SSRS and the SSRS webpart, or, create your own webpart. That way you can use your data display anywhere in your site and it's also ASP.NET compatible.
As Nat said - if all that is needed is to display some data from a database on a page - the DVWP is a great solution. Just open your page in SharePoint Designer, add the database connection, and drop the web part on your page. You can use any of the several pre-formatted layouts, or design/tweak your own so the data is displayed as you need.
Relatively straightforward, lots of HowTos online, and far faster/easier to setup than something like BDC.