Application Generation - Design Patterns

Managing Composed objects - admin workflows. Input appreciated . . .

Tue, 23 Jun 2009 10:24:00 -0400

A common use case in a cms is that you want to add a new object and then add some composed objects. You might add a user and then add addresses to the user or add an event and then add purchasable tickets to that event, etc. Anyone got any opinions about good workflows to enable this? Lets take the events with multiple composed tickets (and I want to differentiate this from associated objects - such as where a product is associated to multiple categories but isn't composed within it). Simplest solution is you go to the event manager, add new event, then go to the ticket manager and add ticket, selecting the appropriate event. This is very easy to implement in the general case but not very usable. Maybe the next step up is at the bottom of the "add event" form to have two buttons - "add event" and "add ticket to event". The first will add the event and go back to the event list. The other will add the event and then display an "add ticket" form which will have two links at the bottom - one to "add ticket to event" and another to "add more tickets". First will add ticket and go back to either event list or event detail (displaying composed tickets as a master detail screen). The second will add the ticket and display another add ticket screen. Another approach would be to ajaxify this a little bit. You could add a "add ticket" button with a pop up window for adding tickets right on the add event form, but then the question comes as to how you associate the tickets to the event if it hasn't been saved yet. Maybe the "add ticket" button both saves the event *and* displays the add ticket window? The main issue that makes this complex is that in the general case sometimes you come across composed objects that in themselves have composed objects - n levels down. Lets say that you added a project, a project had composed teams, teams had composed events, and events had composed tickets. How do you provide a usable interface that allows you to easily add tickets to the events that you're adding to the teams that you're adding to the projects?! Obviously a bit of an edge case, but has anyone ever come across use cases where they had to step down multiple levels of composed objects in that way and what kind of UI did you find to be most usable? Any input on good approaches to this problem appreciated.

When a Form ISN'T a Business Object

Thu, 13 Nov 2008 10:35:00 -0400

Often in OO apps, forms relate to business objects. You might have a user registration form, an admin form for managing products and a login form for users to access the system. All of those probably relate to business objects (User, Product and User or SiteUser respectively) and you'll have some kind of system for populating and validating those business objects on form submission. However, I often find that there are a number of forms on simple websites that really don't need to relate to a business object at all. If someone wants to set an appointment online, you may well want an Appointment object with a bunch of business logic for setting them and managing them, but if you just want a simple "contact us" form or even an appointment form that is just supposed to send an email to a person to handle, it's probably not worth having a whole OO based system for processing those forms. This doesn't mean the form processor won't go through an OO framework - just that the form processing itself won't include populating and validating a form specific business object. That begs the question, how do you determine whether a given form should have a related business object (or objects) . . . [More]

What is an Object as a Struct?

Mon, 14 Apr 2008 15:30:00 -0400

Let's say you have an object and you'd like to turn it into a struct. What does that really mean, and what should the code do? [More]

Rebuilding my Base Object

Mon, 14 Apr 2008 12:52:00 -0400

As you might have guessed from my last few postings, I'm doing a ground up "clean up" of all of my LightBase code. The starting point is to give my base object a quick going over . . . [More]

Storing Instance Data in Beans vs. IBOs

Mon, 14 Apr 2008 10:59:00 -0400

As part of my generic getters and setters I like to put my instance data for all of my beans into a struct so there is no chance that instance data and methods will overwrite each other (which might otherwise be a possibility if both ever had the same names). But when I start to play with IBO's, I have two types of data to store - instance/object data and class data . . . [More]

What do you put in your Base Object?

Mon, 14 Apr 2008 09:55:00 -0400

Creating a base object that all of your CFC's extend is a powerful technique, but one you've got to think carefully about . . . [More]

Other Approaches to Getters and Setters

Thu, 10 Apr 2008 20:14:00 -0400

Both Ben and Joe have proposed other ways to provide getter/setter functionality without having to write (and much more importantly to read and maintain) lots of dumb getter and setter methods . . . [More]

Generic Getters

Tue, 08 Apr 2008 10:44:00 -0400

When developing Object Oriented code, it's important to encapsulate the variables contained within an object. That way, you can vary the internal implementation of an object without having to find and change all of the methods that call the object – providing you don't change the structure or the behavior of the methods for that object. [More]

Adding State to your Business Model

Mon, 07 Apr 2008 13:41:00 -0400

In a recent posting, I looked at how it could be useful to model some of your business objects as state machines. In this posting I wanted to do a thought experiment about how you could build the concept of state right into a business object so you would be able to declaratively describe states and then the object would be smart enough to provide the appropriate attributes, validations and methods automatically, throwing an error should you try to access/modify information or undertake an action which was not valid in the object's current state . . . [More]

Modeling Business Objects as State Machines

Fri, 04 Apr 2008 10:35:00 -0400

Often business objects in even fairly simple systems go through a number of states within their lifecycle. For instance, you can't ship an order that has not yet been placed and a user that hasn't logged in can't view their account. This post looks at how thinking about state when designing your objects can help you to write more maintainable applications. [More]

E-commerce – Orders and Addresses

Tue, 01 Apr 2008 13:37:00 -0400

The thing I love about building even very simple e-commerce applications is that they can bring up sufficiently complex classes of design problems to make them a great testing bed for new ways of implementing web applications. Today I want to look a little at the old “orders and addresses” problem to see if it can provide any more generalized insights into Object Relational Mapping . . . [More]

One Service Class Per Business Object - Not as Bad as You Think . . .

Fri, 14 Dec 2007 10:35:00 -0400

For a while I've noticed that a number of people who I respect in the ColdFusion world recommend that you not reflexively have one service class per business object. I want to suggest that actually it's a pretty useful default approach - especially if you want to develop consistent, maintainable applications - quickly and cost effectively. As always, looking forwards to feedback . . . [More]

How Many Classes Per Business Object?

Thu, 13 Dec 2007 10:35:00 -0400

How many class files should you have per business object? In Smalltalk and Ruby, the answer is often one. I'm finding three is working pretty well for me - here's why . . . [More]

The Death of the Gateway?

Mon, 10 Dec 2007 10:35:00 -0400

It is interesting to see the change in tenor on the mailing lists recently when discussions turn to DAOs, Gateways, Service classes and the like. I won't say the Gateway is dead, but when I say it's feeling unwell, I'm thinking of Soviet era Russian premiers as I think about it . . . :-> [More]

Do YOUR web applications lie?

Wed, 12 Sep 2007 11:38:00 -0400

I noticed a posting on the Scottish CFUG about AOL and session problems and it got me thinking about sessions, the meaning of URIs and whether we're building websites that lie . . . [More]