Share Point Integration Enhancement

Summary

FlexWiki would be great if it were integrated more with SharePoint. People who are used to using SharePoint would be faster to start using wiki if it were (better) integrates

This is an idea of JasonDossett's and MattWright's.

Basically the idea is to provide deep integration between FlexWiki 's wiki engine and SharePoint.

This might include:

Changing the backend to use SharePoint lists instead of flat files

Interesting idea! How would perf be? Could be implemented as a kind of AbstractContentBase -- DavidOrnstein

Modifying the web app front end to look and feel like SharePoint and live in the SharePoint layouts directory

Should this be a built in type (by modifying the xml template files in the _layouts directory) or a template file? Using a template file allows more people to use it since sharepoint users don't always have access to the layouts directory

Create a custom content template like Document Library or List so that Wiki's could be added to a site as a first class citizen

Create a Special WebPart for Displaying Documents in a Wiki Document Library.
What would happen if I clicked on a link? Open in a new page? Use IFrame and open in the WebPart? or act as a link?

Adding custom tags specific to SharePoint to allow things like inline discussions, links to SharePoint contentm etc.
I was also thinking that maybe this should be a Site Template. It would show up in the Site Template list alongside: Team, Empty, MeetingWorkplace, etc.

Provides for a entire site template to be provided, allowing for a more "wiki"ish presentation.

More Random OneNote, SharePoint, Wiki Thoughts - http://www.greghughes.net/rant/CommentView,guid,c6591f8f-d9e8-4478-89ac-5a71334f54bd.aspx

Comment

We're using FlexWiki heavily within Sharepoint 01, and it's fantastic. It's the center of the window, and basically the center of our universe.

I did move everything to the right border. Only request I have for now is that in Edit mode, the right pane (Save/Login) take up as little space as possible - on long page names, it can grab over half the real estate of a web part. Even if it means breaking up page names... they're non-clickable anyway. Otherwise, BRAVO!! ChristopherGaltenberg

Comment

I use FlexWiki heavily at home, and Sharepoint heavily at work. Wiki is mostly about collaborative editing of a single document database. Sharepoint is mostly about storing artifacts. For example, if I have a PDF file that was faxed to me (like a contract), I can put it in sharepoint with a single click. Anyone else working on that customer is advised I've put the contract in the workspace, and can review it if they need to. In FlexWiki, I have to put the file on a network-accessible location, maybe using a file share or WebDAV. Then I have to make an external link to that file. Then anyone can change the link to point at a different file, potentially in a different location. Thats why businesses like sharepoint -- it fits into business processes, which are all about artifacts. Also, it is currently difficult to link from external systems to FlexWiki, because it uses topic names and not opaque ID's. An opaque ID is better, because you can link to different language sites.

WikiVsSharepoint

	Show Changes
	Print
	Recent Changes
	Subscriptions
	Lost and Found
	Find References
	Rename
	Administration Page