Skin Spider : Getting Very Close To Phase I Completion
Posted October 11, 2006 at 7:35 AM by Ben Nadel
To learn all about Skin Spider, click here.
To view the most updated application, click here.
To view the current code base, click here.
I have added the video editing and delete confirmation pages. Nothing particularlly special here. These pages are very similar to the tag editing and delete confirmation pages. For editing, I am displaying both the video and the gallery information but only the video information is available for updating.
On the video delete page, I delete the video, the video thumbnail, and the movie file. Then, I check the gallery that the given video was linked to. If there are no other videos in the system linked to the given gallery then this gallery is no longer needed. If the gallery is no longer needed, then I am deleteing it from the database as well (and also its thumbnail).
The video delete page is the first example of a higher level ColdFusion query of queries. The qGallery query uses a inner join, the COUNT(*) aggregate, and the GROUP BY clause. This is probably the most complex that the queries in the system are going to get. You can only join two tables at one time in ColdFusion query of queries. In order to accomplish more complex queries we are going to have to break them down into less complex, multiple queries. But, I am getting ahead of myself... we will cross that bridge when we get to it.
Getting back to the code, though, I was orginally planning to allow the user to choose wether he/she wanted to delete a single video and / or the entire gallery (all videos associated with the gallery as well as the gallery itself). This, however, is prooving more indepth than I want to go in the first iteration. I am really itching to get the first Phase done and out the door so that we can start exploring the problems with the system and dive right into refactoring the application.
Right now, there is no way in the system to actually edit gallery information. The closest thing that I get is to delete the gallery is if it is no longer needed (as explained above).
Page Flow
As I am testing the system, I am seeing that the "success" page redirection is totally bunk for the search pages. Look at the Tags section for contrast; when you edit a tag, the system throws you back to the tags.cfm page. That's no problem since all tags are listed on the same page. But, on the search page, you might have a particular amount of search criteria or have paged far into the search results. Right now, the video edit and delete confirmation page just throws you back to the default search page. This completely destroys the work flow. This is something that will definately have to be updated in the next phase (keeping it simple for now).
Data Form Structuring
I just wanted to take a second to talk about the page structure of Data Form Pages. I am considering any page with form submission that updates the database to be a Data Form Page. Examples of this are the edit_video.cfm, edit_tag.cfm, delete_video.cfm, and delete_tag.cfm pages. I have FIVE basic page portions:
- Variable Param'ing
- This also includes things like custom tag includes, REQUEST variable setting, etc
- Pre-Form Processing
- Form Initialization & Processing
- Post-Form Processing
- Page Display
For any page, especially in an application like this where were are not working with a real database, we want to perform as little work as possible. Therefore, if we don't need information we don't get it. If you look at any of my Data Form Pages, you will see that the form processing part of the page may redirect the user to another page. That means that anything post-form processing may or may NOT get displayed. Therefore, in order to do as little work as possible, any information that is required ONLY for page display must be done in the post-form processing. If it is done in the pre-form processing portion, then it may never get used, and hence, that is wasted processing time. The only things that I allow in the pre-form processing is information that is required for form processing (and optionally for page display as well).
Favorites (favorites.cfm)
I have added the favorites page, favorites.cfm. This page lists out the videos that have been marked by the user as being a favorite. If you have a look at the code you will see that I basically copy-and-pasted it from the search.cfm video search page and then butchered it to meet the page needs. Unlike the video search page, the favorites page does not paginate. I don't expect there to be too many favorites, or at least not enough to require the overhead of pagination.
However, I do recoginze that the page may get larger than I would look. To counter act the problems that come with this, I am calling a CFFlush tag after every video loop iteration. This will allow the maximum amount of user feedback to be streamed to the browser as often as possible. This should offset the possible page load time the user would encounter on a large page. I know that some people have issues with the CFFlush tag, but I find it is fantastic for page optimization.
As you will see, all the video editing links (edit, delete) go to the same editing page that is linked from the video search page. The Cancel button on this page (as well as the success page) both send the user back to the search page. Therefore, a user might get to an edit page from the favorites page then cancel back to the search page. This of couse is a total bunk page flow... again, something that I will cover in the next phases of development.
