2008-04-16

Web Part Madness

In my earlier post, I commented on how, from what I heard from another developer's rantings, web parts involve developing your own web page. As I'm about to dive into my own web part, I realize I didn't fully grasp what he meant.

It appears that some large things that one would normally take for granted in an ASP.Net web page — in particular, the creation of child controls and the rendering of the page and said controls as HTML — must now be coded manually. Yes, imagine my surprise when I opened up some web part code and saw the CreateChildControls and Render methods and all their code.

What. The. Crap.

It's like SharePoint development takes all the ease and safety of .Net coding and rips it away like a scab that hasn't fully healed, leaving a bloody festering wound in its place. But at least they give you a needle, and if you're lucky, you can go out on the web and find enough thread to sew the wound closed.

Yes, the geezer in me is already telling me to sit down and shut up. I've drawn out web pages by hand before, where the closest thing we had to a "server control" was an include file that wrote an expected structure of HTML code to the response stream. But for heaven's sake, that was over five years ago. We're supposed to be well beyond that. We're even coding with the very tools that take us beyond that, and we're being told that we have to do our jobs with the important tools tied behind our backs.

Maybe this is what Microsoft meant by "do more with less"?

2008-04-10

SharePoint, addendum

Just a quick little addendum on SharePoint. As part of my document library woes from before, I discovered my problem. It seems that there are differences between sites and webs, and in some cases, SharePoint blurs the lines between them, and in others, the lines are very clear. For instance, a Document Library site (or web — see, I'm already confused) that exists under the main site at http://localhost/Docs is not the same site as http://localhost/. Although some features are accessible through the web services located at http://localhost/_vti_bin/*.asmx (such as finding a document by URL), some features are not unless you use the services belonging to the specific site (e.g. http://localhost/Docs/_vti_bin/*.asmx, such as creating a folder).

It doesn't help that, when you add a web reference in Visual Studio to a subsite's services by directly entering http://localhost/Docs/_vti_bin/Dws.asmx, it adds the value to the app.config/web.config file at the root http://localhost/_vti_bin/Dws.asmx level, and if you're not expecting this, you're using the wrong services.

Not that all my problems are solved. Apparently, the web services aren't letting me get information on an empty folder, which sucks, so I dropped that possibility and moved on. (Compared to the object model, the web services are pathetic.)

Recently, I created a custom view for a document list. To create this view, I had to download and install the newest version of FrontPage of all things, called the SharePoint Designer (because Visual Studio refuses connect to a SharePoint web site with an explicit message saying so — more evidence at the lack of support in SharePoint for developer tools). I did this because I needed to remove all the "chrome" from the list view (it's being embedded in an IFrame from a CRM site), and the only way to do that is to customize the .aspx code itself, and the only tool to do that is FrontPage (by whatever name they call it), apparently.

With it all created and working great on my local development machine, all that's left is to migrate it to the servers. I have yet to figure this part out. Although we do have manifests and such set up for web part and event listener deployments, we do not have anything for a custom view template page, and so far Googling has failed to reveal anything that might help.

Again, I iterate how frustrating and ridiculous this all is as a developer. I should not have to waste hours of time trying to find out how to move my work from one server to another. It's possible to point my local copy of SharePoint Designer to the server (with some hosts file editing, since the URLs are only created local to the machines), but this kind of manual copying, essentially duplication of work, is also pretty dang frustrating.

I did come across tools that promise to migrate whole lists, but that's not what I want to do at all. That would overwrite content, which would be bad. I just want to migrate changes, update a view (actually the template for a view), and preferably without installing or pointing a development tool to each server in turn for each change. (And I wasn't able to determine if the solutions I came across would migrate views anyway...)

I'll try to keep these posts updated with any solutions that I find to this and other problems as they come up... >:(

2008-04-04

I'm a developer, and I hate SharePoint

When you develop a regular ol' web site in Visual Studio, you just say "create a new web site". You create your pages and web controls, classes, whatever you find necessary. To debug it, you set your breakpoints anywhere you want and hit F5. Studio these days even launches its own built-in web server, so you don't have to set up IIS. You can even change your code on the fly in some cases. When it comes time to deploy, you grab the code, copy it to the server, point IIS to it, and you're done. (Ok, it's rarely that simple, but it can be. Throw in a few web.config changes or other optional steps like pre-compiling if you wish...)

How easy is it to develop a SharePoint site? First, you have to install SharePoint. While I've never actually done this step, I can't really say that it's hard or easy; however, since IIS comes pre-installed, it's a pretty simple bet that installing anything is more difficult than not having to install anything. Considering how big SharePoint seems once you get it installed, I imagine installing and configuring it can be extremely complicated. Or perhaps it's fairly easy if you just accept all the defaults.

I'm working on a SharePoint project that, so far, we've tried building an event listener, a web part, and code that uses the web services. The event listener works fine, except that to debug, you have to:

  1. manually create the list in the SharePoint site on every developer's instance of SharePoint
  2. register the listener class library in the GAC
  3. use a command-line utility to register the listener with the event
  4. run IISRESET to restart SharePoint
  5. attach the Visual Studio debugger to the SharePoint process

Fortunately, a batch file takes care of the middle steps, and the first step only has to be done once. Still, it's a lot of extra overhead, and it has to be done for every listener that gets created.

The web part has been the responsibility of another developer. Based on his comments, I gather that designing a web part involves practically designing a whole web page. What I remember from them in a previous job, setting them up and deploying them was a royal pain. Modifying them was considered something you just Didn't Do. Their solution was that they had a web part that had, as a parameter, the path to a web control. If you wanted to create a new element on a web page, you created a regular .ascx web control, dropped the "container" web part on the page, and set the path property to the location of the .ascx control. Probably the only easy thing about that job.

The web services are supposed to be easy to use. They have been decidedly not so. My tasks have revolved around trying to interface with the default document library. I can access documents by using the URL http://localhost:ip/Docs/Documents/filename.doc just fine. And yet, if I try to get any information about the document library itself, it tells me the very document library from which it is serving documents doesn't exist. This is most evident when I use the Dws.GetDwsData method on an existing document. It returns a load of information (including a "LastUpdate" parameter which, instead of being a piece of useful information like when the document was last updated, is a key for future calls to see if it was last updated since a given key). One of these pieces of information is a reference to the Document library, which it returns as an error code, "ListNotFound". Because this document library that these documents are stored in doesn't exist, I can't use other methods I need, such as Versions.GetVersions, Dws.CreateFolder, or Lists.GetListItems.

And we haven't even gotten to the point where we try and deploy SharePoint content yet. As I already alluded to before, there's no real way to transfer content pieces from one machine to another in any easy or automated way. A simple list had to be manually created on every developer's machine, and it'll have to be done on Development and Test. In that previous job, they had an established procedure: back up the entire SharePoint database from development, and restore it in the test environment, then QA and then Production in turn. (Which, yes, meant you can't store any development or test information in SharePoint.) While I was there, for the first time, a SharePoint List was used to store data instead of content, and they had to bring in a Microsoft consultant to write a special utility to export the data and re-import it, so it wouldn't get lost in the complete-backup-and-restore deployment procedure they had for years. Because, of course, no procedure currently exists.

Supposedly, SharePoint is what companies want, because it means they can manage content without having to go through development to do it. Case in point, we have a static web site that we're moving into SharePoint for our client, because every change they want to make, they have to call us to make it. The problem is, it's taken our one consultant, the one who's supposed to be experienced in SharePoint, all week to get the existing site into SharePoint, and he still hasn't even gotten the framework in place, let alone the content — something even he agrees would take maybe two days, start to finish, to completely rebuild in a standard ASP.Net site.

Where it seems to make sense to set up a single-environment easy-to-manage web site and collaboration area, it is a nightmare for multi-environment (i.e. Dev, Test, Production) migration and custom development. And yet, it's what the people at this consulting firm keep selling like it's the Holy Grail. I have my own theories as to why this is, but the fact remains, we're stuck with a tool that just refuses to do the job, and tasks that should take half a week are becoming impossible to do in two.