OOPhoto Prototype - Understanding The Interface Before Defining The Domain Model
The latest OOPhoto application can be experienced here.
The latest OOPhoto code can be seen here.
I have completed the prototype for OOPhoto - my latest attempt at learning object oriented programming (OOP) in ColdFusion. As I stated before, since I'm really trying to wrap my head around OOP, I am going to be keeping this application as small as I possibly can, while at the same time, trying to touch on several aspects of object oriented programming. In fact, as I was building this prototype and running through the different use-cases, I decided to eliminate the photo sorting; originally, I was gonna use some drag-n-drop functionality, but I decided that that was going to be too much overhead and more of distraction from OO rather than a benefit. Right now, I just want to get my head around the basic, which is hard enough - I can come back afterwards and add the bells and whistles.
Here are the use cases that I ran through:
- Create a new gallery.
- View a gallery using a given Jump Code.
- Find a gallery using a keyword search.
- Edit an existing gallery using a given Jump Code.
- Delete a gallery.
Not very many different use cases and only a single persona to test. In my next OOPhoto post, I will start to get into the domain model for this object oriented program. For those of you not familiar with the principles of Interface Driven Architecture, it is crucial that we create a complete and robust prototype before we do any coding. Not only does this allow us to stay very agile, it allows us to get a much more complete understanding of what our domain model will be and the services that will need to be made available. Without a full prototype, it would be extremely difficult to be able to capture the full scope of the project.
I have tested the prototype in FireFox and IE 7. I tried to keep the CSS and XHTML as clean as possible; but, at the same time, I didn't want to lose sight of the primary goal of the project - learning object oriented programming. As such, I held the mark up to a high standard, but did not stress myself too much about the naming convensions and minutia of CSS optimization.
Reader Comments
Looks good, Ben. I am sorry to hear that the drag-and-drop tool is no longer part of the first version (though I completely understand why). Having messed around with sorting/rearranging items in a number of different situations, I was curious to see how you'd approach it.
@Brian,
I probably would have just used some sort of "sortable" plug-ins for jQuery. The underlying sort action would have just resorted a hidden ID list:
<input type="hidden" name="lst_photo_id" value="1,5,8,2,4" />
This sort would have then been used to sort the photos on the back end. However, I just feel like it would have been a bit too much for my brain to deal with just now. It's already struggling to absorb all the great stuff the Brian Kotek and others have said in my previous posts.
Yep, that would have been the easiest way to do it.
And by leaving it for the next version, you'll get to see how doing things in OO helps with refactoring.
@Brian,
That is what I am hoping :)