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.

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]

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]

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]

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]

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]

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]

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]

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]

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]