K2 [blackpearl] is the newest version of workflow software from SourceCode. I believe it can be a valuable tool for developing line of business applications, specifially solutions that involve routing and tracking work and information between people. While I haven't built a production solution in blackpearl yet, I think I have a fairly good background from which to evaluate the product. I have experience building process applications in a completely custom fashion, I have some experience with Windows Workflow Foundation (WF) and SharePoint, and I have built a production application using the previous K2.net 2003 product. I recently attended a partner training event to get some more hands on experience with blackpearl and speak with K2 folks who really know the product. This evaluation serves as a mental exercise for me and also information for those who may be considering blackpearl.
The Basics of a Workflow Application
Applications that improve business processes usually have some basic concepts in common: users, tasks, data, rules. Users are assigned tasks to process data. A simple example: Employees (users) submit purchase orders (data) for approval. Depending on the cost of the purchase and the department the requester works in (rules), a manager has to approve it (task).
So how do you build a system like this? Obviously you're going to start with requirements gathering and in a business process app (any app really), that can be one of the biggest challenges. I think blackpearl can help you early on in the process. I'm a big believer in early prototyping. Being able to mock up an early system that walks users through the functionality is much more effective in fleshing out requirements for the final solution than simply talking with the business and drawing up how the app should work. blackpearl allows you to rapidly build out workflows so you can walk users the flow of tasks that each user will get, at least in a rudimentary fashion, early on in the process. I'm intrigued by one of the new built in UI options blackpearl introduces. It auto-generates a tabular-label/textbox-style aspx page for the tasks. The final solution will no doubt involve complex business logic and a fancy user interface and lots of other goodies, but to get moving you should be able to get a simple prototype up and running writing little or no code.
Visual Designer
I'm a visual person. I think you have to be to understand complex business process applicaitons. K2 blackpearl offers three different designers to model processes in: 1) Visio 2007 2) an ajax web-based designer 3) Visual Studio 2005 (and 2008 shortly, I think). The latter is great for developers. And the K2 marketing folks will tell you that the first two options enable your non-technical business analysts to design workflows. I'm not buying it, though. I don't see non-technical folks building out production workflows. Wizards and all, there are still too many blackpearl and technical details in a real world scenario that make this unlikely. I can see two ways this could be helpful, though. Business analysts can start with Visio to diagram a process which can later be "blackpearled" by developers, giving the process a jump start. Then, viewing in Viso, developers and business analysts can continue to refine the workflow by looking at it in a "common language". I haven't tried this yet, but it seems viable.
Looking at the alternative approaches, SharePoint workflos are WF-based and therefore give you a designer to work with. With a custom solution, you could use WF as your workflow engine and get design capabilities. However you have a lot of plumbing to build out.
Plumbing
Building a system that tracks tasks is non-trivial. In a custom solution, it most likely involves building a database table for tasks, writing code at write to and update the tables as events occur, properly assigning to the tasks to the correct user(s), notifying the users of their tasks, and allowing them to manage them. It doesn't sound extremely difficult, right? But like I said, it's certainly non-trivial. WF gives you a good framework to build on and some basic service implementations for things like persistence via SQL Server, but you're still going to have to build out a host process, define your workflow related classes and wire everything up. And unless you're really forward thinking, you have to do this for every application you build.
SharePoint workflows have the concept of using SharePoint lists for tasks. These tasks are scoped to a list within a site and without some custom work, it is difficult to create an aggregate view of tasks from various sites. Another interesting point is that by default SharePoint deletes completed tasks after 60 days to improve performance. You can turn that "feature" off but the onus is on you to archive task history, which could be a necessary requirement for compliance. You may want to do this with a blackpearl solution, as well, but the underlying database is built in a way that you don't need to.
Taking tasks a step further, after getting through the basics, you have to write even more code to monitor the tasks and react to tasks that have not been acted on in certain timeframe. In K2 blackpearl this functionality can be defined in an Escalation. You can specify rules like "if this task isn't completed in 24 hours, send an email every day" or "if this task isn't completed by a certain date specified in my business data, move to another point in the workflow". Certainly non-trivial coding here.
We haven't even touched on how tasks are assigned or how you know when tasks are completed yet, either. Simple assignment isn't that hard, right? Just an AssignedToUserID column in my Task table, right? Well for one applicaiton that might be ok. But what if your process is more complicated. "This purchase order needs to be approved by two of the managers in the Accounting Department." blackpearl has the concept of Destinations, Slots, and Succeeding Rules for each activity, or milestone, in a workflow that allows you to easily define scenarios like this.
Additional Benefits
K2 blackpearl has additional benefits over a SharePoint or custom solution including versioning support, robust logging and exception handling, and MSBuild integration. And K2 blackpearl also offers addtional advanced features. Smart Objects provide the ability to build facades that encapsulate multiple backend datasources for use in workflows and reporting. Another interesting feature is the Event Bus, which allows you to register events and build out an event driven architecture. These concepts are interesting, but I'm reserving judgement until I have a chance to realy work with them. I may try to expand on the benefits in these areas in future posts.
Summary
In the spirit of full disclosure, I have to point out that Clarity is a K2 partner, so it would be easy to assume that I have an obligation to recommend blackpearl. However, we're not in the business of selling K2 licenses. We're in the business of serving our clients by building software solutions and their needs always come first. Writing and testing infrastructure code that manages workflows and tasks is not a activity worth spending time and money on. K2 blackpearl provides that framework, allowing us to focus on designing and building applications that solve the business problems at hand, enabling us to quickly deliver high quality process related solutions that meet their needs.
I wanted to share a few quick thoughts on Visual Studio Team Edition for Database Professionals. Over the past several months I’ve found this to be an invaluable tool. Aside from being a mouthful, the name is a little misleading as it implies that it is only targeted at DBAs. This is not the case. This component of the Visual Studio Team Suite is something that developers can use to gain productivity.
On most of the projects I’ve been involved in, developers are making changes to databases and a DBA may not even exist. Coordination of those changes during the development phase can be a challenge. Even more challenging can be the deployment of those changes to integration, testing, and production environments. VS DB Pro allows developers to track the database structure in a Visual Studio project, just like a class library. A project can be created from an existing database or a new project can be started. The main component of the tool is ability to perform a Schema Comparison, comparing one database or database project to another database. Developers can use the comparison to apply the changes to their local database, or to make changes to the project. I’ve found that this is very helpful for getting changes from one developer to another quickly. The integration with source control helps track your changes. Later in the application life cycle, developers and/or the operation team members can generate a script using the comparison to deploy changes to a test or production environment. In addition to schema comparison, there are other features the tool provides like refactoring and unit testing, which I haven’t used much of yet.
As always, you can’t beat good communication across a team as a key component of a successful project. However, I think that adding Visual Studio Team Edition for Database Professionals can make your project even more successful. I’ve got some further ideas about “best practices” for using the tool on a project and I’ll try to post those at a later date.
A couple notes for full disclosure: I’ve only used VS DB Pro with SQL Server 2005 databases and TFS source control so I can’t tell you about the experience beyond that. Also, I’ve never compared its feature set to that of other tools - I’ve simply taken it for granted as part of the Team Suite. And there are a few gotchas. For example, sometimes after getting latest from source control, even when clicking the “update schema” button, the local temp database doesn’t get updated and that can cause some problems. I’ll give MS a little break chalking this up to a first version of the tool (But it better work better in future releases!).
The other day I attended the Chicago VSTS Users Group meeting where the focus of the meeting was the Scrum methodology. Ed Chaltry from Centare Group led the meeting. He probably felt like he was defending Scrum instead of just presenting it as there was a lot of good lively discussion. It was a VSTS meeting, so a couple of tools that work with TFS Conchango and eScrum were demoed a bit. The emphasis was more on Scrum than the tools, however.
What is Scrum? Scrum is one the agile methodolgies of software development. Wikipedia has an overview here. I have a decent amount of experience working in an agile development model: small teams, including users, SMEs and QA early in the process, following an iterative timeline. Only once, though, have I worked on a project that truly ran under the Scrum methodology. After attending the user group the other day, I was reinspired to evaluate and share my take on Scrum.
The gist of my thoughts on Scrum? Scrum works well in some instances and should not be used in others. I think there are some things to take from Scrum and use and there are some things to get rid of. Some things make sense to me and some I don't Wow! That's genious! Okay, okay. I have more thoughts than that. Below is a breakdown on what I like and don't like. I'd love to hear other people's thoughts.
Burndown
One thing I really like about Scrum is the burndown concept. Your backlog of tasks starts with initial estimates for time and each task is updated on a daily basis to reflect to the amount of work left. What I like about this is that you can see a great view of how your project is progressing. You can see if your estimates were off. You can see when new items have been added. And it is really easy and makes sense. No percentages complete, just what is left. It can all be rolled up nicely into a "Burndown Chart" to show you how your doing. Here's an example.
To get the complete picture, I like to add a line that shows the total estimate. At first you might think that that doesn't help much because it shouldn't change. Well you and I know that that isn't usually the case. This new line on the chart shows how many new items and how much work has been added to the iteration (just in case things slip you can see why, not that that ever happens). Scrum tries to protect the development process: it allows for new tasks to be added to your sprint backlog, there just not supposed to be new features. Again, I think this is not often the way things work out.
All Aboard?
This brings me to my next point. The business side of the development equation has to be on board with the Scrum process for it to work. That might sound obvious, but unless you have a strong voice that will respect the rules, Scrum isn't going to work out. The business will have to know that that new feature will need to wait until the next Sprint. So culture here is really important to your success. That's going to be true with any software development process. With Scrum, I feel like you really need that buy in.
Requirements Aren't Perfect
Like I said before, the idea of a backlog of features is great. "We need to be able to view our orders by state." That's a feature that is pretty straight forward. Put it on the list. Prioritize it. We'll get it into a Sprint and out in a release. Sounds good. But there are always questions to ask about those features. Or there are features that aren't so straight forward. "Our customers need a better view of their orders". They're never perfectly documented or straightforward when they come to a developer. The business analyst might capture what they think the user wants, but there's often back and forth necessary when you start building the feature. So how do you estimate for that? Do you pad for additional requirements gathering time? I think that is what Scrum wants you to do. And the first day of the Sprint is a planning day so you may get some of that done there. So this might be handled in Scrum, but this is one of the things that I think is much harder to do successfully that it sounds.
Long Term Planning
Something that I don't understand about Scrum is how it accounts for long term planning and changes from a technical standpoint. If you're building out a new system, there is going to be a decent amount of technical design required before any coding starts. There might not be any deliverable code at the end of this. Scrum seems to require a potentially releasable deliverable. That isn't always going to be the case. Somethings take longer than a month. For example if you're moving from from oracle to sql server and you know you can't do that in a one month period, do you do it as a sprint do you? Do you start the new work in a Sprint that won't yeild a release while continuing to deliver new features for the current system in a separate sprint? What if you need to do some evaluation of your application. If you were going to evaluate a new third-part toolset or tweak performance? Or if you're changing to a more service oriented architecture that you didn't realize was needed at first. How do you handle this? Can you add technical-only items to you backlog?
This is where I think the 2-4 week strict Sprint timeline breaks down a bit. I get that you can get a rythm going if your consistent, but I just don't think that everything can or should be done in such a strict timeline. What's wrong with a 3-month first phase? This may be where some semantics come into play. You could say that a 3-month phase is just three Sprints. Some things, though, should just be taken out of band.
Daily "Standup" Meetings
My last thought on Scrum is about the daily meetings. Scrum demands a daily "standup" meeting where the team reports quickly on what they've been doing, what they're going to be doing and if they have any roadblocks. Communication is important - no question. And I like the concept of team members committing to what they will be working on. But a daily 15 minute meeting never seems practical to me. Everyone is supposed to stand to keep things moving, maybe even pass something around to designate the speaker. And the Scrum Master is supposed to take issues offline for subsequent meetings. Sounds good.
Realistically people are on a roll come meeting time or they get distracted and pulled in different directions and can't make a daily meeting. At the very least this can cause someone to be late. This is killer if that person is the Scrum Master. Roadblocks that arise often involve the majority (if not all) of the team that is present, so it just makes sense to talk about them a little bit while everyone is there. Autonomy of the developers is a tenet of Scrum, yet developers have to check in every day. Or maybe you don't trust your team? That's one way it could look to a developer. Let's let everyone sink their teeth into something and do a couple days worth of work and then report back.
The daily stand up meeting is likely to fail. This can lead to resentment toward the whole process and subsequently low morale. Weekly meetings and the responsibility to raise issues as needed work better in my opinion.
Last week I participated in the Microsoft .NET Techology Briefing in Milwaukee. I gave a presentation on what's new since .NET 2.0. Topics included .NET Framework 3.0 and 3.5, ASP.NET AJAX, Silverlight, and Visual Studio 2008.
You can download the slides here:
https://employees.claritycon.com/bdougherty/blog/downloads/NewSince2.zip
Here's are links to some of the demo material:
WPF Healthcare Prototype
http://wpf.netfx3.com/files/folders/applications/entry6608.aspx
WPF Zeus XBAP
http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=53790
http://wpf.netfx3.com/direct/zurich/zeuswpf.xbap
Simple demo projects I created in Visual Studio 2008 (LINQ to SQL demo won't have the database so it won't run)
https://employees.claritycon.com/bdougherty/blog/downloads/DemoApps.zip
User controls are great. They allow a developer to encapsulate functionality that can be reused throughout applications. Like any well designed class, they allow the consumer to care only about the interface and not inner workings. And from a team perspective, they provide logical separation of tasks so that multiple developers can work on related functionality simultaneously.
But just like everything else in this world, there can always be too much of a good thing.
Too many user controls can be a pain to manage, add overhead, and potentially make the data you’re trying to work with harder to retrieve. Plus, building new controls does come with a cost and you don’t want to waste your time. Below are some questions I think you should ask yourself before deciding to build a user control. Specifically I’m thinking in the context of ASP.NET web development, but much of this relates to Winform and development, too.
Does my control have a unique behavior?
It’s easy to fall into the trap of data (not behavior) dictating the need for a user control. Let’s say that a couple web pages need to allow users to select from a list of apples. Before you know it, someone builds ApplePicker. The ApplePicker usercontrol contains a DropDownList control and allows the consumer to set the data source to a list through a DataSource property. And…and that’s about all.
It turns out there is no behavioral difference between the two controls. The task of showing selectable lists of fruit could easily be achieved by simply using a DropDownList control itself. Now if the ApplePicker provided a list of options AND conditionally showed an icon based on whether the selected Apple is good for making pies or just good for snacking, then you’ve probably defined some unique behavior. In this case a custom user control is probably in order.
What if I just used a utility/helper class instead?
So let’s suppose the ApplePicker user control was simply a DropDownList as we initially discussed. But now the control is going to be "data aware". It knows how to load itself full of Apples. While it’s pretty cool to be able to drop a control on a page and "it just works" by filling its data source, in my I’ve found that it tends to not be all that practical or even all that beneficial. The rationale behind such a design decision is usually to avoid having to wire up the data source of your control on every web page and allow for ease updating the actual data source. These goals can be achieved in a better way.
Defining a static method a utility or helper class (Utility.GetApples()) allows for a consistent way to load the ApplePicker on all your web pages. The actual source of data can be changed for all controls by changing the inner workings of the GetApples method. And it also allows you to change the data source in any exception cases. For example, most web pages may show a full list of apples, but one may need to show a list of Favorite Apples that a user has defined. Both lists can be displayed with a single control that is now more in tune with a Model View Controller pattern. This can also help you consistently add the typical "-- Please Pick An Apple --" or blank first item in your list. I really like following this kind of pattern with controls to separate the behavior and display and find that it is almost always beneficial.
Do I need to lock down access to my functionality?
So let’s suppose the ApplePicker user control was simply a DropDownList as we initially discussed. What if I want to lock down the way consumers use my control. For example, I feel strongly that consumers should only pass in a List<Apple> (List(Of Apples) in VB) then maybe I’d want my own strongly typed DataSource property. A better rationale, though, would be that certain methods or properties of the standard control provide more access than you want consumers to have. For example, you may wish to only allow the Text property to be read-only. Access alone is probably not going to justify use of a user control since in most cases you’ll probably want to lock down access to something that relates to unique behavior.
Am I just trying to prevent duplication of code?
I’ll buy code reuse as justification for a user control. But only if there is a lot. If you have two web pages that have to show a list of Apples and the list can simply be achieved with the afore mentioned DropDownList, you’re not going to win me over. If you have 20 web pages that need to display this list of Apples with a red Font and green BackColor, then you’re getting warmer. But I’d probably look to see what we could achieve using skins and themes instead. In general, I think you should try to avoid the "duplication of code" argument unless you have a composite UI (multiple controls) like the conditional icon example.
Should I build a templated control?
Lastly, returning to the MVC and "behavior" theme, I think it’s good to ask whether templated controls are a good fit for your design. You’ve defined a unique behavior, but it before you know it, some web page may require 90% of the functionality in your user control, but they want to make a subtle UI change. For example, instead of a conditional icon indicating the best use of the selected apple, you may just want to display the text "Pie" or "Snack." ASP.NET offers some cool functionality allowing you to define a control that allows the UI to be tweaked via templates. This certainly involves more work when building your control, but it may be a good way for you to extend the reuse of your control.
Summary
I’m a big fan of user controls, and an even bigger fan when they are thoughtfully designed and reusable. As discussed above, there are plenty of great reasons to use them. However, they can become maintenance nightmare and simply add to overhead. I know this topic can spark a lot of opinion and debate, but hopefully these questions will help you make future decisions about when to create user controls your applications.
Microsoft has released the newest version of the Interop Forms Toolkit. You can download it here. Clarity created the first version of the toolkit aimed at simplifying the process of migrating VB6 applications to .NET. The new version goes beyond Forms, adding support for easily incorporating .NET Controls in a Visual Basic 6 Form.
MEDC was a bit of a let down this year. Last year, MS was championing Windows Mobile 5.0 and rightly so. It was a big step. This year nothing like that existed.
Windows Mobile 6.0 and.NET CF 3.5 have some cool updates. Windows Mobile Pocket PC and Smartphone are called now Windows Mobile Professional and Standard, respectively. There's a new cellular emulator and a Fake GPS emulator for developers to test with. Orcas is coming. But there wasn't that huge jump in technology.
You still have SQL Server CE. And though the name changed four times, you still only have RDA and Merge Replication. The Occasionally Connected Sync framework/components/pattern or whatever still seems to be off in the distance. Gaming and entertainment still makes up a larger portion of market share than Business/Office and Home/Education combined.
Maybe MS didn't put the effort into mobile that they did the year before. Maybe my perception is off. This year just seemed to lack some excitment. It's still mobile development, though, and that is ALWAYS cool. So hopefully I'll get my hands dirty with some of this soon. I'll be sure to post on any new excitement I learn about.
One of the cooler things I learned about at MEDC was the new Store and Forward Transport capability in the upcoming .NET CF 3.5. This allows one device to send data to a central data store and even directly to another device using the new Email trasport feature in WCF. This looks like it could really simplify data transfer in some scnearios, especially in a loosely connected enviroment. Essentially your "service" mail stays up on the server until your code pulls it down.
The new code lives in the System.ServiceModel.Channels namespace. The basic flow of the code looks something like this.
RECEIVING
- Create a WindowsMobileMailBinding
- From the binding, create a listener specifiying the channel name and email address
SENDING
- From the binding, create a channel factory
- Open the factory and create and output channel
- Create a Message that includes your serialized custom data and send it
Of course there's that's the simplified view, but seeing and playing with the code a little, it looks like it's easy enough. It's also worth noting that messages can be protected using WS-Security.
For more detailed info, checkout Mark Prentice's blog: http://blogs.msdn.com/markprenticems/archive/2007/04/25/introduction-to-the-windows-communication-foundation-for-the-net-compact-framework-store-and-forward-messaging.aspx
One of the discussions at MIX covered patterns to follow when developing with AJAX. These patterns, or maybe better called conventions, can be divided into two groups: Foundational Patterns and User Experience Patterns. Foundational patterns describe the structure of the code and resources used to develop AJAX. User Experience Patterns, not surprisingly, improve the way a user interacts with the web site.
Some of the foundational pattern discussion was not new. It's something I think we all try to do in our everyday development: separation and encapsulation. Whenever possible, separating code from content is ideal. For example, moving your custom javascript code into a separate js file can allow for content updates independent of code. Taking it a step further, the inclusion of javascript and control over the placement of content can be encapsulated into a server control creating a single unit that can be reused. I know this isn't rocket science, but in an enviroment where web tools change frequently and there are lots of options, it is nice to affirm the belief in building reusable pieces of functionality that abstract behavior from content.
The patterns that are more interesting to talk about with AJAX relate to user experience though. That's why we've got AJAX, right? AJAX exists to make it easier to build a user experience that is more intuitive, responseive and user friendly. The two points of interest we discussed related to history an user feedback.
With AJAX, you lose the postback and therefore lose the back button. That might seem like a bad thing, but instead, it can be treated as an opportunity. For example, if a user is filling out a form that adds an order, you probably don't want them to be able to go back to the form with the old values after they submit. Let's think about another example, though. You may show pictures of products that a user can click through with typical paging controls. Making them slick with AJAX is cool, but you could make the behavior of the page even more natural by allowing the back and forward buttons to do what the user expects: navigate through the images they just saw.
A future release of the AJAX Control Toolkit (man is it difficult to track what is/will be available when) will most likely offer a history server control that exposes an API for managing web browser history. This allows you to define logical views in your web site and decide exactly when to add history. You can even structure these views such that they can be accessed via a URL for bookmarking/static linking ability. For more info and the current source code for the control check out Nikhil's blog (http://www.nikhilk.net/BackButtonSupport.aspx).
Another pattern to follow relates to giving a user feedback about what they changed. One way to do this is by using the UpdateAnimation control that current ships in the AJAX Control Toolkit. A new way is using the prototype UpdateIndicator control that is targeted for a future release. I don't think the code for the control is available yet, but I'll post an update if I find it. The server side control allows you scroll to a changed field and momentarily higlighting the change. Implementing this type of behavior significantly improves the user experience and further blurs the line between web apps and richer fat client application abilities.
For more info on AJAX patterns, check out the following sites:
http://ajaxpatterns.org
http://developer.yahoo.com/ypatterns/
Robbie Bach, President of Entertainment & Devices Division, led today's keynote address at MEDC 2007. The overarching theme of the presentation was that Microsoft is known to be your connected solution in the workplace, but they want to also be your mobile solution. MS wants to give users "what they want when they want it." They are continuing to focus on expanding mobile services from both MS (SQL Server, Office, Dynamics) and partners (VCast, Yahoo!, Sling, Weatherbug, vodaphone), improve development provide tools (VS.NET), and supporting the market (Mobile Marketplace, Verisign) to foster growth in the mobile landscape.
The presentation was a little heavy of the marketing side of things, but there were some cool highlights:
- Clarity's own Jon Rauschenberger demoed a Crate & Barrel touch screen Gift Registry kiosk application, highlighting the use of Expression Blend, Target Designer and USB boot/deployment
- Microsoft Robotics Studio was demoed, using an XBOX control to drive a robot through a full 3-D, full-physics simulation environment
- Additional help for developers including SQL Server CE in-ROM, .NET CF 3.5 support for LINQ and support for unit tests
- A new technology shipping with .NET CF 3.5 Futures called Store And Forward that allows a mobile device to push data (like inventory information) through Exchange to another mobile device
- Using web services on devices (WSD) to control things like lighting and the thermostat in your home remotely
- A demo showing a full Silverlight web site running on IE mobile
Today at MIX, a new set of controls aimed at simplifying data binding in ASP.NET were announced as part of the ASP.NET Futures release. The goal of these controls is to make the process of creating a data bound web site extremely easy. The theme of the presentation seemed to be "Use these controls to rapidly develop a starting point that you can replace portions of over time." While the controls do meet this goal, there is, in my opinion, only a very small set of real world projects that would ever use them.
Some of you roll your eyes when I voice my skepticism for the magical wizardry that Visual Studio and some controls (Web or Winform) offer to make data access and display too easy and impractical for real world enterprise applications. I can usually support my position in a debate, though I many times I'm satisfied to say "it just doesn't feel right." With these new Dynamic Data Controls, though, I think we'll all be able to agree: They're just not practical for most enterprise situations.
Let's review the offering before making a full judgement, though.
The story of the Dynamic Data Controls starts by adding a data source (currently only a SQL Server database) to the App_Data folder of your web site. (You may also be able to simply select a connection string, but it wasn't clear.) Then you create a web page, optionally using the pre-built Dynamic Data Web Form template. Finally, you add one or more of the new Dynamic Data Controls and there you have it. The magic behind the curtain recognizes the columns, data types, foreign key constraints and other info about your database and wires up a fully functional read/write data driven web site. You can even skip adding the web page and with a simple tweak of the web config you can have the auto.axd mechanism create an entire site for your database.
The new release offers several new controls. The DynamicList is essentially a grid with your typical edit, delete, and row select features. DynamicDetails and DynamicInsert controls gives you a details view and the ability to insert a record. The DynamicFilter is a drop down list or radio button (or maybe another control) that filters your data source. The DynamicRSS control exposes your data as an RSS feed. Finally, there is the big daddy DynamicAutoData control that is a composite of all of the above.
All of the controls support the extender pattern of setting the ControlID property to the ID of the Control you want to use. For example, if you want to make a DynamicFilter a DropDownList with so you can handle it's events, you would set the DynamicFilter's ControlID to the ID of the DropDownList.
<asp:DynamicFilter ID="dfOrderID" ControlID="ddlOrderID"/>
<asp:DropDownList ID="ddlOrderID" SelectedIndexChanged="ddlOrderID_SelectedIndexChanged"/>
So to review, with zero code, you created a data driven web site. You can even customize some of the style and behavior. But that's it. You haven't built an enterprise LOB application. And you really can't. The meat is in the magic, and there is a little too much mystery meat for my taste. Where's the security? Where are the business rules?
Unfortunately, there is no good answer, at least not yet. The roadmap for the Dynamic Data Controls seems to revolve around the use of LINQ as the data layer and that is where you would wire up your business logic. But integration with LINQ isn't ready.
I credit the team that built the Dynamic Data Controls for creating a neat tool. But unfortuantely (at least for now) outside of a purely internal or administrative web site, I don't see there being any enterprise-level value. Oh, and the whole thing just doesn't feel right.
So I finally got a new phone! I've upgraded my MPX220 to the Cingular 3125, also known as the HTC Star Trek. I've had the phone for a few weeks and so far I've been very happy.
Phone
First and most importantly, let's talk about the phone features. It's thin and light, comparable to the RAZR, and has metallic textured exterior so it doesn't slide around. The call sound is solid - definitely loud enough. It's comfortable to hold when making a call, one thing I didn't like about the Q or BlackJack which are wider than a typical phone. The buttons are flat, but have dividers so you know what button your pressing. The joypad in the middle is a bit small for my fat thumbs, but I've adjusted pretty well. The screen is clear and bright and in general the Windows Mobile 5.0 OS seems to keep up.
Battery life, another complaint among owners of the afore mentioned QWERTY phones is not an issue with the 3125. I don't have to religiously charge it everyday and that's with some MP3 use and over air ActiveSynching. The phone comes with both a wall charger and a USB charger, also used for synching. This is great because I keep one at work and one at home. The one downside, though, is that USB charger is definitely slower.
Predictive dialing works well, with one complaint. My speed dial numbers used to display at the top of the list on my old phone. Now when I press 5, the J's, K's and L's from my recent history now show above my #5 speed dial, where as with my old phone, the speed dial number was at the top. It still works the same (press and hold 5 and it calls that speed dial) but I miss the visual feedback.
MP3 Player
UnAmerican as it may be, I don't own an iPod and instead use my phone as my MP3 player, just like I did my old one. This is where the 3125 picks up steam. The media controls on the outside are the killer feature I've been waiting for. It shows you what song is playing on the cool exterior display and I can pause and skip to different songs. Only once have I accidently hit the buttons hard enough to inadvertantly start the media player. The included earbud headphones have good sound and a volume control next to the microphone.
While it still lags behind the iPod when it comes to usablity, the new version of Windows Media Player Mobile is a big improvement over previous versions. It has a library concept allowing me to browse by artist, album or genre. Synching through Media Player on my PC is better than it used to be, but still craps out every once in a while. I haven't figure out why yet.
In general the MP3 capabilities are what make this phone great. With a 2GB micro-SD card added, it has a pretty good capacity. I can use it on the train or at the gym. I just need to get the right adapter and hopefully I can get it working in my car.
Organizer
Lastly, there's the productivity side of the equation, and the reason I got a smartphone. I can sych my calendar, email, contacts. MSN Mobile works pretty well for checking my Hotmail, too. The only big upgrades I got here are Exchange Push Notification and synchronization of tasks. The former doesn't make a big difference for me, but the latter was big for me - I'm a big list maker. The interface ifor tasks is still pretty prehistoric, but synching over the air is great. I still may look for better task management software, though. The phone also shipped with the ClearVuew suite of software for viewing documents, pdfs, and presentations.
Overall I think the 3125 is a great phone. It has solid phone features, makes for a good MP3 player, and satisfies all the organization needs of someone who would rather carry a small solid phone over a a brick with with a QWERTY keyboard and a stylus.
So SQL Server Compact Edition has been released officially. Remember? It's that product that was called SQL Server Everywhere...or was it SQL Server Mobile?
Jim Wilson has a nice post that summarizes where you can get all the goods:
http://pluralsight.com/blogs/jimw/archive/2007/01/15/45704.aspx
For more on the naming see Steve Lasker's blog:
http://blogs.msdn.com/stevelasker/archive/2006/10/31/sql-server-everywhere-gets-yet-another-name.aspx
Sometimes we write .NET code that needs to behave differently based on the type of the instance it is working with. In other words, branched logic based on type. In a custom collection, for example, we may have logic that says "if the item added is of my custom item type then check one of its properties." An example in the .NET Framework is the DataGridView. It behaves differently based on the type of the data source that was set. One set of behaviors for an ArrayList and additional logic for a DataSet.
Usually the following code would satisfy the need:
If TypeOf _dataSource Is DataSet Then...
This type of detection gets a little tricky when your writing code to try to find a Generic class that you don't know the type parameter for.
Assume you defined the following classes:
Public Class SomeCollection
Public Sub Add(anyItem as Object)
' If anyItem is SomeObject
' check the SomeInfo Property
End Sub
End Class
Public Class SomeObject(Of TInnerObject)
Public ReadOnly Property SomeInfo As String
Get
Return _info
End Get
End Property
End Class
The first class is a collection that allows any item to be added to it. The second class is a Generic class that you will sometimes add to your custom collection. If SomeCollection always wanted to check the property SomeInfo on a SomeObject if it were added, you couldn't easily write the code to do so because you don't know what the type parameter for the instance is. In other words, you don't know to put in place of the question mark below:
If TypeOf anyItem Is SomeObject(Of ?
There are two similar ways to go about solving this problem. The first is to declare an Interface that SomeObject implements.
Public Interface ISomeObject
ReadOnly Property SomeInfo As String
End Interface
Then you can write the code as
If TypeOf anyItem Is ISomeObject Then...
What I prefer is to create a base class for your Generic object that has the same name but no type parameter and forces the implementation in the derived Generic class. I think it is more readable and potentially easier to manage.
Public MustInherit Class SomeObject
Public MustOverride ReadOnly Property SomeInfo As String
End Class
Public Class SomeObject(Of TInnerObject)
Inherits SomeObject
Public Overrides ReadOnly Property SomeInfo As String
Get
Return _info
End Get
End Property
End Class
This way you can add the following code in SomeCollection's Add method:
If TypeOf anyItem Is SomeObject Then...
Background
I recently needed to implement custom serialization in a class that we'll call MyCollection for simplicity. The class supported a number of things including providing a Dictionary like interface as well as binding support. Not surprisingly it maintained a couple collections including a Dictionary(Of TKey, TValue) and a BindingList(Of T), the latter exposing events needed for binding to a grid.
The Problem
Since I was using binary serialization, serializing the BindingList would be problematic since any objects that hook the BindingList's events would also be serialized. That includes a BindingSource object which doesn't like to be serialized. Okay. No problem. All I'd need to do is only serialize out my Dictionary, and then rehydrate the BindingList after serialization.
I can prevent serialization of my BindingList by decorating the private member with the <NonSerialized()> attribute. Then using the new <OnDeserialized()> attribute that is part of the .NET 2.0 Framework, this would be easy. Just create a method in MyCollection of the correct signature, decorate it with this attribute, and write a quick loop to add from the Dictionary to the BindingList. That easy, right?
Enter the Misbehaving Dictionary
For some reason, the Dictionary is not all quite there when my method gets called. It's there, but empty. But if I check it after the serialization is all done (which I thought my method was doing), it IS filled with my objects. I didn't get it. I tried some simple examples with non-Dictionary classes out and they all work fine. Then I found empathy, or is it sympathy...well, at least I found someone with my problem:
http://forums.lhotka.net/forums/5495/ShowThread.aspx
Happy to find that I wasn't crazy, I came up with a workaround. Again using custom serialization attributes, this time the <OnSerializing()> attribute, I can force the serializer to call a method that will copy my Dictionary's keys and values into arrays which are members that will be serialized. Then during deserialization, I can rebuild my Dictionary based on the keys and then I'm back to where I wanted to be: able to rehydrate my BindingList from my Dictionary. A little bit of a pain in the butt, but it works nicely.
More Posts
Next page »