SharePoint Apps: Alexander Malek's weblog

Welcome to VS extensions for WSS!

Alex Malek — Tue, 07 Nov 2006 16:34:00 GMT

Download VSeWSS.

Greetings from TechEd Barcelona! Today, we finally got to announce a project I've been working on for the last year: "Visual Studio 2005 extensions for Windows SharePoint Services 3.0". Yup, the name's a mouthful :). Explaining it is pretty easy though - make "F5" work for SharePoint stuff in VS! That's essentially what VSeWSS brings to the table. Once you have it installed, you can actually boot VS, create stuff for WSS and have it work. For example, if you want to build a web part, from the "New Project" dialog in VS, choose "Web Part" under the "C#/SharePoint" node. Add some code and you're done. You can hit F5 and immediately debug your web part. Pretty cool, no?

In addition to web part support, VSeWSS also helps you build Site Definitions, List Definitions and Content Types. Over the next few weeks, I'll use this blog to explain how to use the various parts of VSeWSS. In the meanwhile, download the bits and drop any questions you have to "microsoft.public.sharepoint.development_and_programming".

Cheers,
alex

My TechEd Slides

Alex Malek — Thu, 06 Jul 2006 00:04:00 GMT

Thanks again to everyone who showed up for the SharePoint Designer talks at TechEd! As promised, here are my slides from the presentation (attached to the posting). Thanks! -alex

Changing the ‘return URL’ for SharePoint forms

Alex Malek — Sat, 17 Jun 2006 19:57:00 GMT

Here’s a quick little tidbit that will help when building SharePoint applications. By default, when users fill out a SharePoint form, they are navigated back to the "All Items" page after pressing OK. You can easily change this behavior by altering what is in the “source=http://…” part of the URL "query string" on the form page.

Example: Let's add a link to the Announcements “New Item” form on the home page, so that it returns the user back to the home page after they press ok.

Step 1) Add the following URL to the home page:
http://<site>/Announcements/Forms/NewItem.aspx?Source=http://<site>/default.aspx

That’s it! :) Once the user presses OK, the form will read the “source=” part of the URL and navigate the user back to that page.

Thanks to Jason and Andre for suggesting this blog tip!

So long TechEd (and thanks for all the fish)

Alex Malek — Sat, 17 Jun 2006 00:26:00 GMT

Just about to take off for Seattle – finally catching up on a week’s worth of email backlog :). Overall, TechEd was a blast. It was great to be able to show off SharePoint Designer to so many people. Thanks to everyone who came by after the sessions or to the booth. I got tons of great questions and suggestions, many of which will help us in planning vNext. Please keep the feedback coming!

SharePoint Designer at TechEd!

Alex Malek — Sun, 11 Jun 2006 15:21:00 GMT

I’m excited to be going to TechEd this week. I'll be presenting two sessions on SharePoint Designer 2007. If you have any questions about building apps on SharePoint, definitely come by the session or the Office booths! See ya in Boston.

Session ID: OFC210
Session Title: Office SharePoint Designer 2007: Create and Customize Microsoft SharePoint Web Sites and Build Workflow-Enabled Applications
Description: Come and learn about Office SharePoint Designer 2007. This is the powerful and easy to use tool for information workers to automate business processes and build efficient applications on top of the SharePoint platform, and tailor their SharePoint site to their needs in an IT-managed environment.
Time Slot 1: 6/13/2006 1:00PM-2:15PM [Breakout 08]
Time Slot 2: 6/14/2006 10:15AM-11:30AM [Breakout 12]

5 Cool SharePoint Designer Features

Alex Malek — Fri, 02 Jun 2006 03:11:00 GMT

There is so much stuff in SharePoint Designer 2007, it's hard to pick favorites, but if I had to choose the five things I'm most excited about...

1) Data View v2:
In addition to update (form) support, we can also now create "aggregate" views across multiple sources, have a cool new Xpath "Expression builder", integration with the "Business Data Library", not to mention a nice UI for managing view parameters.

2) Workflow Designer:
Leveraging the new "workflow" capabilities built into the SharePoint platform, we added a "rules-based" designer to SPD that allows you to quickly add application logic to your SharePoint apps. Think of it as a way to put code behind your apps. I'll be talking about this feature lots more soon :).

3) CSS support:
We built a whole slew of features to create and manage CSS styles. We also worked with the SharePoint team to make it possible to 'detach' from ows.css (now called core.css) and easily customize the SharePoint stylesheet.

4) Better code view:
CSS/XSLT/Xpath intellisense, code view/design view sync for Data Views (best feature ever!), CSS hyperlinks, and more.

5) Rich ASP.net integration:
We collaborated with the Visual Studio team to build really deep support for ASP.net into SharePoint Designer, e.g. great previews in design view, full property grid support, as well as support for bringing up the native "builder" dialogs.

Welcome to the list of features I plan to blog about over the coming months :).

oh ya, did I mention we also built "Re-Ghost Page"?!

Welcome to Office 2007 and SharePoint Designer!

Alex Malek — Fri, 26 May 2006 06:44:00 GMT

Now that beta2 of Office is out (grab it here for free!), I think it's a great time for me to switch over from talking about FrontPage 2003 to SharePoint Designer 2007. In case you hadn't heard, a few months back we announced that Office 2007 would include a new product called SharePoint Designer, aimed specifically at enabling rapid application development for the SharePoint platform . SharePoint Designer (SPD) is very much the continuation of what we started with SharePoint app development in FrontPage XP and 2003. SPD takes the best parts of FrontPage and adds a ton of new capabilities to the Data View web part, a cool new "Workflow" designer for adding application logic to your SharePoint site, not to mention great CSS and ASP.net support. Overall, I think this change is great for fans of building apps on SharePoint. And since Microsoft now has a dedicated product, Expression Web Designer, for addressing the needs of web designers, we as the SharePoint Designer team can focus all of our efforts on building the absolute best design tool for SharePoint.

Cool Outlook Trick

Alex Malek — Tue, 16 May 2006 19:04:00 GMT

One of my long pet peeves about Outlook is that if you search for a user in the “Global Address List” that happens to be in your “Contacts” list, Outlook always returns the entry from the contacts list. This is a pain since sometimes there is information in the global address book (e.g. phone number) that one doesn't have copied to the local entry. Well, turns out there is a power user feature to work around this. If you type “=username” in the contact search box, it will always return the entry from the global address book. Sweet.

Allowing Users to Filter/Search a Data View

Alex Malek — Tue, 25 Apr 2006 19:06:00 GMT

In my previous post, I talked about how Web Part Connections can be used to pass data between Web Parts. I showed building a simple master/detail scenario, where you have one view, showing all the records in a data source, filtering a second "single item" detail view of the same source. There are tons of other scenarios where Connections are useful. For example, imagine if you could have a little form on your web page, where any values entered into that form could be passed into a connection. As luck would have it :^>, we built a part exactly for this scenario, called the "Form Web Part"! Little fyi: the Form Web Part was actually the very first feature I worked on when I came to MS, so I'm kinda partial to it :)

Quick example: Using a Form Web Part to "search" the Title field of an Announcements List view

1) You can insert a Form Web Part by clicking Data/Insert Web Part, and then from the Web Parts task pane, dragging the Form Web Part into your page. By default, this is what the Form Web Part looks like, a single text box with a "Go" button:

Note: You can add more form controls (including other types of controls) to the part by using the Insert/Form menu, but for this scenario, the default setup will work.

2) Next you need to add a view of the Announcements list to your page. We'll filter this view with the value entered into the Form.

3) You can now right-click anywhere inside the Form Web Part and choose "Web Part Connections...". In the Connections Wizard, hit Next on the first two pages. On the third page, choose the "Announcements" part as your target part. However, unlike in the last example, instead of using "Filter View Using Data Values" as the Target Action, choose "Modify View Using Parameters", and hit Next.

4) Long story short, there are two ways to use Web Part Connections: 1) as show in the previous post, the source part can affect the target using one of the default connection "verbs", e.g. filter the target part, or 2) the source part can just pass a value to the target part, and leave it to the target to do whatever it wants with that value. In this demo, we're using option 2, since we want to have finer control over the type of filtering done in the target part.

The Data View has a default parameter we can use called "Input Parameter. The way to pass the value from the textbox in our form is by choosing "T1" in the left column. You then hit Next.

4) After you hit Finish in the Connections Wizard, there is still one more step remaining. We need to go to the target part, in this case, the view on Announcements and define what to do with the value that comes from the parameter. For our scenario, since we want to Filter the view with the parameter value, select the Announcements view and choose the Data/Filter menu item, which will bring up the Data View filter UI.

For the field name, choose "Title" - for the comparison, you likely want "Contains" - and for the value, we can plug the parameter in here by choosing "[Input Parameter]".

Press OK, and your done! Now, if you browse the page, you should be able to enter a value into the form part and have the view filter to only show values that contain what was typed in the form.

Note: You probably noticed that the view shows no records by default - this is due to the fact that the parameter we're filtering on is blank when the view first loads. One way to work around this is to give the parameter a "default value", which you can do in code view by searching for the following line, and setting the DefaultValue attribute to whatever you'd like the value to initially show.

<udc:ClientParameterBinding Name="filterParam" Location="Postback;Connection" DefaultValue="baz"/>

Using Web Part Connections to build a Master/Detail View

Alex Malek — Mon, 10 Apr 2006 20:22:00 GMT

One of the great new features part of SharePoint v2 is this thing called "Web Part Connections", which allows you to easily have Web Parts communicate with each other, thus adding a level of interactivity to your web applications. In a way, you can think of connections is as a data-driven hyperlink, i.e. clicking the hyperlink will push some data to the second part, which can then consume that data. The most common Connection scenario is to use one part to filter another other one, e.g. imagine having a "master" view, where you can drill from each item to a detail view.

Quick Example: Let's look at what's involved building a master/detail view of a products table. In this example, I'll use Data Views for both my master and detail view, but it should be noted that you can connect different types of parts together too!

Step 1: The first step is to build a simple "master" view showing all the records in my products list

Step 2: Next, on the same page, let's build a "detail" view that shows a single item from the Products list, but with more detail.

Step 3: Once you have your views setup, you can quickly create a connection so that clicking an item in the master will cause the detail view to be filtered to the same item. To do this, right-click the field you want the connection hyperlink on, and choose the "Web Part Connections..." context menu item. This will bring up the Connections wizard.

When setting up a connection, it's easiest to think of the two parts as source and target. The first step is to choose what you want from the source part. 99.9999% of the time, you simply want to grab some values from the source part and pass them along - this is the default option, so you can just click next.

On the next page of the wizard, you get to choose which part to connect to. In the case of this master/detail scenario, I have the "detail" part on the same page, so I can click next again.

Here, we choose the specific part and what we want to do to that part. The default behavior is to filter the target part, which for our scenario is the desired behavior.

The last piece of information required is to choose what field the target part should be filtered to from the source part. Since both parts in this case are on the same list, we can use the ID field, since that is guaranteed to be unique.

That's it! You can now click through and complete the wizard. After you hit "Finish", you'll notice that there is a hyperlink on the original field you selected.

If you browse the page, you'll notice that clicking the hyperlink in the "master" view will cause the "detail" view to filter to the correct item. Sweet :)

How to Create a Data View that Shows a Single Item

Alex Malek — Fri, 31 Mar 2006 03:06:00 GMT

When you first insert a Data View, the default "look" is always a tabular multi-item view; however, it's easy to change this to whatever style you want. We even include a few pre-built styles in the box that you can quickly switch between. To change the style of your view, go to the Data menu and click "Style...". From the "View Styles" dialog that pops up, you can change between a few different styles.

Quick example: One of the more common types of views you'll often want to create is a "single item" item view.

Step 1: Create a tabular Data View that includes the fields you want to end up in the single item view:

Step 2: Click Data/Styles and choose the forth style - repeating form with border. Your view should now look something like this:

Step 3: The last step is to change the view so that it only shows one record. You can do this by clicking Data/Styles again and going to the "Options" tab of the View Styles dialog. At the bottom of the dialog is a section called "record sets", where you can change how many records are shown in your view. For the single item view scenario, we want to "limit the total number of items" to 1.

Voila, you now have a view showing just one item. The only thing left to do is filter the view to the specific item you care about :).

Next time, I'll show you how you can use a feature called "Web Part Connections" to allow users to dynamically filter a single item view from a "master" multi-item view.

Welcome to Office 2007 and SharePoint Designer!

Alex Malek — Sun, 26 Mar 2006 04:06:00 GMT

Now that beta2 of Office is out (grab it here for free!), I think it's a great time for me to switch over from talking about FrontPage 2003 to SharePoint Designer 2007. In case you hadn't heard, a few months back we announced that Office 2007 would include a new product called SharePoint Designer, aimed specifically at enabling rapid application development for the SharePoint platform . SharePoint Designer (SPD) is very much the continuation of what we started with SharePoint app development in FrontPage XP and 2003. SPD takes the best parts of FrontPage and adds a ton of new capabilities to the Data View web part, a cool new "Workflow" designer for adding application logic to your SharePoint site, not to mention great CSS and ASP.net support. Overall, I think this change is great for fans of building apps on SharePoint. Since Microsoft now has a dedicated product, Expression Web Designer, for addressing the needs of web designers, we as the SharePoint Designer team can focus all of our efforts on building the absolute best design tool for SharePoint.

Conditional Image Swapping in a Data View

Alex Malek — Thu, 23 Mar 2006 03:45:00 GMT

One of the cooler uses for Conditional Formatting is to to dynamically swap between a set of icons/images, e.g. imagine a scenario where you want a red, yellow or green light based on how a sales department is tracking to budget. Although it's possible to build this kinda of view with the Conditional Formatting feature, it's a bit of a pain since you not only need to define the conditional to "show content", but also all the conditions when not to show the content. If you are swapping 3 or less images, you can get buy. However, since the number of total conditions grows exponentially with each image, it soon becomes untenable. Fortunately, the Data View is built on XSLT, which has a command exactly for this specific problem, and though we don't have UI to automatically create the right XSLT, it super easy to go into code view and made the change yourself.

Quick Example: Imagine you have a Data View of products, where each product comes from a different county. The default view works, but it's a little on the boring side. It's also difficult to scan and quickly see which products come from which country.

A nice little improvement would be to show the country flag instead of the name of the country.

The first step to building this view is to drag one of the flag images into your view and use "Show Content" Conditional Formatting to only show the flag when it matches the country of origin. In this case, I'll start with the Canadian products.

Next, you need to jump to code view and search for the XSLT that defines this conditional formatting: <xsl:if test="@country = 'Canada'">.

Instead of using <xsl:if>, XSLT supports a tag called <xsl:choose>, which is exactly for the scenario of choosing among multiple options. <xsl:choose> is analogous to the C# Switch construct. To use <xsl:choose>, first wrap the existing <xsl:if> block with an <xsl:choose> tag. Next, change the word if to when,, as shown here:

The last thing to do is add one <xsl:when> block for each of the possible images, like so:

That's it. When you switch back to design view, you should see the following:

Note: you can also finish your choose block with an <xsl:otherwise> block to define an "else" condition, i.e. when no condition matches.

Conditional Formatting Internals

Alex Malek — Thu, 23 Feb 2006 11:15:00 GMT

The inner workings of Conditional Formatting are actually pretty straightforward. The key construct that makes the feature possible is a tag called <xsl:if>, which is used to conditionally add content to the HTML output of the transform.

It's easiest to grok xsl:if with the "show content" type of CondF. Basically, the content you want conditional shown is wrapped in a xsl:if tag, where the test attribute of the tag defines the "condition" to be evaluated. If the condition is true, the content contained within the xsl:if gets output into the resulting HTML. If not true, nothing gets output.
<td>
    <xsl:if test="@Units >= '500'"><img src="Dc39.jpg" width="33" height="29" /></xsl:if>
</td>

For "apply formatting" CondF, the markup is only slightly more complicated. In this case, the xsl:if part remains the same - the only trickiness is that in tis case we want to affect an attribute (style on the parent <td> container), not another tag. One does this by wrapping the xsl:if tag with an xsl:attribute tag. Using the name attribute on the xsl:attribute tag, we can define which attribute the optional content gets added to. In this case, it's the "style" attribute.
<td>
    <xsl:attribute name="style">
        <xsl:if test="@Units >= '500'">background-color: #FFFF00;</xsl:if>
    </xsl:attribute>
</td>

That's pretty much all there is to Conditional Formatting. One of the nice things about understanding the markup is that you can exact "formatting" you desire. Next time, I'll show you how how you can do some more advanced conditional formatting by manually editing the XSLT.

Grokking "Show Visibility" in the Conditional Formatting Task Pane

Alex Malek — Sat, 11 Feb 2006 05:03:00 GMT

Sometimes true Wysiwyg is not what you want in design view. For example, if you are using Conditional Formatting to optionally show content in your view, and your data is such that all records evaluate to false, you end up in a situation where you can no longer select the tag that holds the Conditional Formatting. To address this issue, we build a little feature into the Conditional Formatting task pane called "Set Visibility", which allows you to force the Conditional Formatting "on/off" states, regardless of what the "conditional" evaluates to.

The "Set Visibility" button has three options (note: these are only available if CondF is applied to the view):
1) Default
2) All formatting hidden
3) All formatting visible

When we initially designed the feature, we had it so that "All formatting hidden" was the equivalent of forcing all "conditionals" to evaluate to false, and "All formatting visible" forced everything to evaluate to true. The problem we ran into with this design was that the resulting behavior was a little unexpected, e.g. "All formatting hidden" would cause every "Show Content" Conditional Formatting to disappear, since that's what happens when the conditionalal evaluates to false.

Since we didn't think that was the user's expectation, we changed the design so that "All formatting hidden" showed the view as if no Conditional Formatting had been applied, which translates underneath the covers to forcing "Show Content" CondF's to evaluate to true, and "Hide Content/Apply Formatting" CondF's to evaluate to false.

For the "All formatting visible" option, we left the design of that one alone - underneath the covers, it forces all conditionals to true, which means that the Show/Apply formatting are there for every row, and any content with a Hide on it, will be hidden for every row.

Example: Here's a view with a "Show Content" Conditional Formatting on the image, and "Apply Formatting" CondF on the 2nd column background.

Default view

All formatting hidden

All formatting visible

Interestingly, in the way we implemented the feature, "Set Visibility" options are actually saved into your page, which means that if you preview that page in the browser with a "Set Visibility" command like "All formatting hidden" set, you'll actually see the same thing in browser that FrontPage showed in design view. Arguably, a little weird :).

Conditional Formatting Part 2

Alex Malek — Sat, 21 Jan 2006 07:35:00 GMT

In addition to being able to show and hide content using Condition Formatting, you can also use the feature to dynamically change the presentation of your view, based on data in the associated data source.

Example: for the view of the "Product Sales" list, let's say you want to highlight the background of any product who's "Units Sold" exeeds 500.

The first step is to select the object you want the formatting to apply to. In this case, we need to choose the "Product" table cell:

The easiest way to make this selection is to click the <td> tag in the "Quick Tag Selector", which is the bar at the top of design view showing the tag hierarchy for the current selection:

Once you have the cell selected, click Data/Cell Formatting to bring up the "Cell Formatting" task pane. From there, choose Create/Apply Formatting. This will bring up the "Condition Criteria" dialog, where you can define the condition under which the content should be formatted. For this scenario, we want to highlight the background when "Units Sold > 500":

Once you have pressed ok in the "Condition Criteria" dialog, the formatting dialog will come up, allowing you to choose what formatting to apply. In this case, we want to set the background to yellow.

That's all there is to it. Exit out of formatting, and your view will now reflect the formatting you have chosen:

Data View Conditional Formatting

Alex Malek — Wed, 28 Dec 2005 02:23:00 GMT

One of the things XSLT makes really easy is "conditional formatting", i.e. having parts of your view appear differently depending on some data condition.

Quick example: let's say you have a view of a "Product Sales" list, and you want to show a flag icon beside any product that's sold more than 500 units. The first step is to add the flag image into the view, which will cause it to show up for every row:

Next, right click the flag image, and choose "Conditional Formatting". This will bring up the Conditional Formatting task pane. You can use this task pane to create new conditional formattings as well as manage existing ones.

Now click the "Create" button and choose "Show Content" - this will bring up the "Condition Criteria" dialog, where you will define the condition under which the content should be shown. For this scenario, we want to show the flag icon when "Units Sold > 500":

Press ok in the "Condition Criteria" dialog and you are done! You should now have a view where the flag icon only shows for products with greater than 500 units sold.

There are tons of cool ways to use this ability to conditionally show&hide content. One I use often is the "red light/green light" scenario - I put both a red light and green light icon in my, and define conditional formatting for both so that each row shows either a red light or a green light, giving a very quick very indication of whether an item is tracking to plan or not. Next up, I'll show how you can use conditional formatting to change the actual formatting of your view.

Wysiwyg XSLT Editing

Alex Malek — Sun, 04 Dec 2005 08:11:00 GMT

We built the Data View on XSLT for a couple of important reasons:

1) We wanted there to be a "real" programming language under the covers, so that our users would never be limited by what our UI allowed, i.e. even if FrontPage can't do something, you can always jump into code view and still solve the problem.

2) The very nature of XSLT, being a declarative programming language, made it possible for us to ship one of the richest design experiences out there for building data-driven views. In the most tools (at least any I've seen :>), the experience you have building the view is very distinct from what you get using at the view. At best, the design surface show you a very rough approximation (typically schematic) and any editing is done through intermediate tools, e.g. dialog boxes, code view, etc. With the Data View, thanks to the power of XSLT, we were able to deliver a no-compromises experience, where you always see the exact end product and editing works like you'd expect it to.

Example: To highlight the difference between most view building tools and the Data View, let's compare what it's like building a simple view of the SQL Northwind Products table using the Data View vs. the the ASP.net Grid View. Note: although I'm picking on the Grid View is this case, this comparison is valid for most app building tools out there.

Here's what the ASP.net Grid View looks like by default against the Northwind Products table:

As you can see, the Grid View uses sample data, not the real data, meaning the editing experience is different from what you get when you preview the page. You also can't directly format the view, i.e. you can't click inside and start editing. If you want to change the way the view works, the Grid View supports some amount of formatting using the "Edit Fields" dialog, but if you want to do anything really fancy, you're in the world of templates or .net code.

Contract that experience with the same table in the Data View:

Not only do we show 'live data', but you can also directly format the presentation of your view just like regular page editing. E.g. in the picture above, I was able to make the first column bold simply by clicking inside and pressing the bold button.

How it works: In previous posts, I explained that XSLT allows you to take an XML document and transform it into an HTML presentation. The magic of the Data View is that it allows you to go in the opposite direction - FP shows you the "transformed" HTML in design view and makes it look editable, pretty much like a regular table. However, under the covers, instead of mapping edits to html changes, your edits get translated by FrontPage into XSLT changes, which is what you'd see in code view. E.g. in the above scenario, when I made the product name bold, FrontPage figured out what part of the XSLT defined the product name, and wrapped the tag (in this case, an <xsl: value-of> ) with a <strong> tag. Of course, you can also go the other direction, edit the in code view and have us reflect those changes in design view.

This mapping of HTML edits to XSLT edits is what makes it possible for us to provide our great editing experience. And although the technical explanation is rather complicated (and frankly a bit above me :>), it's only possible with a declarative programming language like XSLT, where a program like FrontPage can truly "understand" how to read and write "code". One of these days, I'll interview one of our devs and get the "real" technical explanation for y'all :).

How the Data View uses XSLT

Alex Malek — Tue, 15 Nov 2005 23:59:00 GMT

In my last post, I talked a little about XSLT - how it can be used to mix data from an XML file with HTML markup, thus producing a web page presentation for that data. This is fundamentally how the Data View Web Part works. When the Data View executes within an ASPX page, it first fetches the data as XML, be it from SQL, a web service or a SharePoint list. That query is defined in the <dvwp:DataQuery> section of the markup. Next, the Data View executes the embedded XSLT markup (contained within <dvwp:XSL> tag) against that returned XML, which produces an HTML stream that is returned as the rendered output of the web part.

Of course, there are other server-side smarts built into the Data View, e.g. support for part to part connections, parameterization, etc, but the XSL transform is the heart of the of the feature.

Next up: the real magic of the data view - wysiwyg XSLT generation in FrontPage.

Quick and Dirty XSLT Primer

Alex Malek — Tue, 01 Nov 2005 23:54:00 GMT

...From the Open Internet Lexicon: "A Transformation Language to convert XML/XSL documents into HTML suitable for a browser to display." Personally, I like to think of it as language that sucks data from an XML file into an HTML file :).

Here's a quick example that demonstrates how XSLT can be used in combination with HTML to build data-driven web pages.

XSLT Example:

Let's say we have an XML file with three records, each the name of a breakfast food, and we want to display that data on a web page.

Here's our XML file:
<?xml version='1.0'?>
<BREAKFAST-MENU>
       <FOOD>
              <NAME>Eggs</NAME>
       </FOOD>
       <FOOD>
              <NAME>French Toast</NAME>
       </FOOD>
       <FOOD>
              <NAME>Waffles</NAME>
       </FOOD>
</BREAKFAST-MENU>

Here's what we want on the web page:

Breakfast Menu

Eggs

French Toast

Waffles

Using this XSLT (with inline HTML), we'll get the right HTML:
<table border="1" width="100%" cellpadding="2">
    <tr valign="top">
        <th nowrap="true"><u>Breakfast Menu<u></th>
    </tr>
    <xsl:for-each select="/BREAKFAST-MENU/FOOD">
        <tr>
            <td><xsl:value-of select="NAME"/></td>
        </tr>
    </xsl:for-each>
</table>

The final HTML (after the XSLT is processed):
<table border="1" width="100%" cellpadding="2">
    <tr valign="top">
        <th nowrap="true"><u>Breakfast Menu<u></th>
    </tr>
    <tr>
        <td>Eggs</td>
    </tr>
    <tr>
        <td>French Toast</td>
    </tr>
    <tr>
        <td>Waffles</td>
    </tr>
</table>

How it works:
When the XSL is processed, commands that begin with <xsl:> get treated like programming commands. The "for-each" statement causes the markup contained within the for-each to be processed once for each item that is returned by the select="/BREAKFAST-MENU/FOOD" command, which is this case returns the three food records. The <xsl:value-of select="NAME"/> command is what sucks the actual data from the XML file into the HTML. xsl:value-of food your best friend when it comes to understanding XSLT and particularly XSLT generated by FrontPage.

Next up: How the Data View uses XSLT.

Data View formatting: controlling the presentation of your data using 'Format Item As...'

Alex Malek — Sat, 08 Oct 2005 02:02:00 GMT

Beyond look and feel, there is lots of other formatting support in the Data View. One of the most important is that you can easily change the way the Data View interprets data for presentation, i.e. for fields such as dates, hyperlinks, rich text, numbers, etc, you can tell the Data View exactly how you would like that data represented on the page. For example, let's say you have a number field in your data source - in your view, you might want that number formatted as British Pound currency. Using the 'Format Item As...' feature, you can easily do this.

a quick example:
In this Data View, I have a 'created date' column. The data itself stores both the date and time for each record. However, in my view, I just want the date to show up...

I can easily make this presentation change by right-clicking any row Created column, and choosing the 'Format Item as -> Date & Time...' menu.

Clicking 'Format as Date & Time' will bring up a nifty little dialog we have which gives you the option to hide either the date or time. You can also change how either the date or time is represented. For example, you can change the date to be shown with the year first. For our little demo, we'll just uncheck 'show time' ...

Press ok and voila! As you can see, the time is now gone from the view.

In addition to being accessible via the field's context menu, you can also get at it from the top-level 'Data' menu. The feature works against all kinds of different field types - it's worth messing around with :).

Coming up, I'll dig a little into how the data view works (hint: it's built on standard XSLT technology) and how you can use that knowledge to your advantage!

Data View formatting: the basics

Alex Malek — Fri, 07 Oct 2005 05:35:00 GMT

I'm very happy to say that formatting a Data View works exactly the way you'd expect/want - you simply select the field you want to format, use the HTML formatting toolbar and voila: 'it just works'.

a quick example:
let's say you wanted to highlight the Title field in yellow. First you would select that field in the Data View. You can see in the image below that the design surface gives you some visual feedback (the orangish selection of "Test2", 3 and 4) that any formatting you do will affect every record of your data source.

Next, you would use the highlighter button in the toolbar:

That's it, that's all. You're title field is now highlighted yellow. And of course it's all data-driven, any new records added to this data source would get their Title field highlighted as well.

On first blush, this seems kinda obivous - I mean, how else would it work?? :) That's what makes the Data View so cool (imho), it allows one to create data-driven web pages exactly the way you'd expect to. Most other tools I've seen for creating 'views' of data, be it for client or server apps, have one work with a less intuitive, less wysiwyg experience. Typically, one doesn't get 'live' data in the design surface, nor is the formatting so direct.

Next up I'll show you some more interesting formatting you can do to the way the data itself is presented.

creating your first Data View

Alex Malek — Mon, 03 Oct 2005 18:28:00 GMT

Now that I've introduced the Data View web part, I'd like to give you a quick demo of how easy it is to add one of these data-driven views to a web page...

-> The main entry point for creating Data Views is the top-level menu called Data, which is a new menu to FP 2003. Nearly all of the Data View's functionality can be accessed via the Data menu - you'll definitely want to hunt and peck in there when you have some time. For our demo today, we want to insert a Data View from scratch, which one does by clicking Data/Insert Data View:

Step 1: Configure a data source
After clicking Data/Insert Data View, FrontPage will bring up a task pane called the 'Data Source Catalog' or DSC for short. As the name implies, you can use the Data Source Catalog to manage and configure all of your data sources. Now, it may seem a bit weird that 'Insert Data View' brings up a task pane for managing data sources, but the reason is that you first need to configure a data source to work with and that's what the DSC is all about. As you can see from the screenshot, the DSC supports many data source types: SharePoint lists, database servers (SQL, DB2, Oracle), XML files (both remote and local to the site), server url's and web services. The catalog is also pretty smart - it dynamically discovers any SharePoint lists or XML files in the site and aadds them to the proper category. Since the 'Announcements' list is already configured and ready to use, we'll work with this source for our demo. Note: It does gets a smidge harder when working with 'external' data sources such as web services, but nothing too crazy :)

Step 2: Select the data source
Once you have chosen a data source to work with and are ready to create a view, you can click that data source in the task pane and choose the 'Show Data' menu item. That will cause FP will navigate to another task pane called 'Data View Details' or DVD for short. The DVD is a really nifty piece of UI that will become your home for working with Data Views. Not only can you create and format Data Views from the DVD, but it also allows you to browse the records in your data set, as well as filter/sort that data.

Clicking 'Show Data' ->

Step 3: Create your Data View
When you are ready to add a Data View to you page, simply select the fields you want to be in your view and press the 'Insert Data view' link. FrontPage will then insert a new Data View at the current cursor location in your page. And that's all there is to creating a Data View! :) Once you have a Data View in your page, you can now format it using the regular FrontPage formatting tools.

In summary:
- the Data menu is your friend for creating data-driven web pages
- the 'Data Source Catalog' (DSC) is the place to manage all of your data connections
- using the 'Data View Details' (DVD) task pane, you can add Data Views to your page (as well as browse data sources)

Next up: Formatting your Data View

a story of data and views

Alex Malek — Fri, 30 Sep 2005 06:35:00 GMT

As I mentioned previously, my main area of focus on FrontPage is features that help users build applications for SharePoint. The cornerstone of our app creation experience in FP 2003 is a little thing we call the ‘Data View’ web part. You can think of the Data View as a Swiss army knife for creating data driven web pages, i.e. web pages with a ‘view’ of some stored data. The Data View allows you, without writing any code, to create views against nearly any data source - it supports SQL, xml files, web services and of course, SharePoint list data.

Here's a simple example of a page with a Data View on it. In this case, I used the Customers table from the SQL Northwind sample database:

One of the great things about the Data View is that the editing experience is completely wysiwyg, e.g. I was able to format the 'Company Name' column blue just by selecting the cell and pressing the Font Color dropdown.

There is tons more to the Data View - much of this blog (at least initially) will focus on its cool ins and outs. Next up, I'll run you through how I created the above view.

list editing gone wild

Alex Malek — Tue, 27 Sep 2005 07:54:00 GMT

In my last post, I mentioned the neato ‘Datasheet’ view that comes with SharePoint. I'm sure this is old hat to many of you out there, but on the off chance you haven't played with it, the Datasheet is definitely worth checking out. In a nutshell, the Datasheet is a special view that lets you do bulk editing of SharePoint list content. It's a great tool to have in your arsenal when you are building apps on SharePoint. You can get to the Datasheet by clicking the 'Edit in Datasheet' button that's on the detail view for most lists - you can also create a new Datasheet view via the list's view creation UI.

When you click the 'edit in Datasheet' button, you get a page that looks like this. Using the Datasheet grid control in the center, you can quickly add, edit or delete content. I use this view all the time when I need to quickly get a lot of data into one of the lists I'm building an application around.