I know next to nothing about SharePoint, so maybe this isn't something you can/should do, or maybe it's something completely trivial, I don't know, but we have a custom in-house help desk application at work, and I'm wondering if it can be integrated into our help desk SharePoint site somehow?
I really don't know what's possible with SharePoint, so any ideas or thoughts on this matter would be appreciated.
The short answer is yes but the amount of time required to make this work will be directly related to your flexibility / needs. Would you be satisfied with default SharePoint lists / forms? Do you need to retrieve and update data hosted in an external source? Do you really need this integrated with SharePoint or simply hosted under the same URL?
I've found that SharePoint can do anything but the time required to make it meet the needs of a demanding/inflexible business user is sometimes significant.
There is also the issue of doing right or simply making it work. Making it work buys you some time initially but you can easily dig yourself a very deep hole that is difficult to escape. My suggestion is to keep the solution as simple and maintainable as possible.
Pretty much anything that can go on a webform can go in a webpart - with obvious complications, but yes it would work. Look into webpart development.
I would try to stick to the features that SharePoint is already offering you. You can achieve a lot by using them, and enriching them with a few simple workflows.
If you want to add some workflow logic to your solution, then try to avoid the designer workflows, since they have some issues when it comes to deployment(in short: you cant). So even if it looks easier to design them in Designer, you will pay a price later when you want to deploy them to production (You have a staging/development enviroment?)
In general I would also agree with mayos answer
Anything is possible...but check out the MSDN reference for integrating with SharePoint:
Integration with Office SharePoint Server
Related
Ok, I always ask this question to myself.
When it comes to SharePoint OOTB features VS C# custom development, where exactly do you draw the line?
Just post your thoughts... (even if you think this question is ridiculous :-P)
I can't recall one single project where SP "OOTB"...
Fulfilled the client requirements entirely (except for the most trivial cases). In the case of changing requirements this often led to over-complicated hacks or eventual re-write as some "custom development".
SharePoint Designer didn't make the problem harder and less maintainable. Worst. Product. Ever.
Edit: Actually, now that I am "forcing" myself to remember it, I think it all devolved to some hack or issue avoidance to get around some limitation or another. The difference is where the hack is encountered and how easy it is to perform said counter-measure(s).
Not sure how you're going to get anything like a specific answer to this, shouldn't it be decided on a case by case basis?
Surely its just "If the cost of the custom development is less than the cost of 'living with it as is" then develop, or not?
In SharePoint there are many customizations that can be done without having to develop (if you are referring to 'custom development' as C# code.
Several thing can be done using Sharepoint Designer, and I wouldn't know if those are to be considered custom development.....
I have created websites out of VS, changing basic stuff with Designer, and I've created workflows with WSS as the UI... so it also depend on what you want to accomplish...
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.
What would make development with SharePoint easier?
A better product.
Right now it is to many things that doesn't behave as a development environment should.
Dispose of objects
Performance of traversing small lists with 3000/4000 items
Lack of support of transactions
Hopefully next version will have the SQLServer based lists where you can have transactional support and better performance......
Bill G raised the question in feb 2008 that it is something strange with Sharepoint that you get problems when you have 3000 items in a list and SQL Server easily supports million of items....
The build and deployment process needs to be simplified. There are numerous tools available to create WSP files, but they are all decent at one thing another, but you ultimately need to extend or rework the solution WSP deployment package for you environment.
Standard HTML and better support for the DOM.
Informative error messages.
While easier debugging and less XML are very tempting (as people suggested), I would settle for something much more modest.
SharePoint usually "swallows" exceptions or other error messages. Very often when a customized page or a web part fails, you get an obscure 'page cannot be displayed' message. With luck, the designer will direct you to the problem, or you might find some details on the logs or the system event viewer. But in many cases you have nothing.
Examples - Business data catalog xml monstrosity that worked on the editor but not on the site, xml web parts that fail randomly, xsl typos or mistakes, etc. All take much longer to find than they should, and some are impossible to debug.
Remote Deployment:
- 1 central Sharepoint, and transparent remote debugging.
Less XML (schema.xml etc).
Making the dev process more like "traditional" asp.net development, in other words making the integration with VS better. You should develop against SharePoint from within VS not from within SharePoint (ie SPD).
SPVisualDev on codeplex has made that process better but I hope (an I say hope) for better support within VS2010 together with SP2010.
Should check out #SPDevWiki's page on this also http://www.sharepointdevwiki.com/pages/viewpage.action?pageId=7340352
Less people trying to abuse the product would make things a lot easier too ;)
I am working on a project that is replacing an old portal system (Plumtree) with sharepoint and we want to make the transition as smooth as possible.
One thing we are look at currently is taking all the gadgets (Plumtree term for WebParts) and making sure they appear in the same place on the users new MySite.
Plumtree holds this information in a simple table containing the user, page, gadget and position information. I want to find a way to automate reading this table and putting the new WebParts on the users MySite and not have to manually set it up for hundreds of users.
I'm told modifying Sharepoint tables in SQL Server directly is not a good option as it may affect our support arrangements, but if it saves doing this by hand then I would concider it.
Other options that spring to mind are creating a equivalent table and using API calls to load the WebParts the first time the user accesses their MySite.
Any better suggestions?
You are right, messing directly with databases are not supported nor recommended.
Unfortunately, there are not much ways to modify MySites, the best way I know come from the MOSS Team Blog: http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-the-enterprise.aspx
The way we did it was pretty much what is described in the link above (http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-the-enterprise.aspx).
Your best bet is probably to staple a Feature to MySite creation and have it poll the plumtree database, find the gadgets for that user, and add a 'Page Viewer' web part for each, pointing to the gadget's location. That said, you may want to reconsider blindly migrating all your plumtree gadgets into SharePoint. There may be much better 'SharePointy' ways to provide the functionality that your gadgets are currently providing.
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!