<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" media="screen" href="/styles/xslt/rss.xslt"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:c9="http://channel9.msdn.com">
<channel>
	<title>Comment Feed for Channel 9 - Rules Driven UI using WF</title>
	<atom:link rel="self" type="application/rss+xml" href="http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF/RSS"></atom:link>
	<image>
		<url>http://ecn.channel9.msdn.com/o9/previewImages/100/208209_100x75.jpg</url>
		<title>Channel 9 - Rules Driven UI using WF</title>
		<link></link>
	</image>
	<description>Moustafa has put together this screencast to show off how you can use the Rules Engine capabilities contained in Windows Workflow Foundation outside of a workflow, and leverage it to drive the business logic
 of a Windows Forms application.&amp;nbsp; Check out the video, and if you&#39;re interested in more, then head on over to&amp;nbsp;&amp;nbsp;our community site&amp;nbsp;where
you can download the sample.

This is the article that Moustafa mentions that introduces the Rules Engine available at MSDN.


For more information on Windows Workflow Foundation, you can check the following resources:

http://wf.netfx3.com http://msdn.microsoft.com/workflow

</description>
	<link></link>
	<language>en</language>
	<pubDate>Tue, 21 May 2013 14:12:17 GMT</pubDate>
	<lastBuildDate>Tue, 21 May 2013 14:12:17 GMT</lastBuildDate>
	<generator>Rev9</generator>
	<item>
		<title>Re: Rules Driven UI using WF</title>
		<description>
			<![CDATA[Great screencast! <br>
<br>
Now I finally understand what WF does.... All this time I've been mystified to what it does new or how it does it&nbsp;differently, and only found the Microsoft articles on the subject even more confusing.
<br>
<br>
This screencast is a great introduction to the subject, because it shows you just how amazingly powerful WF can be... No more rolling out new applications when a single algorithm or constant piece of data changes, instead just login, update the database and
 your done! Amazing and powerful. <br>
<br>
Thank you.<p>posted by UnoriginalGuy</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632880994650000000</link>
		<pubDate>Mon, 10 Jul 2006 03:37:45 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632880994650000000</guid>
		<dc:creator>UnoriginalGuy</dc:creator>
	</item>
	<item>
		<title>Re: Rules Driven UI using WF</title>
		<description>
			<![CDATA[
<p>Thanks for this screencast. Whilst the summary indicates the separation of UI from business rules as a benefit, the demo hasn't taken advantage of it. Perhaps a demo where the rules engine interacts with an object which is bound to the UI would be a better
 scenario. This could better demonstrate the separation of business logic from the UI. Additionally, the Rules could be applied to an object in a web app, web service or windows UI perhaps solving the issue: I need to apply the same business/validation rules
 in the UI and in the middle teir.</p>
<p>PS. Perhaps I should not criticise and do it myself <img src='http://ecn.channel9.msdn.com/o9/content/images/emoticons/emotion-5.gif' alt='Wink' /></p>
<p>posted by Beep</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632883775850000000</link>
		<pubDate>Thu, 13 Jul 2006 08:53:05 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632883775850000000</guid>
		<dc:creator>Beep</dc:creator>
	</item>
	<item>
		<title>Re: Rules Driven UI using WF</title>
		<description>
			<![CDATA[Beep,<br>
<br>
If you want to put together a similar demo, be sure to submit it to <a href="http://wf.netfx3.com">
http://wf.netfx3.com</a>, and I'll make sure that it gets up there.<br>
<br>
matt<p>posted by mwink</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632884179050000000</link>
		<pubDate>Thu, 13 Jul 2006 20:05:05 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632884179050000000</guid>
		<dc:creator>mwink</dc:creator>
	</item>
	<item>
		<title>Re: Rules Driven UI using WF</title>
		<description>
			<![CDATA[ok. I like WF. The demo was pretty clear.<br>
<br>
However - hardcoding prices of products makes it extremely difficult to maintain.<br>
<br>
Hence, the demo is completely unrealistic.<br>
<br>
I this what WF expects us to do?<br>
<br>
<br>
<p>posted by christianlott</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632895232030000000</link>
		<pubDate>Wed, 26 Jul 2006 15:06:43 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632895232030000000</guid>
		<dc:creator>christianlott</dc:creator>
	</item>
	<item>
		<title>Re: Rules Driven UI using WF</title>
		<description>
			<![CDATA[
<p>Hi, christianlott,</p>
<p>I am glad you like WF and the demo and thanks for the feedback. Please note that the sample is for demonstration purposes only to show you how you can leverage WF rules to drive the business logic of a windows form application. WF recommends that you model
 your application to fit your business needs and if hardcoding the items' prices doesn't meet your needs then you can pursue other options. One option is to create or reuse an internal structure and the rules can lookup values from this structure and manipulate
 the UI controls accordingly. Hope this helps.</p>
<p>Thanks, --Moustafa</p>
<p>posted by moustafak</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632895341580000000</link>
		<pubDate>Wed, 26 Jul 2006 18:09:18 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632895341580000000</guid>
		<dc:creator>moustafak</dc:creator>
	</item>
	<item>
		<title>Re: Rules Driven UI using WF</title>
		<description>
			<![CDATA[Thanks Moustafa.<br>
<p>posted by christianlott</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632896160690000000</link>
		<pubDate>Thu, 27 Jul 2006 16:54:29 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632896160690000000</guid>
		<dc:creator>christianlott</dc:creator>
	</item>
	<item>
		<title>Re: Rules Driven UI using WF</title>
		<description>
			<![CDATA[This is good, but I agree with Beep in that what's shown here isn't really practical for a production application. I totally understand the idea of presenting something that is simple as an introduction, but I think it should at least be mentioned in the
 demo.<br>
<br>
I have some larger concerns/questions about the included rules editor and the extensibility of the rules execution model shown. I woked on a large winforms application last year for which we developed a custom validation framework. This framework was similiar
 to what's shown in this screencast, but our rules were almost <i>always</i> too complex to be evaluate with only a single If/Else condition. Our rules usually required broader knowledge of the current state of the application (often beyond the current screen)
 and would often contain quite a bit of logic.<br>
<br>
The very fact that the rules are complex, of course, is why it's useful to separate them from the rest of the application. The
<i>real</i> value comes when you create rules that are reusable, and rules that are written directly against a particular UI are not going to be reusable. But I love the idea of having a rules config editor to help you wire up custom rules along side simple
 conditional rules that can actually be coded entirely in the editor.<br>
<br>
I'd like to see a more in-depth screencast that demostrates how you can extend the WF model shown here to handle complex rules, executing against business objects, and requiring broader application state access. Ideally you can do this while keeping the actual
 UI code just as simple, and the rules reusable (so they can be used on another screen that access the same business objects).<br>
<br>
<p>posted by Seraph</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632898708680000000</link>
		<pubDate>Sun, 30 Jul 2006 15:41:08 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632898708680000000</guid>
		<dc:creator>Seraph</dc:creator>
	</item>
	<item>
		<title>Re: Rules Driven UI using WF</title>
		<description>
			<![CDATA[
<div>I am glad MS is having these WF screencasts. I agree with the other commenters&nbsp;that the demo doesn't show a good real-world example though.
<br>
<br>
Another problem is the lack of proper separation of the&nbsp;layers: it's tying business-logic directly to the UI, making it brittle and the rules are not reusable (in other forms in the same app or in different apps). I should have an Order object, set up the Rules
 for that object and instead of manipulating the .text property of the winform controls directly, I should be altering the instance of the&nbsp;Order object that the Order Entry form is presenting (through databinding). Then, due to this separation, the same validation
 rules and behaviors could be applied to other presentation layers (ASP.NET, CompactFramework) without&nbsp;duplicating all the rules (our apps have a TON of rules that can vary by customer).
<br>
<br>
If this can be done, then <em>that</em> is the type of screencasts we should be seeing, a best-practices demo, without hardcoded prices and without tying the business logic directly to the UI, but to the underlying objects to which the UI is bound. Otherwise,
 I'm sure many programmers will end up incorrectly thinking that the way this webcast presents it is the best practice or if they recognize that it isn't, they won't have an example of what a best-practice example does look like.<br>
<br>
There should be a set of validation rules you set up for the Model, and the UI should have a way to hook into the results of the validation tests. Ideally the WinForms/ASP.NET/CF controls would all know how to get the message from the Validation engine that
 the text entered is incorrect with the ability to have a user-defined style applied to the control (red borders, red background, red text or a red dot next to the edit/check box or set up an event handler for ValidationFailed event) with a float-over hint
 that ties back to the error message in the user's appropriate language. Then you could databind a label to the validation engine results so it could show all the failures on the form&nbsp;in User-readable text format as defined in the Validation Engine of the Business
 Rules layer, but definitely not the Presentation layer. <br>
<br>
For an example of a framework that does this, go here <a href="http://www.oakleafsd.com/">
http://www.oakleafsd.com/</a>&nbsp;and check out MereMortals. While I've not used it, the online screen casts show how the exact same validation rules are used for both the Windows front end as well as the asp.net front end --<em> coded once</em>. The problem with
 their approach is that they have to subclass all of the winforms/webforms controls to be able to support the extra features. It would be nice to see something like MM's features native to .NET and could be used in different ways by various presentation layers.
 The validation error messages should be easily localizable.<br>
<br>
The direction we should be seeing from MS is toward finding the best ways to properly separate the layers so that even more code is reusable. The presentation layer should have as little code as humanly possible. Then when we want to switch to Avalon or some
 other future front end technology, there is very little that needs to be done, if we want to create a simplified version to run on CF, it should be simple.
<br>
<br>
Let's say I add a new restriction to the Order&nbsp;object, I should be able to add it only to the validation engine then WebForms, Winforms, Avalon and CF forms should all automatically present the validation error to the user without any coding
<em>or even recompiling</em> of the presentation layer on any form that attempts to post bad data.<br>
<br>
For the best developer experience, the business objects could be a part of an object persistence framework which would allow me to pass an Order object to the form, the form would have a holder for that Order object and then other controls would use that holder
 as their datasource, with the ability to reference the object properties as a part of what they are bound to. If you look at Delphi's ECO (Enterprise Core Objects) it allows for this, with substantially more databinding ability than .NET. It allows you to
 write OCL (Object Contraint Language -- which MS was part of developing the standards for, along with Rational) which can do if/then and other control structures, type conversions, user-defined calls, etc&nbsp;to define what is shown in a control. A grid on the
 order form would then have the grid datasource set to &quot;thisOrder.OrderDetails&quot; and with each column able to reference the different properties/fields of the OrderDetail objects in the OrderDetails collection found on the Order object.<br>
<br>
Now that Borland sold Delphi (and it's other IDEs), it'd be great if MS would buy or license the ECO (which is written in .NET) technology from DevCo (the buyer) and make it core to the .NET developer experience.<br>
<br>
Sorry this is&nbsp;so long! <img src='http://ecn.channel9.msdn.com/o9/content/images/emoticons/emotion-1.gif' alt='Smiley' /></div>
<p>posted by nuclearspike</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632924029210000000</link>
		<pubDate>Mon, 28 Aug 2006 23:02:01 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c632924029210000000</guid>
		<dc:creator>nuclearspike</dc:creator>
	</item>
	<item>
		<title>Re: Rules Driven UI using WF</title>
		<description>
			<![CDATA[i've a similar windows form application where i am calling this rules set editor in dialog box. i want to edit &amp; create new rules using this &amp; also save this to database.<br>
i am successful in retrieving the ruleset from database &amp; displaying it in rule set editor. but i am not able to save changes made to this rule set using editor.<br>
how to save to SQL database?<p>posted by poonamb</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c633468691930000000</link>
		<pubDate>Tue, 20 May 2008 08:33:13 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c633468691930000000</guid>
		<dc:creator>poonamb</dc:creator>
	</item>
	<item>
		<title>Re: Rules Driven UI using WF</title>
		<description>
			<![CDATA[I agree with Seraph.&nbsp; I understand each group within Microsoft putting out demos for each .Net feature and keeping them simle to get concepts across.&nbsp; It would be nice to see a small amount of work go into showing how to do it correctly with the proper
 separation.&nbsp; This could be done with one field as an example if time and effort is limited.&nbsp; I have yet to see a good reference application written using a mixture of these concepts, features, and practices in a single example.&nbsp; This is especially true for
 client applications.&nbsp; There are web examples-a-plenty but from the current emphasis I'm guessing Windows.Forms is dead.&nbsp; It looks like either Microsoft employees don't know how to do this or don't want anyone&nbsp;else to know.&nbsp; Thus we end up doomed to&nbsp;salvage&nbsp;projects
 with countless problems that may have been avoided with a good example of how to do it right.<p>posted by eeevans7</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c633612483170000000</link>
		<pubDate>Sun, 02 Nov 2008 18:45:17 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/mwink/Rules-Driven-UI-using-WF#c633612483170000000</guid>
		<dc:creator>eeevans7</dc:creator>
	</item>
</channel>
</rss>