Rants Tagged with “Training”
1 2 3 > >> (Total Pages: 3/Total Results: 21)
During the three days of MIX 10, AgiliTrain will be giving away a seat per day of the event to people who follow them on Twitter (@AgiliTrain).
To qualify, you must be a follower of the AgiliTrain twitter account by the end of of each day at MIX (by 8pm PST). For each winner, they receive free entrance to any Silverlight Course of their choice that is given by AgiliTrain.
Follow @AgiliTrain now to qualify!
We have made some adjustments in the Fall/Winter schedule for the Silverlight Tour. As Fall is often our busiest time of year, we decided to move some dates around to not conflict with the PDC and other conferences. Here is the new Schedule for the Silverlight Tour and the Advanced Silverlight Workshop:
Silverlight Tour
Advanced Silverlight Workshop
Note that by attending the Silverlight Tour workshop, you not only receive a full version of Telerik's RadControls for Silverlight but also get a discount to attend the Advanced Silverlight Workshop.
We are very proud to announce that AgiliTrain and Rachel Appel are partnering to present a series of public classes on the next generation of web development. Rachel will be teaching two new courses for AgiliTrain on web development:
- The MVC Tour: A 3-day training session that features an in depth look at MVC – the Model/View/Controller pattern as implemented in ASP.NET.
- The jQuery Tour: A 3-day jQuery workshop that enables developers new to jQuery development to increase their knowledge and gain familiarity with the jQuery libraries, plug-ins and ecosystem.
For those not in the know, Rachel has been working as a mentor, instructor, software developer, architect and DBA for nearly 20 years. During her career, Rachel has worked with a variety of languages, technologies and systems and has contributed to projects of all sizes including large scale enterprise applications at some of the world’s leading companies. Rachel’s expertise lies within developing solutions that align business and technology using the Microsoft .NET family of products, particularly ASP.NET & SQL Server. She is also an ASP.NET MVP, ASPInsider and holds the Microsoft Certified Trainer, MCAD & MCSD certifications.
The workshops will be held in several cities including:
The MVC Tour (http://mvctour.com):
- Sep 14-16, 2009 in Seattle, WA
- Nov 2-4, 2009 in Philadelphia, PA
- Jan 11-13, 2010 in Dallas, TX
The jQuery Tour (http://jquerytour.com):
- Aug 24-26, 2009 in Philadelphia, PA
- Oct 5-7, 2009 in Dallas, TX
- Dec 7-9, 2009 in Seattle, WA
Get your seats while they last. Only sixteen students per date will be accepted.
In cooperation with Accentient, AgiliTrain is now bringing Richard Hundhausen's Agile Database Techniques workshop to a city near you. This three-day course will give students a deep dive into managing SQL Server database development in an agile environment. From understanding how VSTS supports an agile database development lifecycle, to creating and configuring database projects, as well as automating the building and deploying of SQL Server databases, you’ll walk away knowing how to do it all.
The dates for the workshop are coming up soon. The workshop will take place:
- July 20-22nd, 2009 - Seattle WA
- August 3-5th, 2009 - Atlanta, GA
- September 7-9th, 2009 - Chicago, IL
The workshop is limited to the first sixteen students so register before the seats are gone!
You only have one week left to register for our innaugural Advanced Silverlight Workshop. On March 30-31st, we will be holding the class in Atlanta, GA. This new class covers the material that you need to build large, robust applications using Silverlight 2 or 3. The workshop includes coverage of:
- Custom Control and Custom Layout Control Development.
- Testing Your Silverlight Applications.
- Securing Web Services.
- Sharing Entities Between Client and Server.
- Implementing Model-View-ViewModel (MVVM) in Silverlight
- Using Inversion of Control Containers with Silverlight
- Composing Large Applications using Prism
If you are headed into a Silverlight project and want to be prepared to successfully architect and design your solution, this is the class for you. For more information visit:
https://agilitrain.com/workshop/info/Advanced_Silverlight
The Silverlight Tour is happy to announce that we now include Silverlight 3 features in our normal Silverlight Tour schedule. Our first Silverlight 3 class will be the Chicago, IL class that takes place on April 6-8th. If you are ready to learn all there is to know about Silverlight 2 and 3, the Silverlight Tour is the right place to be. The new content includes changes and improvements to the platform including:
- The Out-of-Browser experience.
- Use Pixel Shaders and 3D transformations.
- Build Behaviors.
- Styling Improvements including Merge Dictionaries and Based-on Styles
- Data Validation using the Control Model
- Working with Binary XML
- Using the new Bitmap APIs
- Blend 3 Preview Coverage
For more information, visit:
https://agilitrain.com/workshop/info/silverlight_tour_workshop
Coming up on March 30-31st, we will be holding our first Advanced Silverlight Workshop in Atlanta. This new class expands on the Silverlight Tour Workshop. This new class requires that students have a working knowledge of Silverlight and teaches the next level of Silverlight design, development and architecture.
The class covers:
Building Composite Applications
- Separating Concerns
- View-Model-ViewModel
- Composition with Prism
- Working with Large Teams
TDD with Silverlight
- Using the Test Framework
- Unit Testing
- Integration Testing
- Build Integration
Managing Data
- Picking a Data Layer
- Change Management
- Security of Data in Silverlight
- Integration with Existing Data Layers
Custom Controls
- Why a Custom Control
- Derivation Schemes
- Custom Containers
- Control Templates
- Supporting Blend
Visit the AgiliTrain website to register or just hold a seat for the upcoming class.
In Part 1 and Part 2 of this series, I talked about why I used MVC to create my new venture and how I implemented MVC. In this third part, I will talk about data entry and validation.
When I talk to a lot of people about MVC they point to jQuery and other frameworks as the reason they want to use MVC. Certainly ASP.NET MVC allows us to program our views much closer to the HTTP protocol and the HTML DOM which means that scripting frameworks are easier. This means that you can do some amazing things with these tools in ASP.NET MVC without having to fit a square peg in a round hole.
But for me I decided to not do much AJAX at all. This site has two goals: communicating information about classes and collection data for registration. Lots of AJAX would look cool but isn't necessary. In my case I simply decided to do all server-side data validation. The only place I used jQuery at all was to do some quick pane switching on one of the entry screens.
In Part 2 I explained that I created Model classes that represented the data that was going down to the Views. I decided to use those models to handle the validation. In the Views you can use ValidationMessage objects to show messages when validation fails. For example, a shortened version of one of my instructor data entry pages looks like this:
<% using (Html.BeginForm())
{ %>
<div>Your Name</div>
<div><%= Html.TextBox("name") %>
<%= Html.ValidationMessage("name") %></div>
...
<div><%= Html.SubmitButton("submit", "Save") %></div>
<% } %>
You can see that I am showing a TextBox then a ValidationMessage right after it. The idea here is that when the form is posted, if it fails validation, we'll return to it and show any validation errors directly in this form.
One common pattern I saw in some examples was to use to do the validation on the server in the Controller:
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult ConfirmAccount(string username,
string password,
string id)
{
// Basic parameter validation
if (String.IsNullOrEmpty(username))
{
ModelState.AddModelError("username",
"You must specify a username.");
}
if (String.IsNullOrEmpty(password))
{
ModelState.AddModelError("password",
"You must specify a password.");
}
if (ViewData.ModelState.IsValid)
{
//...
}
// If we get this far, display the form with errors
return View()
}
In this pattern the ModelState can be used to add errors to be displayed then check to see if the ModelState is valid before proceeding. I didn't like this style as it puts too much validation in the Controller. I sensed that if I had a model, the model should be responsible for validation. I would have preferred to have a loose coupling between the model and controller, but for brevity I sacrificed perfection and added a method to the Models called ValidateModel that took the ModelState:
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Register(RegisterPostData data)
{
data.ValidateModel(ViewData.ModelState);
if (ViewData.ModelState.IsValid)
{
// ...
}
// If we get this far, display the form with errors
return View()
}
I do the same work I would do in the Controller method but this style lets me encapsulate it to validate it anywhere I use the model. For example:
public class RegisterPostData
{
public void ValidateModel(ModelStateDictionary state)
{
RequiredField(state, this.FirstName,
"firstname", "First Name");
RequiredField(state, this.LastName,
"lastname", "Last Name");
RequiredField(state, this.Address1,
"address1", "Address");
RequiredField(state, this.CityTown,
"citytown", "City/Town");
RequiredField(state, this.StateProvince,
"stateprovince", "State/Province");
RequiredField(state, this.PostalCode,
"postalcode", "PostalCode");
RequiredField(state, this.Country,
"country", "Country");
}
protected void RequiredField(ModelStateDictionary state,
string data,
string name,
string desc)
{
if (String.IsNullOrEmpty(data))
{
state.AddModelError(name,
string.Format("You must specify a {0}.", desc));
}
}
// ...
}
Validating the Model is not necessarily this simple, it also might involve more complex validation. For example, in my RegistrationModel I have to validate that either a valid a Credit Card number or Corporate PO information is supplied. Your validation may be as simple or as complex as you require. One small hint that is useful is that sometimes you have validation that is more about a genreal validation error (e.g. not validation on a single field). In that case when you call AddModelError you can specify "_FORM" instead of a field name and it will show up as a form-level error (using the ValidationSummary construct).
Again, I couild do double duty and have the validation performed at both the client and server and it would be slicker but with my short time-frame I decided to implement the important side first. I will likely revisit the pages and add client-side validation at some point. Luckily MVC makes these sorts of refactoring especially simple since the View is so separated from the rest of the logic.
In Part 1 of this series, I talked about why I used MVC to create my new venture. In this second part, I will talk about how I implemented MVC.
Stubbing out the Site
When I decided to implement MVC, I was very new to it so there is some code in the site that reflects that. The later code and the code I've gotten around to refactoring is much cleaner, but working code is working code.
My first step was to create a couple controllers for the first sections I knew I wanted to implement. I started with the Home and Workshop areas. One of my favorite features of the Visual Studio support is that I can create controllers, then stub out actions and views quickly. Once you have a controller and an action, you can simply right-click and use the context menu to create the view for an action:
Better URLs
I was using the standard routes that the template gave me (<Controller>/<Action>/<id>) and for what I was doing that was fine. I have considered replacing it at some point but it never became important.
One of my pet peeves though is that it becomes easy to create an action that takes a primary key value (e.g. WorkshopID). That would end up with URI's like:
http://agilitrain.com/Workshop/Info/15
But that is just as bad as using a query string as far as I am concerned. Not only does the user not care about the key value but it doesn't add value (to the user or search engines). So I used strings as my IDs. For example, my Workshop Info action looks like this;
public ActionResult Info(string id)
{
}
By using a string I could just use the name of the workshop to get better URI's (though that means searching by name in the database, but the number of workshops is going to be so small that the heavier weight on the database won't matter in the big picture). My string based URI's were better:
http://agilitrain.com/Workshop/Info/Silverlight%20Tour%20Workshop
While this is better, it is still not great. The URL encoding replaces the spaces with the "%20" which makes it harder to read. I relented and encoded/decoded my own IDs with a little piece of code that simply replaced all spaces with underlines. If you choose this approach, make sure you do the replacement on both sides (e.g. replace them when you create ActionLinks and reverse it in the Actions). My resulting URI's were much more reasonable:
http://agilitrain.com/Workshop/Info/Silverlight_Tour_Workshop
What is the Model in MVC?
The last thing I'll share in this part of the article is my initial thoughts about how ASP.NET MVC handles models. I could see early on that a common way to share information between the controller and the view was to use ViewData. ViewData is a structure that is passed on to the View and is a simple dictionary lookup. For example, to set the page, I used a "Title" parameter in every action:
ViewData["Title"] = "Login Page";
This works but for most of your data this isn't a great method. In early pages I peppered them with several different pieces of ViewData but that meant on my pages I needed to do a lot of casting as well as not having a single unit of data I could test my controller and views with.
Instead you can also return the model for a view directly by returning a View from your controller and including it as a parameter:
public ActionResult Login()
{
return View(someObject);
}
So what should you return as the model? Early articles I saw were returning domain object (e.g. entities directly from the database). This works but it makes it harder to separate other functionality and mix data. What I was urged to do instead was create a model for the need. For example, on my Workshop info page, I needed information about the workshop, upcoming events and some information about the current attendee. So instead I created a simple model class:
public class WorkshopInfo
{
public Workshop Workshop { get; set; }
public Attendee Attendee { get; set; }
public Event[] Events { get; set; }
}
This allows me to setup all the data I need then pass it to view in one step. This works much better but there was still some casting. To get around this you should use a typed view:
public partial class Info : ViewPage<WorkshopInfo>
{
}
Or if you're using the new MVC RC's ability to have views without code-behind:
<%@ Language="C#"
Inherits="System.Web.Mvc.ViewPage<AgiliTrain.Data.Workshop>" %>
This allowed me to get the data into my views, but I when I was ooking at the sparse documentation it caused me to thrash a bit with how to handle data entry pages (e.g. Login). The cool thing is that you can specify in the controller two actions (e.g. methods) for a view. The trick is to specify what HTTP verbs are going to be used for which methods. For example:
[AcceptVerbs(HttpVerbs.Get)]
public ActionResult Login()
{
// ...
}
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Login(string username, string password,
bool rememberMe, string returnUrl)
{
// ...
}
For my login action, the first method is called when the login URL is used, but when I post-back from the Login page the second method is used. One thing you should notice is the parameters of the 2nd method. The ASP.NET MVC framework attempts to match the form input's to a list of parameters. When I coded the Login page that made a lot of sense and made it simple...but of course when I got to larger forms this became a bad idea. You can imagine some of the actions having a huge number of parameters which is hard to maintain.
In fact if we track back to the Model idea, its the same solution. If we define a model that has types for the data in our forms, we can use it as the parameter to the POST method. The ASP.NET MVC framework will look at the post variables and create the type and attempt to set the values of the new type. For example our LoginInfo model should look like this:
public class LoginInfo
{
public string UserName { get; set; }
public string Password { get; set; }
public bool RememberMe { get; set; }
public string ReturnUrl { get; set; }
}
Then our login method can take that structure and the framework will handle setting and getting the data for us:
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Login(LoginInfo model)
{
// ...
}
In many cases (though Login isn't one of them) you could fill in this model and send to the view in the GET so that you have the initial data for the form, not just retrieving from the POST. In fact, I have the model handle the validation for me so I can use the same model in multiple places and have the data inside it be valid for my data entry screens.
In the next part of this article I will delve further in the data entry screens on how the model is used to fill in data.
I am very happy to announce that we have finally migrated our training business to a new web venture called "AgiliTrain".
AgiliTrain will run the Silverlight Tour as well as other workshops. I can announce today three new courses:
We also plan on updating the Silverlight Workshop after MIX (like we've done every year) to include the newest changes to the platform.
AgiliTrain is my venture, so the care and feeding of the Silverlight Tour hasn't changed at all, it has just given me the ability to more easily create new courses for developers. In the coming months you should also see courses by other subject matter experts appear on the site.
If you have any questions about this, please let me know!
