You’re Still in the Right Place

Yup.  Decided to switch themes.  Sort of like trying on a new summer wardrobe. I thought that this theme might be a little easier on the eyes and also give a bit more room for code. Let me know what you think!

UPDATE 2009-07-26 — Turns out the new wardrobe just didn’t feel right, so I’m back to the old theme.  The thing that really decided it was that when I searched, I got the full text of all of the posts back rather then just the titles.   Silly little thing, but I was used to it the way it was.  That, and Francois liked this theme better (see comment below).

The "Right" Way to Join Two Lists In a DVWP

As long as I’ve been working with Data View Web Parts (DVWPs), I’ve pretty much always done my “joins” manually by diving into the XSL.  When I started working with DVWPs, there wasn’t much available to tell me how to do things, so I just made it up based on what worked.

Today I saw this video from Laura Rogers that showed the way you are probably “supposed” to do a “join” in your DVWP.  Take a look.  I may have once followed this route, but it would have been long ago!

A few observations on all of this:

• When you create a Linked Source, what actually happens is that the information about the sources is saved into an XML file in the _catalogs/fpdatasources Document Library in the current site.  What this XML file contains is information about the SharePoint:AggregateDataSource in a udc:DataSource wrapper.   Each time you use the Linked Source, this information is copied in as the SharePoint:AggregateDataSource for your DVWP.  Think of it as a SharePoint:AggregateDataSource template.  If you can make the CAML more efficient, and you expect to reuse the Linked Source, you can do it here.
• Upon initial creation of the DVWP from the Linked Source, there are templates in the DVWP named dvt_1, dvt_1.body, and dvt_1.rowview.  (Depending upon the other options you choose from there, you may end up with more dvt_1.* templates.)
• Note that both Data Sources (in this case; there can be many) have the selectcommand=”<View></View>” by default, so there is no efficiency in the “join”.  I haven’t seen issues with this, even with thousands of rows, but folks often [virtually] look at me askance when I suggest doing the filtering after the items have been retrieved.  (I often reply with “I learned to program in 16k of memory, so this makes me blanch, too, but I just haven’t seen performance problems.)  If you expect that you will have large numbers of items in your lists, think about how you can add WHERE clauses into your CAML to reduce the number of items retrieved initially as I mention above.
• When you add the first Joined Subview, what happens is that a second set of templates called dvt_2, dvt_2.body, and dvt_2.rowview are created in your DVWP. This set of templates is for the second Data Source (thus the names).
• The “join” isn’t really a join at all.  The dvt_1.rowview template calls the dvt_2 template and the values of the columns which you specify in the Joined Subview dialog are used to filter the second Data Source, something like this:

  <xsl:call-template name="dvt_2">
  <xsl:variable name="dvt_ParentRow" select="current()" />
  <xsl:variable name="Rows" select="../../../Assignees/Rows/Row[@Title=$dvt_ParentRow/@Title]" />

You can watch all of these things happen if you follow along with Laura’s video and do the same things that she is doing in Split mode in SharePoint Designer.  At this point, you’re sort of where I end up when I do most of this manually.  However, there are some best practices which I follow which I thought I’d pass along:

• Rename the templates from dvt_1.* and dvt_2.* to match your list names.  So, given the code above, I’d rename dvt_2 to Assignees, dvt_2.body to Assignees.body, and dvt_2.rowview to Assignees.rowview.  This makes following even your own code much easier, and it certainly ought to make more sense to someone else who gets stuck with it.
• Rather than using the dvt_ParentRow logic above, call the dvt_2 template (which is called something like Assignees now, right?) with the columns you want to “join” on as parameters, something like this:

  <xsl:call-template name="dvt_2">
      <xsl:with-param name="Title" select="@Title"/>
  </xsl:call-template>

  and then the top of your dvt_2 template looks like this:

  <xsl:template name="dvt_2">
    <xsl:param name="Title""/>
    <xsl:variable name="Rows" select="../../../Assignees/Rows/Row[@Title=$Title]" /> 

• This way, if you need to “join” (notice how I keep putting “join” in quotes) based on multiple columns or a calculation, you’re positioned for it.  Simply pass in the additional parameter(s) and add the logic to the filter in dvt_2.

Once you’re as familiar with DVWPs as I am, you may forego the dialogs, too, but hopefully this gives you some better ideas about what’s going on “under the hood”.

jQuery Fun with Animation and Opacity

Over the last few days, I’ve been doing some more work with jQuery.  It’s really a very cool abstraction on JavaScript, but it does take some getting used to.  My latest challenge is to understand .animate.  It’s pretty straightforward, but cross-browser issues can make it tricky.  I’m having “special” trouble with opacity in Internet Explorer.  It’s probably not a surprise that IE thinks about opacity differently than the other big browsers (Firefox, Safari).

The CSS for opacity in most browsers looks like this:

#MyID {
  opacity= .4;
}

The values for opacity can be 0 (transparent) to 1 (opaque).

In Internet Explorer, opacity is set like this:

#MyID {
  filter: alpha(opacity=40); /* IE5-7 */
  -ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=40)"; /* IE8 */
}

The values for opacity in this case can be 0 (transparent) to 100 (opaque).

What I’m trying to do is to get a tag line to animate by fading in and sliding to the right at the same time on a banner background.  Well, why not just use Flash or Silverlight, you might ask?  The answer is partly that I want to learn how to do this and partly because I think it will be great to let users set the text anytime they want in a Content Editor Web Part (CEWP) in SharePoint and have the banner text just change immediately.  (I know there are ways to do this with Flash and Silverlight as well.)

I’m stuck on the opacity in IE.  Take a look at the SophiaThink Consulting home page (live but not “launched” yet) and let me know if you have a fix.  It’s working great in Safari and Firefox, but looks pretty bad in IE.  I’ll post the solution when I find it.

UPDATE 2009-07-24 14:50 – Found this blog post that gave me some insight on IEs quirks with opacity.  Turns out the filters aren’t the same in IE8 (which I am using) and IE5-7!  Yeah, like that was obvious.

UPDATE 2009-07-24 15:35 – Everything’s working well, except the text is grainy after the animation.  From what I’ve read, jQuery ought to handle this in IE by removing the alpha filters when the opacity is 1 (100).  I’m trying to do this myself, but still no joy.  Here’s the jQuery at this point:

$("#BannerText").css({
    width: "100%",
    opacity: "0.0",
    marginLeft: "20px",
    fontSize: "26px"
   }).animate({
    width: "100%",
    opacity: "1.0",
    marginLeft: "100px",
    fontSize: "26px"
   }, 5000 ).removeClass("filter -ms-filter");

UPDATE 2009-07-27 – If you can’t make it work, find a compromise that will. I’ve decided to back off on the fade in in IE. There just doesn’t seem to be a way to make the opacity animation work without ending up with grainy text.

Here’s the CSS and jQuery I’ve ended up with.  It looks staggeringly simple given the amount of time I’ve fiddled with it!

.BannerLarge div span {
 width:70%;
 opacity: 0; /* Firefox and Safari */
 padding-top:55px;
 margin-left:20px;
 float:left;
 font-family:"Franklin Gothic Book", Helvetica, sans-serif;
 font-size:26px;
 color:#ffffff;
}

if(jQuery.support.opacity) {
    $("#BannerText").animate({
     opacity: "1.0",
     marginLeft: "100px"
    }, 5000 );
   } else {
    $("#BannerText").animate({
     marginLeft: "100px"
    }, 5000 );

UPDATE 2009-08-02 – I think that the issue in the above situation is actually caused by the background image format. (I haven’t yet been able to find out exactly how the graphic designer created the image.) Because I liked the effect, I tried something similar on the Sympraxis Consulting site. It seems to work fine in IE, too. I created the simple background image using Gimp and deployed it as a JPG.