Uninspired

A little over a week ago I had 6 full posts I wanted to write, and was going to kick this blog back into high gear.

So why did I lose my inspiration?

A full week of literally babysitting the SharePoint environment, testing it every few hours, rebooting services and servers when they went down, just trying to keep it afloat.  Tens of hours researching errors and problems, to find that we are not alone in our tribulations, but nobody else has answers either. Being told that other organizations had to rebuild their server farm from scratch to resolve these kinds of issues. Starting to do so ourselves just in time, as our initial farm dying a tortured death. Piecing things back together, getting 90% of the functions in place, but beating our heads against the last 10%. Hiring some of the top consultants in town only to have them shrug their shoulders at our problems.

It is hard to be unbiased about a technology when you spend your Christmas just trying to keep it alive. I wasn’t alone in this… one other member of my team has put in just as much effort and made sacrifices as well.  Perhaps even more than I.

So I have lost a lot of inspiration to write this blog.

It still is my job to do this mirgration, though. So I will still write. But I have nothing unbiased to say right now.

View Navigation

I’ve been quite disappointed in SharePoint’s mechanism for switching between views. A barely visible drop-down? Even if over time, SharePoint users might get used to that, our Notes Community won’t accept it. Not when they are used to hierarchical navigators that display categorized views.
So as an alternative, I went into one of my lists, and added a content editor web part to each page, and simply wrote up an HTML list navigator more along the line of what the users have come to expect. I’ll see what the users think, but if they like it, I’ll continue it.

My way of doing it actually was pretty bad - it would be better to store the HTML somewhere either in SharePoint or on the file system, and call it via a different web part.  But I’ll figure out the best mechanism later - this first step is just seeing what kind of navigation works for the end users.

Hierachical Document Structures?

I want to throw a question out to everyone else who has worked in both Domino and SharePoint:

In a number of our Domino apps, we will have a main document, for example a project description, with child documents, using different forms, for example, tasks, deliverables, meeting agendas, etc. Each of those forms may, in turn, have their own child documents.

The final result is one parent document, with the ability to drill down in a view to see all the available child documents at multiple levels of a hierarchy.

So the question — How does one achieve this same type of UI in SharePoint? Is there any way to do it that isn’t either spaghetti code or a maintenance nightmare?

More Details on Hide-Whens

I wanted to go over a bit more detail about ‘hide-whens’ in SharePoint:

As I stated in the previous post, you can use a Custom List Web Part to pull your list item UI into XSL, giving you control of the UI, which in turn lets you hide elements using xsl:if.

To begin, we need to add the Custom List Part:

1. Open your SharePoint site in SharePoint designer, and navigate to your list. (Note: If using single sign-on like we do, you may need to open the site in a browser first to cache your credentials.)
2. Navigate into ‘Lists’, and then into the list you want to modify.
3. Open ‘DispForm.aspx’ - This is the form that SharePoint uses when displaying a new list item. (EditForm.aspx is for editing existing items, and NewForm.aspx is for creating new items. This works on any of these pages.)
4. Right-click the default List Form Web Part, and select ‘Web Part Properties’. Open the ‘Layout’ settings and select ‘Hidden’. I’ve read that hiding the form works better than deleting, but I haven’t testing this out to determine why. *shrug*
5. In Code view, place your cursor in front on ‘</ZoneTemplate>’ and then select from the menus ‘Insert..’ –> ‘SharePoint Controls’ –> ‘Custom List Form’
6. You will be prompted for which List to show, and whether you want to use this web part for creating new items, displaying, or editing items. In general, if you make these selections match the page you are working on, all will be well. Someday, I may experiment with pulling in different list data, but I haven’t done that yet.

At this point, you should see the specific fields for your list in your designer client. If you look at Design view, it looks like the default SharePoint form. Code view will show the XSL that creates the form. Now we can edit that XSL and modify our UI.

 By default, SharePoint will display each field in a table row containing the field name in the left hand column, and the field value in the right hand column. You probably will see many iterations of code that look like this:

<tr>
<td width=”190px” valign=”top” class=”ms-formlabel”>
<H3 class=”ms-standardheader”>
<nobr>Field Name</nobr>
</H3>
</td>
<td width=”400px” valign=”top” class=”ms-formbody”>
<xsl:value-of select=”@Field_x0020_Name”/>
</td>
</tr>

Looks a lot like HTML, doesn’t it? The XSLT tags surround all this HTML, so even through there is only one xsl tag in the above code, it all is programmable via XSLT if you choose to do so.

(Also, note the field name - it converts your column name by adding a @ at the beginning, and converting spaces to ‘_x0020_’. That gets easier to type after you do it a few hundred times. I thought about not using spaces in my column names, but while that would make the code cleaner, it would make the standard SharePoint UI less user-friendly, so I just deal with it.)

Now, to hide something…

In general, to hide, you will use ‘<xsl:if test=’YourCriteriaHere’>’

So, to only show the value of “Assigned To” if “Is Approved” is set to ‘Yes’, you would write the following code:

<xsl:if test=”@Is_x0020_Approved=’Yes’”><xsl:value-of select=”@Assigned_x0020_To”/></xsl:if>

Voila! Hide-whens in SharePoint.

Naturally, you will want to do something more complex than that - if you choose to hide a field value, you probably also want to hide the full table row containing that field value. I also have used this to write custom text to the browser based on a combination of field values. Use your imagination. And Have Fun.

Hide-whens in SharePoint!

I had mentioned quite some time ago that one feature SharePoint just didn’t have was hide-when formulas.

Let me state here and now that I was mistaken.

Just this morning, I figured out how to do hide-whens in SharePoint. I don’t have the full range of options provided by the @Functions in Notes, but I can hide form UI based on data within that form.

I will try to expand on this later (I’ve already got 3 topics lined up to post about… just need to find the time), but in brief:

1. Edit your list pages in SharePoint Designer (NewForm.aspx, etc)
2. Hide the default list web part on that form. (Apparently it must be hidden, not deleted… i haven’t tested to see why that is.)
3. Add a Custom List Web Part to the form
4. Modify the XSL in that new web part.

That’s it. Now that you are working in XSL, you can use xsl:if to write logic to choose exactly what UI components should / should not display.

This technique won’t give you the full capabilities of Domino’s hide-whens, as it limits your logic to the list data… but that is better than nothing, and still fairly powerful. I intend to do more research to see if I can pull in more environment/session/user data to expand the capabilities of this concept.

And I suppose this also means I need to become much stronger with XSLT. I’ve suspected for years that XSLT is a skill I need to pick up. This forces the issue.

Admin Vs. Dev

A few months back, I had stated that setting up a basic SharePoint environment really isn’t all that painful. And that is still true.

However –  what I have found is that only basic dev or proof-of-concept environments actually stay that basic. We have about 2 dozen servers in our environment, for example.

And we have spent the VAST majority of our time on administration issues, not on development efforts. In theory, everything will be wonderful once we get everything stabilized. But getting there is taking more effort than anticipated.  Every time we work on one issue, we find three more. The theory sounds much better than the practice.

I think that SP will still come through for us. But the process to go from nothing to a full-blown stable multi-server SharePoint install that actually benefits a business organization… Whew.  It is a doozy.
There was always a half-true joke in the consulting world that to accurately scope out a project, you take the estimate from the technical team and double it. For SharePoint, I’d double it again. If you are hiring consultants to do it, double it once more for good measure.