A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Ive worked with SharePoint for a significant time now and am aware of what it is capable of.
Essentially I am writing an application that, at the data layer, looks extremely similar to Sharepoint's database schema. I mean, the way it is extensible and scalable, the type of data it stores etc etc.
The question I'm throwing out there, is, has anybody put their own interface on Sharepoints data and used the web services API to read/modify it. It seems in my instance that is doable and would save a lot of work.
Do you think its a viable plan
I have an application that uses Sharepoint document libraries as a store. I use the Sharepoint object model, not the webservice, and a collection of connected webparts for the GUI.
You might want to think twice before going into too much template customization. Sharepoint is one of those apps that feels like semi-consultingware in that respect. Great functionality for the enduser, but there are some horrors under the covers.
Another gotcha for the end user is the administration. It is more like a maze game of hunt-the-wumpus to find anything in that interface, and every click is a "let's hope this works because I haven't got the faintest idea of what this does".
Just me (Sir to you)
Monday, February 21, 2005
Yes absolutely, I've written and presented admin training for Sharepoint on occasion, the point and hope thing is exactly right.
Anyway, the solution Im aiming for doesn't quite fit into WSS's model, however I wil definitely be using some hints from its DB structure
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz