May 2008 - Posts - Glenn Block

Ruby on Rails on the DLR, getting closer

Just caught this little gem from John Lam on Twitter

This is very good news.

Posted May 26 2008, 11:21 AM by Glenn Block with 2 comment(s)

Using ViewModels and DataTemplates to compose your UI

Several drops ago we introduced a ViewModel composition spike. The purpose of this spike was to introduce a different way to compose your UI that WPF offers. That is instead of having your views and regions be UI-Elements, having them as pure models. What I mean by this is instead of having a Employee Region which is a tab, that contains EmployeeViews, you have a model (the region) that contains Employees. Likewise instead of of having a panel that displays a CustomerView, you have a model that contains a single Customer. So how do I get my Employee region to display as a Tab, and my Employee to display itself in the same way as the EmployeeView? The answer is using DataTemplates. Using DataTemplates, you can define the UI rendering for a specific type (in this case the Employee and the EmployeeRegion). The nice thing for the no code-behind zealots among us is that there is absolutely NO CODE BEHIND in a DataTemplate.

Below you can see an example of what an Employee template might look like.

<DataTemplate DataType="{x:Type Employee}">

    <Grid x:Name="GeneralGrid">

        <Grid.ColumnDefinitions>

            <ColumnDefinition></ColumnDefinition>

            <ColumnDefinition Width="5"></ColumnDefinition>

            <ColumnDefinition Width="*"></ColumnDefinition>

        </Grid.ColumnDefinitions>

        <Grid.RowDefinitions>

            <RowDefinition></RowDefinition>

            <RowDefinition></RowDefinition>

            <RowDefinition></RowDefinition>

            <RowDefinition></RowDefinition>

        </Grid.RowDefinitions>

        <TextBlock Text="First Name:" Grid.Column="0" Grid.Row="0"></TextBlock>

        <TextBlock Text="Last Name:" Grid.Column="2" Grid.Row="0"></TextBlock>

        <TextBlock Text="Phone:" Grid.Column="0" Grid.Row="2"></TextBlock>

        <TextBlock Text="Email:" Grid.Column="2" Grid.Row="2"></TextBlock>

        <TextBox x:Name="FirstNameTextBox" Text="{Binding Path=FirstName}"

            Grid.Column="0" Grid.Row="1"></TextBox>

        <TextBox x:Name="LastNameTextBox" Text="{Binding Path=LastName}"

            Grid.Column="2" Grid.Row="1"></TextBox>

        <TextBox x:Name="PhoneTextBox" Text="{Binding Path=Phone}"

            Grid.Column="0" Grid.Row="3"></TextBox>

        <TextBox x:Name="EmailTextBox" Text="{Binding Path=Email}"

            Grid.Column="2" Grid.Row="3"></TextBox>

    </Grid>

</DataTemplate>

Julian has a set of posts where he is discussing this interesting approach to composition. He's done two posts so far, but I am sure there's much more to come.

Using the Presentation Model in WPF

First approach to Presentation Model with DataTemplates

Great stuff!

Posted May 24 2008, 09:10 AM by Glenn Block with 10 comment(s)

Filed under: prism, WPF

Dispelling some urban legends about LINQ to SQL

Scott has a great post where he dispels the following two myths about using LINQ to SQL.

LINQ to SQL requires you to start with a database schema.
LINQ to SQL requires your classes to implement INotifyPropertyChanged and use EntitySet<T> for any associated collections.

Looking at the post I think he also added in dispelling a third legend, though he didn't explicitly call it out.

LINQ to SQL requires you to use custom attributes in your code and cannot work with a simple poco. (In other words, LINQ to SQL supports persistance ignorance!)

Personally I have not used LINQ to SQL yet, though I do intend to play with it at some point. I know I have talked to many folks (including friends at Thoughtworks) and I have heard it far easier to grok and use than some other Entity frameworks :)

On the intuitiveness said, I am sold. It took me about five minutes of looking at sample code to understand how to use it.

Thanks for this post Scott!

Posted May 18 2008, 11:26 AM by Glenn Block with 5 comment(s)

Filed under: LINQ

Guidance for developing custom solutions with SharePoint 2007.

First let me start off by allaying all your fears, "No it's not another factory". :-)

For a while we've been hearing a lot of requests from customers for patterns & practices to deliver guidance on SharePoint. For several weeks now we've been exploring this space, and evaluating where we might be able to deliver value.

With the new guidance, we want to focus on a specific set of scenarios which SharePoint is appropriate for. We then want to focus on what solution is appropriate for addressing those scenarios and why.

If you've been developing SharePoint solutions, then we need your help. Please take the following survey and let us know what your pain points are, where do YOU see the most need for guidance?

Posted May 18 2008, 01:48 AM by Glenn Block with 8 comment(s)

Filed under: Featured, SharePoint

Prism, CAB, and WinForms futures

On the forums, Bil asked the questions below.

Just wondering about guidance here. I have clients who are not ready or able to move to 3.5/VS2008 yet but need to start developing new Smart Client applications. They're also not ready to move to WPF as they don't see a lot of value in it for the type of apps they need.
That sort of leaves me between a rock and hard place IMHO. Prism is good, but only if you're on the 3.5 platform and want to build WPF apps (right?).

Smart Client Software Factory is good if you're on the 3.5 platform and want to build WinForms apps but you're tied to ObjectBuilder and CAB (and we won't open that can of worms).
So what does one do when you're living in reality (2.0 platform, WinForms) and need to build new Smart Clients. Are you stuck using either the old SCSF/CAB setup or RYO.
Wondering if there's any plans for Prism to be a little more broader than WPF or what the alternaties are?

Thanks.

Below is my answer. I hope this clarifies these questions which are on many customers' minds.

Great question Bil

1. We have an FAQ we will be including in our Docs that clarifies how Prism is postioned against our other offerings. I've posted the content of that below. Let me know if it makes sense.
How does Prism compare to patterns & practices’ other Composite UI offerings?

Within patterns & practices, we have several offerings for building composite applications. The following list highlights the scenarios where you should consider using each:

Smart Client Software Factory: Recommended for WinForm composite application development.

Mainstream recommendation for LOB applications.
Leverages the most mature platform.
Offers the best development and debugging experience (tooling, control support, drag & drop, RAD experience).
Best for forms over data-type applications (order entry, etc).
Includes guidance automation (guidance package support and recipes).

Smart Client Software Factory and WPF interop: Recommended for islands of WPF in an existing SCSF application.

Allows leveraging existing SCSF infrastructure.
Includes guidance automation (guidance package support and recipes).

WPFCAB: Recommended for migrating existing CAB applications to WPF.

Pure WPF.
Allows leveraging existing SCSF infrastructure, except for views.
Not maintained or owned by p&p, supported by community.
Literal port of CAB to WPF (not optimized for WPF paradigm).
Does not include guidance automation.

Prism: Recommended for building new composite WPF applications that are optimized for WPF.

Targets WPF composite application development.
Lighter-weight, ability to pick and choose.
Better integration with existing applications and libraries.
Does not include guidance automation.

2. As to what to do if your clients need to build composite UI apps, but they are not ready to move to 3.5? In terms of p&p current offerings, SCSF is the only option. Notice I said building composite UI, not smart client as SCSF on the whole is not necessarily appropriate for all smart clients. Once option is to explore using many of the Prism services in Winforms as they are NOT UI dependent (more about this in the next points).

3. On the 2.0 / Winform question, Prism libraries take hard dependencies on 3.5, not only on WPF, but also in LINQ and Lambda usage. Now most of the services do not actually depend on WPF, including Module loading, EventAggregator (currently depends on Dispatcher, but we are moving to use synchronization context). The LINQ/Lambdas could be removed. The RegionManager depends on WPF in it's use of attached properties for registering. But you can also register regions imperatively, thus allowing you to have a WinForm RegionManger that does not use attached properties. Now whether or not the guidance / libraries would be appropriate for Winforms, is a different story and one that you would have to answer.

4. Will Prism be more broader than WPF? Silverlight is definitely something we are looking at. There is already a version for Silverlight on our contrib site. Would do Winforms / Web guidance on Prism? It's possible, though not something we have thought a lot about to date. We've worked really hard to be focused, and not look outside of our main focus area that is WPF. At the same time we the design is very malleable, and loosely coupled, making it potentially usable on other platforms. Mono version of Prism anyone?

Posted May 10 2008, 09:32 PM by Glenn Block with 2 comment(s)

Filed under: prism

WPF, from this to that..Wow!

A few weeks ago, our reference implementation for Prism looked like this.

Early on we decided that we needed the RI to have a better look in feel so that it delivered a more real world WPF experience. We hired a design firm to create XAML proofs based on our implementation. The process on their end was two fold. First there we a graphic designer who created non XAML proofs. Then a XAML developer converted those proofs to XAML.

Once we got the proofs, Adam Calderon from Interknowlogy (on our team) team took two weeks, and merged the new XAML into our existing codebase. In the migration, there were a few aspects of the proofs that we decided not to apply because we wouldn't push on the scenarios we need to. However, the changes we did apply, did not require much code rework to the application itself.

This is what came out of that effort, and what was in our last drop.

I must admit, I was previously skeptical of the whole designer-developer interaction and what was really possible. I am definitely now a true believer! Great job WPF team!

Posted May 08 2008, 06:44 AM by Glenn Block with 9 comment(s)

Filed under: Composite WPF, Featured, prism, WPF

Prism vs Framework XXX

http://www.flickr.com/photos/mukluk/288925731/

There's been a bunch of talk on the net comparing Prism to other frameworks that exist. In many cases comparisons are being made based on feature parity and such. I think it's important to make the distinction of why Prism is different.

Prism is a set of guidance for building Composite UI applications with WPF. It is not a framework, though it includes a light framework that was refactored out of building the guidance. This is actually a very small part of it. Here are some of the things that are different about Prism.

Built with some of the leading WPF experts in the industry.
Includes a reference implementation that was developed under the review of more than 25 industry experts, including several fortune 500 companies, the WPF team and the .NET product teams.
Includes comprehensive documentation on building Composite UI applications, what kinds of challenges they solve, when they are appropriate, which design patterns and principles they incorporate.
Includes How-Tos walking through how to implement the various composite functionality within your apps.
Includes several Quickstarts designed to ease adoption, and to illustrate specific aspects of building Composite UIs.
Allows customers to incrementally adopt it in their existing WPF applications rather than starting from scratch.
Incorporates a Composition model that is non-invasive.
Fully black-box and white-box tested.
Built entirely with Test Driven Development. Full code coverage and unit test suites.

This does not mean that Prism is the end-all solution, as I have said many times that is not. It does mean however that is much more than a framework with a bucket of features. We're not building it to be feature-laden, we're building it to best address a specific set of scenarios.

As a friend of mine told me, "less features is a feature".

Posted May 08 2008, 01:33 AM by Glenn Block with 7 comment(s)

Filed under: Composite WPF, Featured, prism, WPF

Unity and Silverlight

It can be done! Go read Chris's post for more. Jared if you are listening, we need this for PrismContrib. (which I still need to post about)

Posted May 05 2008, 05:08 PM by Glenn Block with 2 comment(s)

Filed under: prism, silverlight, unity

Reflections on ALT.NET Seattle, breakfast

What do you do before you head over to a day of grueling open-space sessions? Why head to Ruby's diner for breakfast of course.

Here's my table with Jeremy Miller, Jason Grundy and Jarod Ferguson.

We weren't the only ones who showed up. That's Roy Osherove in the corner (without a guitar), and Scott Reynolds doing what looks like tweeting. The side profile is ~~Dru Sellers~~.Dustin Campbell

Others showed up as well like Udi Dahan and Don Demsak though they escaped my cameras wrath :-) Anyway, after eating our "Wheaties", we headed over to Digipen for the opening session. with full bellies and eager minds.

Posted May 05 2008, 12:12 AM by Glenn Block with 6 comment(s)

Filed under: ALT.NET

PrismShouldNotReferenceUnity

Clarification: We are not against using Unity, the Prism RI uses Unity, and we've been very happy with it's implementation. We are after all one of Unity's first internal customers. On the other hand, we want to make it easier for customers to use their IOC container of preference, which is what this post illustrates.

Friday night Oren (Ayende) and I headed downtown to Seattle at the Tap House grill, where we paired and hacked there and at my apartment into the early hours of the morning. You can see me tweeting about it below.

One of the best parts of the evening is the part I have highlighted in red, which happened after a discussion we had on how Prism does not depend on Unity. I told Oren that we had thought of automating as part of our tests to check whether or not any reference was included but that we found it unnecessary as the team was very clear on this requirement. He however disagreed and said "You should, you should" in order that we emphasize it. He then pulled open VS and wrote this test.