I'm creating a Site Definition for SharePoint 2010 using VS 2010. Have some questions:
How do I limit the page layouts to the custom ones that I created?
I created a custom Home Page layout. How do I by default create a page based on this page layout and set it as the welcome page for the site?
Your implementation approach (either declarative or programmatic) isn't indicated in your question so I am only assuming that you are building your custom site definition declaratively (with CAML). You will find that creating a custom site definition declaratively is pretty painful, especially when debugging. It usually involves making changes to the onet.xml file and just hoping things go right during deployment and/or site creation.
When developing custom site definitions, I find it easier to forgo the declarative mess and staple a custom feature to my custom site definition, allowing me to build the site up with code. Andrew Connell has a blog post to this effect:
http://www.andrewconnell.com/blog/archive/2008/02/15/You-dont-need-to-create-site-definitions.aspx
(Disclaimer: yeah, it's old, but still quite relevant, in my opinion)
Now that your tasks are programmatic (allowing you to debug, log errors, and generally have more visibility into the SharePoint magic) you can initialize your new SPWeb object as you see fit via the SharePoint object model.
Setting the available page layouts.
Setting your custom page as the homepage (after you add it to the Pages library).
Perhaps someone else can enumerate 100% declarative approach; I'm sure it's ugly, as is most CAML.
Related
I am aware of a program called "SharePoint Designer 20xx), and I would like to know if any of you have modified the default master page to make it.. less confusing and more simplistic. Can this be however I want it or is there limitations?
I also found this:
http://www.expertsharepointconsulting.com/images/Blue%20Large.PNG
I would like to implement a design similar to this! If I were to download a "Free sharepoint master page", would this design only work for the main page of SharePoint? as in if I were to go from the newly added masterpage, to a page called "reports", would it be completely different? If so how can I get around this?
You can create customized masterpages whichever way you want. Usually you don't touch the default ones, specially because you can break some system pages with that. Just create new ones from them or from the minimum.master one.
As an example of a Sharepoint Website using a very customized master page I can point you to a publishing website project I was involved for a Portuguese company: http://www.ana.pt/en-US/Pages/Homepage.aspx
It's all Sharepoint 2010...and it is fully customized
You can of course use the same template for all pages, just have to set it on the root site and say that all sub sites inherit from it.
To achieve the level of design changes you see on that web site you have to build new master pages, page layouts, use JS, CSS and user controls (the website uses little to no web parts).
we don't use Sharepoint designer because that would mean the files becoming unghosted, which can be pain sometimes, and sharepoint designer is not a very good tool.
The way we do it is by implementing everything on visual studio and deploying it via WSP packages. This way everything stays ghosted on the file system. You can check an example here:
http://mihirsharepoint.wordpress.com/2012/11/23/creating-custom-master-page-in-visual-studio-and-deploy-it-to-the-sharepoint-site/
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 have a sharepoint list with several views. I can modify the view pages (such as AllItems.aspx) via the sharepoint designer. However I would prefer to modify the underlying template instead.
Now I could directly modify the default view page template located in templates\pages\viewpage.aspx but this would affect the whole sharepoint installation.
I would rather make a copy of this template and make my list (or views) point to it. Is there a way I can accomplish this?
Note: The list/views were created via the Web UI without any custom XML.
Check out this blog:
http://weblogs.asp.net/soever/archive/2006/11/11/SharePoint-Solution-Generator-2D00-part-1_3A00_-create-a-site-definition-from-an-existing-site.aspx
Basically, use the sharepoint solution generator to create a VS solution of your SharePoint list. The solution will contain a file called schema.xml that defines the list and associated views. You can then customize the aspx pages like viewlist.aspx and point the schema at your custom pages. When you deploy the solution/feature it will deploy your custom pages with it.
There's really a wealth of info out on the internets, it's just difficult to find when you don't know what you're looking for. But this should get you started in the right direction.
Also, in my experience, once you create the solution you should port it (read: copy teh contents) into an STSDEV project. STSDEV really shows you what's happening behind the scenes, whereas the other VS tools for SP development can do some hand-waving magic which will leave you in the dark when things go wrong. Just my 2 cents.
I am new to SharePoint development. We have created a base site template and have used that template to start new sites in other locations on the same server. This works fine but the newly created site seems to "flatten" the custom content types created in the original site. I would think there would be a way to keep the original content type inheritance intact to help support any necessary modifications on the new site. They can still make the modifications but they take longer because you have to visit each list individually. Does anyone know how to fix this or know a better way to approach this?
The problem you are having is the move from your original site collection to another. The site template does not store the complete definition of a site - only the differences from the underlying site definition. Move from one site collection to another and you lose the underlying site definition and run into problems such as the loss of your content types.
Site templates and site definitions are two separate customizations you can undertake. You need to make a decision based on your requirements as to which is best.
Site templates
Pro's:
Easy to create and reuse through the SharePoint interface
Ideal for end users
A site template is a customization of the underlying default site definition
Con's:
Dependency on underlying site definition means SharePoint updates could break your site templates
Poor performance since the modifications are held in the database and are read from the DB and compiled on each request
Limited customization options
Site definitions
Pro's:
Harder to create: involves coding XML
Made by developers and site administrators
Independent of SharePoint default site definitions so not affected by SharePoint updates
Limitless customization options
Con's:
Difficult to modify when deployed
Can be cached on the file system so is fast to load
Check out Google for info on creating custom site definitions.
Hope this helps!
Jonny
The best way to do this is to create a site definition where the content types are within features whose scope is to the farm.
Tim
When creating web parts for Sharepoint, is it better to create an actual web part, or is using and ASP.NET User Control (.ascx) just as good?
I already know how to create the user controls that I need, so it seems like the extra effort of creating a web part is just unnecessary leg work.
What are the advantages of using a web part over just creating and ASP.NET user control?
I am a big fan of user controls except for the simplest web parts. I create a webpart that instantiates and loads the user control. There are other tools out there that you can use to expose your user control, like smartpart, but I would suggest you wrap it up yourself, as it is a good learning experience. Once you have done it once, you basically have a template for any other webpart you want to create.
Good Luck!
A bare ASP.NET ascx control would have to be added to a custom layout page. This limits the utility of the control a little as it cannot be added "just anywhere".
Having a webpart gives the flexibility of the control being added to the site multiple times in different locations or even multiple times on the same page with different properties.
As has been mentioned it is good to use CreateChildControls() to create the controls in the webpart and it is not that much of a big deal to code and package a webpart into a solution, making it worth the extra effort.
Webparts are also able to accept connections from "filter" webparts on the same page, giving additional flexibility to webparts compared to hosting ascx controls on the site.
When it comes to editors using the site, it makes a lot of difference for them to be able to add a webpart compared to editing a page layout, publishing it and then creating pages based on that page layout, so from the perspective of a site editor, the difference in usability is really quite large.
I recommend going even further and coding your webpart to use an xslt file to display the contents and making the location of that xslt a configurable property of the webpart. This really adds to the flexibility of your control.
Look at the Dataview webpart to see how much can be done with the addition of custom rendering.