Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Object Model Changes

  Asked By: Leroy    Date: Dec 20    Category: Sharepoint    Views: 912

One, the inconsistency of terminology between the object model and WSS/SPS administration/design is disappointing/confusing... This is a big stumbling block on the learning curve to understanding WSS/SPS. Two, the lack of documentation and detail in some of the existing docs is a BIG development slow-down. Having to write programs to discover what a property/method does even when it is "documented" sucks up valuable time. How can I devise a credible project timeline when I don't even know if or how a task can be accomplished. Existing documentation consists of extremely terse object model online docs and "white papers" on how to accomplish specific tasks. Some subsystems are essentially undocumented. (Can someone say 'Search'? Try building a query from scratch. Some doc says it's "sort of like" SPS 2001. "Sort of" does not cut it in my shop.) There is no detailed documentation on the life cycle of a request through SPS. What is the flow of exceptions and errors? How do I trap ALL errors? On and on...

Real Life Rule: If you are going to advertise a system as having a rich development environment, make sure that the rich environment is available outside the walls of the vendors development team building. Otherwise, you may find your customers get a bit hot under the collar. Read below, "The Ultimate Horror Experience for a Developer".

Remember: The product announcements giveth and the release notes taketh away.

Sure, you can try the Anakrino (pardon spelling) reverse-engineering route to figure out what the documentation does not provide. I learned long ago to avoid solutions that depend on undocumented "features". Those have a habit of disappearing at the next upgrade.

Real Objects -- Not simple object wrappers around single purpose subroutines. The supplied webpart objects should be replaced en masse. For example, SearchBox and SearchResults objects just return fixed HTML. There is no way to significantly influence the HTML it generates. You can only employ "screen scraping" techniques to modify the HTML it builds. These webparts depend on the presence of certain HTML hidden fields to function properly. Without being told explicitly which hidden fields are needed, it is hard to make major changes to web pages and still use these webparts. (Back to documentation...) The SearchResults webpart object does let you intercept the returned dataset. It contains events which let you know when a column is to be rendered. Dataset column? Nooo, the column in the HTML table it is rendering. (listen to sound of head banging on the wall.)

The SPWeb object is about the most complete object in the suite. An exercise, try moving up the web hierarchy to the top-most virtual server object.

Consistency - Finding out how to add additional objects to a collection object is a journey in itself. One, the process is not consistent or documented in the paragraph describing the specific collection. Some collections have you create a new object and use an Add method. Some require you to call an special method in a different object. Some require a call to an Update method, some don't and some require something else. Reminds me of control programming in VB6.



No Answers Found. Be the First, To Post Answer.

Didn't find what you were looking for? Find more on Object Model Changes Or get search suggestion and latest updates.