I curious of what you’re experiences are one the user of site definition compared to feature stapling. In a video on Channel 9 Ted Patterson explains that feature stapling is the way to go. It would be nice to know of some experiences other SharePoint experts have.
Are you all using Feature stapling or are there areas where Site Definitions is a better choice?
For me it purely scenario dependent Feature stapling is good if we have to work on some existing site definition like third party or OOTB. but if its a custom solution or my own custom product based on SharePoint i would still like to go with site definitions
Ideally, we should avoid using Site Definitions and use Features for all the custom development/provisioning/customizations cause they are much more flexible & extensible.
I have worked for Microsoft on many sharepoint projects including the 2007 and 2010 version of the http://www.microsoft.com/sharepoint public iste and almost all the customizations and provisiong was done via Feature Staplers.
If you have lots of customizations, then site definition is the only route to go.
In my experience, it's hard to maintain a complex site definition. The best way to go is create a very minimal site definition than staple the features you need. It also promotes modularity (by using features) and reusability.
Related
For our application, when the site gets installed, it creates a bunch of different fields, lists, content types, etc., etc. There are a lot of dependencies to manage there, and I'm wondering how others go about this, from an OOD perspective.
We use feature stapling to do this kind of work. For more detail information (and reference application) checkout the Microsoft SharePoint Patterns and Practices.
http://www.codeplex.com/spg
We are currently in the process of drawing up a solution for an existing client, creating a number of eServices. The client currently have MOSS 2007. The proposed solution is to use MOSS as the launching pad for the eServices…
The requirement involves drawing up several online forms which provide registration facilities as well as facilitating a workflow of some sort. I have been told that the proposed solution requires complex web forms.
Most are complex forms with parent child details that have multiple windows. The proposed solution is to do some bespoke development, developing ASP .NET forms. These forms would be deployed under the _layouts folder of the current MOSS portal, inheriting the master page design on the current site.
I have been told that this approach make development and deployment more simple, as well has having ‘complete integration’ with MOSS.
My questions are:
Is this the best way to leverage SharePoint – it seems like the proposed solution is not leveraging MOSS at all..! I thought perhaps utilizing Web Parts would be better, but I have been told that this is more complex and developing more smarter intuitive UI is more difficult. Is this really the case? If not, what should be the recommended approach?
We will be utilizing Ultimus as the workflow engine. However, I have been recommended K2 Workflows. Anyone used both/have any opinions on either?
Many thanks in advance!
Kind Regards,
If they have MOSS 2007 Enterprise, you might consider if web rendered InfoPath forms can meet your needs for "complex web forms". When it comes down to it, probably all of these technologies can meet the neeed it is just a matter of what skill sets you and your customer have and how that will facilitate keeping this solution up to date.
Asim, what they propose is a possible solution. They can however provide the same functionality by making use of webparts. With the details you are giving us that isn't really possible to decide which option would be easier. I used both approaches in the same project depending on the requirements of each functionality.
I can understand that it doesn't seem like they are leveraging MOSS, but they actually are building pages within the context of MOSS.
I haven't really heard about Ultimus, I did use K2 in a proof of concept and I was quite happy with it. Then again, choosing the right workflow solution depends on your requirements.
Basically need to use SharePoint (because we promote MS yay!) as a content management system for an internet facing site.
How do I get rid of the default SharePoint look and feel and make it look like however I want it to?
I know the process involves creating a new masterpage with SharePoint Designer. However I prefer to code webpages rather than use a visual editor. Is this possible? Do I need knowledge of .NET?
Just check out ferrari.com for a very well made redesign of a SharePoint site.
Heather Solomon's Branding SharePoint series would be a good place to start. There's a lot you can do just with CSS, JS and HTML, but the most complete solutions (like Ferrari) require some pretty extensive customization with .NET and other SharePoint development techniques (features and delegate controls, in particular).
Your branding effort will be a lot easier if you only need to heavily brand the public-facing "publishing pages", from which you can remove most of the SharePoint-specific elements that make branding difficult.
Also, SharePoint Designer has a source view if you don't like the visual editor.
Yes it is possible to make it look like however you want it to (as you've seen from the Ferrari site). However to create that sort of site takes a lot of work.
Microsoft recommend the use of SharePoint Designer for 'designing' pages and layouts. However changing their behaviour almost always needs Visual Studio and development in .NET. You can largely avoid SharePoint Designer (which may worth considering as it can be a PITA) with an open source tool such as SPVisualDev. Use this with WSPBuilder for packaging your solutions (and avoid VSeWSS where possible).
Considering it sounds like you're just getting started, be aware this is a big topic with a reasonable learning curve. Read a good book on the topic such as Professional SharePoint 2007 Web Content Management Development: Building Publishing Sites with Office SharePoint Server 2007 by Andrew Connell. It takes you through most things you will encounter from the ground up.
I'm working my way through Real World Branding by Andrew Connell at the moment. It seems like a good demonstration, with code.
Plus the Heather Solomon articles as suggested by dahlbyk are always informative.
Just changing the theme, or creating a custom theme for the site, can go a long way towards making SharePoint look a lot better. It's also a lot less intensive then changing the master pages.
How to create a theme
How to deploy a theme
Example customization you can do with just CSS
Does the EULA allow you to disguise the fact that it's MS software?
Remember, you didn't buy the software, you're just paying for the privilege of using it.
I am total beginner in SharePoint and I need some help in starting a project. I have to develop publishing site that will be delivered to the client. I would like to give client deployment experience like he would get when deploying standard ASP.NET application as much as possible. I plan to use Visual Studio 2008 with SharePoint extensions and maybe WSPBuilder or some other tools.
I also need help in structuring whole project.
Here is what I plan to do:
1. Develop minimal site definition
2. Create site from this defionition. How should I do this from code ? Use SharePoint Feature ? How should I activate it ?
3. Develop all the needed infrastructure for the site (master page, layouts, content types, ...) as SharePoint Features.
Is this correct and how should I develop all those parts so I can make a some kind install script so can client create get complete site with one click ?
Site definitions are complex no question about it, but they are very useful if you need to deploy to unrelated enviornments. If you are staying on the same server farm, maybe site definition is overkill. If you are going between domains (i.e. test & prod, then maybe they are worth looking into).
Another advantage to site definitions, esp. if delivering to a client is it feels more like a traditional deliverable. They will have a bunch of files (hopefully in source control) that are their custom site. I think that gives IT dept's a much warmer feeling than an XML file created from the SharePoint UI.
Another benefit of site definitions are you have a lot more control over the pages that make up the site. IMHO its easier to add master pages & custom CSS via site defintion that site template.
I am curious as to what are the 'moving parts' to the site you are trying to deliver? I think that answering that question will determine how to define the project's structure.
Generally, I think you are on the right track. Features and solutions are a must. I would stay away from VSeWSS, its buggy and clunky and generally terrible if you are trying to do anything complex. It tries to be so smart, that it leaves you no control.
That said, it really depends on what you are trying to do. If you are going to build a solution to deploy to the GAC with one assembly, and only building features supported by vsewss you may be fine.
If however, you want to develop, say a timer job wiring that into the VSeWSS feature framework gets tough. Also, if you need multiple assemblies in the solution. YMMV, but I had to junk it and find of a more flexible solution (hello NANT).
A lot of the work you will end up doing is building and checking, and re-checking XML configuration files. Bookmark the Feature Schema reference page on MSDN, you will be spending a lot of time going through it.
Finally, yes, if you have all of the parts packaged as features you should be able to develop a nice install script. Ultimately the script will need to call the STSADM (there are some really nice STSADM extensions here) commands necessary to create the site structure, add & deploy the solution & activate the features. You can start with a batch file, and get as complicated as you want.
Personally I don't find that creating a site definition is really that useful for the sites I have built. They can be very tricky to set up, because of their complex nature.
What I do is use the standard Publishing Site and then using features to add my additional componets (deployed via a SharePoint solution).
You can use Feature Stapling to connect up the feature to the Publishing Site creation.
I've also just done a blog post on how to programmatically modify the workflow which is created by default: http://www.aaron-powell.com/blog/february-2009/programmatically-modifying-sharepoint-workflows.aspx (that also has a link in the comments off to the Feature Stapling concept).
Then I use a combination of SharePoint Solution Installer (http://www.codeplex.com/sharepointinstaller) and batch files to install the components. SSI for all the SharePoint database level installs and batch files for the file system stuff.
Adding another answer, because I have more than 300 characters worth of stuff to say :(
RE: SharePoint solutions generator, again I would say your mileage may vary.
The biggest issue with SharePoint dev is managing all of the "magic strings" across the various configuration files. GUIDs and Fully Qualified Assembly names are the spit and glue that hold the whole thing together, and although it all makes sense its very difficult to manage.
The current crop of tool all try and alleviate the complexity of managing these things, but they require that you work in a certain way, so the tool knows how to inject the appropriate plumbing.
If you plan on doing a lot of work with SharePoint it really behooves you too learn to manage the plumbing yourself. Its painful up front, but really pays dividends.
Basically, I suggest you spend your time learning the platform and not the tools. Once you know the platform, using the tools will be much easier.
If you are doing this as a one-off engagement and just want to get it done, I'm sure you can get any of the tools you've mentioned to do the trick.
I would agree with the use of the out of the box publishing site definition, and then customizing it using Site Collection features (Master Page, Page Layouts, CSS) and site features (create lists, pages, sub sites, defining master pages of sites, etc...).
Feature stapling is great when you want to customize new sites (allow user to create new sites) of well known site templates, like customize the "My Site" look and feel. In this case I don’t think its very useful.
As a tool to help this task, I personally use STSDEV (http://www.codeplex.com/stsdev) to help in creating, programming, debugging and deploying my Sharepoint solutions.
First it creates a good project for Visual Studio (clean, or with some nice "starting point" definitions). Then it includes some “build configurations” that really helps with install, deploy and upgrade in the development machine.
Are there any blogs, guides, checklists, or controls we should be using to ensure our SharePoint implementation is accessible?
Preferrably to the W3C double A standard, or as close to that as we can get.
We're implementing an extranet solution.
This study has already been funded by Microsoft, and unfortunately the results only seem to be online in a Word Document.
The document is hosted on this blog:
http://blog.mastykarz.nl/best-practices-for-developing-accessible-web-sites-in-microsoft-office-sharepoint-server-2007/
And the path to the document is here:
http://go.microsoft.com/fwlink/?LinkId=121877
I'm unsure on whether it would be a good thing to copy the contents of that into here to fully answer the question in a way that will be indexed by search engines, but I'll play safe as it's not my content.
The best place to start is the Accessibility Kit for Sharepoint. With this, you may reach single A standard, but in my experience, you will find it very tough to reach AA.
Microsoft didn't factor in accessibility in Sharepoint, and even 2007 suffers from a huge overdependence on table layout.
Good luck!
How are you deploying the implementation? Is it as an Intranet, or, is it as a public facing website.
I think one of the first rules is to be extremely selective with the use of out of the box web parts. Many of the web-parts I looked at weren't compliant even on a basic level.
Andrew
The best way is to run checks as you develop so you know where your pain points are.
The next step maybe to start with a minimal masterpage so you can choose what elements are presented to the user.
More advanced you can override the render methods to remove or change bits of the page that are not compliant with your checks. EG changing the case of tags (XHTML does not like all caps)
A bit more in this guide.
http://techtalkpt.wordpress.com/2008/06/18/building-accessible-sharepoint-sites-part-1/
http://techtalkpt.wordpress.com/2008/08/07/building-accessible-sharepoint-sites-part-2/
I recently read the MOSS book by Andrew Connell (www.andrewconnell.com) and it has a chapter dedicated to accessibility and SharePoint sites.
Simply put SharePoint sites are very difficult to generate W3C AAA standards, but the Accessibility Kit is one of the best starting points.
Stronly recommend his book for this chapter (http://www.amazon.com/dp/0470224754?tag=andrewconnell-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0470224754&adid=18S6FKQJR5FZK56WHH6A&)
It depends how much of Sharepoint out of the box you are intending to use. In implementing our public facing site we managed to achieve AA compliance, although the amount of custom development required has raised questions over the benefits we are actually gaining from using Sharepoint in the first place.
A few pointers:
We made heavy use of SPQuery/SPSiteDataQuery to render site data to screen using xslt which gave us full control over the output. I found this link helpful:
http://blog.thekid.me.uk/archive/2007/02/25/xml-results-using-spsitedataquery-in-sharepoint.aspx
Check out RadEditor for Sharepoint for a nice accessible rich text editor for publishing.
For xhtml compliance, things were a little more tricky, we had to override most of the Sharepoint publishing controls' render methods to correct dodgy output.
If you are wanting to leverage the portal like capabilites of Sharepoint in your extranet it is more problematic. The web part framework is not accessible and I have not yet found a way to make it so. Any suggestions welcome!