One of the first things that you learn to do as a Flex developer is create custom components by extending those that come with the core MXML library. Usually you'll bundle a few items together, create a custom event or two, and maybe override some functionality.

However, we've been experimenting with what else you can do with components without crossing the line in to bad practice. Frankly, we're not sure where the line is yet, but hopefully somebody with some more professional Flex experience will stumble upon my blog and set us straight if we're venturing beyond the realm of nice-smelling code.

One of the things I'd really like to do is loosely pair the services that will support our business domains with a set of reusable components that can utilize them. The goal would be that as a developer, you could drop a component tag on a page and have both data and functionality appear immediately.

This probably makes more sense for us than the average Flex development shop because we don't build a lot of one-off Flex apps. Instead, we're building custom software to support specific lines of business within CFI, many of whom consume similar information and perform common functionality in differing business process flows.

Let me explain.

We have a lot of software user interfaces that essentially do the same thing, but slighty differently for different business units. So, for example, our sales floor might search hotel availability when making a sale of a vacation, while our customer service department might search hotel availability to add extra nights to an existing vacation. The business rules for what sort of availability should be searched might be different for each business unit.

Another thing our business really likes to do is the same thing, slightly differently, a lot. So, we might start a sales program that six sales agents test market, where we offer a limited set of hotel availability or adjust the pricing of the hotels somehow to match a test marketing program.

So, we have a few options to make this work in Flex.

1) Write a custom component set, and hook it up to one or more services that handle the variances in business rules. Do this using a framework, writing essentially the same glue code over and over again for each separate application.

2) Write a custom component set, and design it so that each component can invoke its own data service directly (i.e. embed the calls to the remote service directly in the component). Make the bound services implement an interface of some kind so that the component can be wired up with different services.

So, what we'd like to explore is #2. For each application, we'd skip the repetitive glue code, and instead would write a base component and extend/compose it in to a custom component for each front end application. The extension/composition would simply pair the component with the implementation of the service interface containing the custom business logic.

As varying events happen in the component, they can be emitted for handling in the full UI implementation, which would use a standard Flex framework to process the results as necessary. So, for example, a hotel search might take place entirely inside the component with a direct call to the service backing the component, and then when the user double clicks the hotel they want to book, a hotelSelected event is announced that can be trapped by the UI and processed accordingly with the flow of the particular business process for that business unit.

If we go this direction, we'll essentially end up with a set of base components backed by directly called services, with both services and components closely related to a particular problem domain (such as seaching hotel availability, charging credit cards, etc.). For each specific UI implementation, the base service could be used (or a custom service implementation associated appropriately), and bound to the business process through handling of events dispatched by the service-backed components.

We've already prototyped out some components along these lines, and so far we can't see anything we're scared of from a practice or maintainability standpoint. Of course, it's early days, and we have plenty of time left to see this crash and burn in practice.

If you have any thoughts on this approach, please share them. Are we setting ourselves up for total disaster, or is this something that might actually make a lick of sense?