What is the best practice for developing sharepoint applications?
Since last year we had to work with multiple SP applications. All of them were running on external farms with SP2010, so we can only use sandbox solutions.
At the beginning we had to change some implementations of list interactions from C# to JS. All actions of these dynamic masks were terribly slow because of the full postbacks and rerendering of the whole mask after user interaction.
- This sounds silly. Why we must retrieve the data via webservice and render content via JS instead of using the DB "near" SP to do this job?
- There is Nintex Forms/Workflow installed. But all these "clicky" stuff has a reliability problem. Who has changed what when and why in detail?
In normal applications all updates are first saved in a CVS
- Whats about portability?
How we get the actual "is" of an application from one SP (test) to another (prod) or vice versa. On "going live" of a new version we need the first, on bug comprehension the second. The data on prod must never be lost. When working with multiple developers - how we can merge the work of each?
- When using VisualStudio, what is about SoC? Why we have to create/layout/fill controls via C# CreateChildControls instead of using templates/views?
- VS support possibility seems to be realy poor? With SPSF we can "easily" (this plugin often crashed with huge stack traces when opening files. Only disabling and reenabling solves the problem) define types. But thats all? How we can do something with this information? In a normal application we would create a central model which can be used everywhere - with SP we only have the stringy stuff and no IDE help at all?
- Most of the applications are "living": they change monthly, get and looses contenttypes, colums, lists. Must each change be an additional feature which relies on the existing and must additional be activated? The feature list will be realy big after short time
So much questions