Tuesday, April 10, 2007
HowTo: Application Block Software Factory (ABSF) Part III: An example
After an introduction to ABSF and a explanation about providers, here you have an example of how an application block and a provider library can be created. What I did was to take snapshots of the solution after executing each recipe:
1. New Animal Application Block
2. New Provider Factory and Base 'Animal'
3. New Provider (Typed) 'Dog'
4. New Provider (Untyped) 'Monkey'
5. New Design-Time Base Provider Node 'AnimalNode'
6. New Design-Time Provider Node 'DogNode'
7. New Provider Library
8. New Provider (Typed) 'Cat'
9. New Design-Time Provider Node 'CatNode'
The example is based on the Animal Application Block of Brian Button. Brian and Tom did a series of webcasts explaining the Entlib Core and Design-Time creating an Animal Application Block. You can download the webcasts from here and here.
The idea is that you can open each snapshot and take a look at what stuff is created after executing each recipe. In order to build the snapshots, you will have to copy the Common.dll, Configuration.Design.dll and ObjectBuilder.dll to the lib folder of each snapshot. I recommend you to unzip the snapshots in a directory near the root (c:\) because of the path length restriction (you won't be able to build the snapshots if the path is longer than 248 characters)
Finally here you have the link to the snapshots!
Enjoy!
Friday, April 06, 2007
Enterprise Library 3.0 Released!
I've been part of this excited project mostly developing the Application Block Software Factory (ABSF) and some parts of the Validation Application Block (VAB) (which core and intergation support was developed by Fernando). I want to thanks all to let me be part of this great experience and learn a lot from this spectacular people.
You can download it, start using it and provide feedback! Here you have the links:
Download: http://www.microsoft.com/downloads/details.aspx?FamilyID=62ef5f79-daf2-43af-9897-d926f03b9e60&displaylang=en
Codeplex community site: http://www.codeplex.com/entlib
Tom Hollander's Blog: http://blogs.msdn.com/tomholl/
Olaf's Blog: http://bloggingabout.net/blogs/olaf
Enjoy!
Tuesday, March 20, 2007
HowTo: Application Block Software Factory (ABSF) Part II: Providers
This is the second part of this post. In this one I will tell you what you need to know when you are creating a new Provider (Typed or Untyped).
When you are creating a new provider for your own block you will have to specify many things (when a well known provider for an existent block is being created we already know the provider hierarchy so we don't need to ask you :)):
1. Provider Interface
2. Provider base class
3. Configuration class
There are basically two kinds of providers: Typed and Untyped.
Typed Providers: The typed providers have strongly typed configuration. This means that you have to specify every configuration property in the Configuration Class and Design-Time Class.
(1) and (2) could be the same but you will probably want to be different in order to separate the Interface from its implementation. The (3) is the base class for all configuration object in the same provider hierarchy. It provides the abstract message protocol to create specific configuration objects.
UnTyped Providers: All untyped providers have the same configuration class and it's based on key/value pairs (as strings). So the provider will receive a Name Value Collection and it will have to parse manually the values.
So if you want to create Providers with a very little effort you will probably need an Untyped Provider but if you want a fully design-time user experience you will need a Typed Provider.
Friday, March 16, 2007
Validating inputs using Validation Application Block and XmlHttpRequest (Part II): The code!
Someone has left me a comment in my previous post about this topic asking for the code to take a look at the solution. So I think that instead of making you waiting for a detailed explanation of the solution you could take a look at it and see if it's useful for some specific scenarios you may be interested:
There is the code. The zip file contains the Proxy implementation, the JS function and the TypeDescriptor infrastructure you need to make the VAB get the html control value.
Of course this is draft code, and it's only for demo purposes. I hope you enjoy it and provide some feedback!
An example of how to use the Client Validation could be:
<asp:TextBox ID="TextBox1" runat="server" />
<cc2:ClientPropertyProxyValidator
ID="ClientPropertyProxyValidator1" runat="server"
ControlToValidate="lastNameTextBox" PropertyName="LastName"
RulesetName="RuleSetA"
SourceTypeName="ValidationQuickStart.BusinessEntities.Customer" />
The example was taken from the Validation Quickstarts and you can realize that you only have to change the control declaration!! (PropertyProxyValidator -> ClientPropertyProxyValidator)
Thursday, February 22, 2007
HowTo: Application Block Software Factory (ABSF) Part I
The Guidance Package included in the Enterprise Library V3 includes support for creating your own libray and application block. Here is the difference among them:
- Application Block: It contains a Provider Hierarchy (created using the "New Provider Library and Base" recipe) and may or not contain one or more provider or implementations. The provider hierarchy is the base infrastructure that is needed to create an abstraction. Then you are able to create many providers (or services) that can be used to solve the concrete problems. For example in the Logging Application Block one abstraction is the Trace Listener and the Providers are the WMI Trace Listener, the email Trace Listener, the text file Trace Listener, etc. The provider library defines the base structure that the providers need to be used without depending on the implementation because for example you ask for a name provider, say "MyTransactionTraceListener" and you don't know where it will definitely log the entries you send to it.
- Provider Library: It contains only implementations of an existent Application Block. It must reference the Application Block project (or assembly) and it should only implement new Providers. It is a mechanism to extend existent Application Blocks without modifying them.
I will use the Brian's Animal Application Block example. Brian did some webcasts explaining how to develop a new Application Block and its design-time support. Here you have the links:
http://www.agileprogrammer.com/oneagilecoder/archive/2006/02/09/11359.aspx
The first decision you have to make when you are using the ABSF is if you want to create a new Application Block or you want to extend an existent one (You can extend your own App Blocks or the Enterprise Library existent ones).
If you want to create a new App Block, the first recipe you should execute should be the "New Provider Library and Base" and decide if you will have many implementations of the abstraction or only one. It creates many files for you. Lets take a short look at them (Following the example, the Provider name is "Animal"):
- Interface Provider (IAnimal.cs): It allows to use the abstraction without being coupled to the implementation.
- Base class Provider (Animal.cs):
- Factory (AnimalFactory.cs): It's the facade to get the providers. It uses the InstanceFactory (AnimalInstanceFactory.cs) to create the instances.
- Configuration Data (AnimalData.cs): Base class for all configuration objects of the Provider hierarchy.
- Custom Configuration Data (CustomAnimalData.cs): The configuration of custom provider (UnType Providers) is quite different from the configuration of the Typed Providers. This configuration class should be used for your new custom providers.
- Appliction Blocks Settings: It represents the section that you will use to configure your application block. It's a Partial class because it's supposed to be extended by partial classes. Every new Provider Hierarchy will add a new partial class adding the Provider Hierarchy configuration structure.
The next step is to create the Providers (Typed or Untyped) and wire them to the Provider Hierarchy. I will post this in a future post. See you!
Validating inputs using Validation Application Block and XmlHttpRequest (Part I)
Enterprise Library V3 already includes Asp.Net Validation support using the Validation Application Block (VAB). You can download it and try the quickstarts from Codeplex. Here you have a Quickstart fragment showing how to use the PropertyProxyValidator to validate a TextBox control:
<asp:TextBox ID="dateOfBirthTextBox" runat="server" />
<cc1:PropertyProxyValidator ID="dateOfBirthValidator" runat="server" ControlToValidate="dateOfBirthTextBox"
OnValueConvert="dateOfBirthValidator_ValueConvert" PropertyName="DateOfBirth"
RulesetName="RuleSetA" SourceTypeName="ValidationQuickStart.BusinessEntities.Customer" />
Then the IsValid property is used when the user submits the form and all input are validated using the server side configuration (this is the attributes metadata in the domain objects or the configuration file definition). But what about the client validation that provides the rest of existent Asp.Net's validators? They use fixed or custom (provided by the user) javascript code to perform the validation and the problem is that you have to duplicate the same logic in both C# and JS languages.
I don't have the answer to how to perform a fully client validation but at least I developed a first approach to the solution using XmlHttpRequest. This solution allows you to validate each Input when it loses focus and shows the user the errors before continuing with the next input:
The solution: I extended the PropertyProxyValidator and I added to it the CustomValidator behavior. The JS function is fixed and it sends the XmlHttpRequest to the server specifying the following 3 things:
1. This is a "client side" validation.
2. The value to validate.
3. The validator id.
In the OnLoad event I check the (1) and (3) parameters. Then I execute the base EvaluateIsValid method and write the response containing the validation result and the error message to be shown. The tricky part is how to provide the GetControlValidationValue(string name) because it gets the value from the property defined in the ValidatorPropertyAttribute on the Control to validate. This property could be different in each control and should be set with the value to validate (2). So with the help of reflector and kzu we realized that in the end the TypeDescriptor features are being used to get the Property value to validate. In short we registered a TypeDescriptionProvider to return the value to validate (2) before invoking the validation and we removed this after that.
I think this was too much for this post. I will continue posting more details of the the solution in future posts so stay tuned if you are interested in!
Sunday, January 14, 2007
Application Block Software Factory
I have been working as part of the Enterprise Library V3 Team in
- Create your new Block
- Create a Provider Hierarchy (this is the base types for your new providers)
- Create you Providers and its configuration
- Create the design-time support for your new block
- Extend the new block creating a Provider Library
