« An amusing story about databases and pants | Main | Celebration »

Partial Pages in ASP

I wrote some code. Imagine that! If someone were familiar with this backup tracker project, but not with me or my family, it would appear that I started testing out partial pages, then fled in terror for 3 months. Not true! While the specific implementation of partial pages in ASP.NET is new to me, I understand the benefits.

The basic idea is to write a piece of a page that you can use multiple times in other pages. In this particular case, that's a form. Whether you want to add a backup/harddrive, modify an existing entry, or delete one, you need some kind of interface for entering that data. If you want to add a new entry, the form is blank. If you want to modify an entry, you pre-populate the form fields with the data about the harddrive or backup and allow the user to edit some or all the fields. If you want to delete, you pre-populate the form, restrict the ability to edit, and make it super-duper clear that you're deleting something. Partial pages lets you write the big chunk of that page -the form- once and use it in different contexts by inserting it in other pages.

This was a new way of thinking about this problem for me. I'm mostly self-taught, and I started with PHP. When I needed to do add/edit/delete forms for a project in PHP, it took a while to figure out how to do it. My first thought was to just write 3 pages, but I rejected that idea almost immediately. Copying code like that is a bad idea. What if the form has to change? What if something with the database changes? What if someone else has to change something, and doesn't know to change the other two?

So the next thing I thought of was to do all of them as a single page. This seems like a good idea until you try to do it. The hard part isn't really writing the code, it's trying to understand it later. Now I'll admit that I probably didn't hit upon the best way to do this particular idea, so maybe there are ways to do it that are easier to manage or make more sense. My pages were a mess. The problem is you need to account for 3 different complex tasks, all while trying to use the least possible amount of code. You want the add/edit/delete options to use the same form or you run into the problem of having 3 completely separate pages. The solution is to use variables in the form, and account for them in the code blocks for the 3 specific options.

So what I did was split the page into 3 parts. The first part was Setup, where there was some code to figure out what you want to do, and prepare the correct data for that option. If you wanted to add an entry, it would use blank variables so the form would be empty. If you wanted to edit it, then it would get the info from the database and put it in the variables to pre-populate the forms. The delete would do the same as modify, but also add a little piece to the form that made the fields uneditable. This section would also define the instructional text above the form, change the title of the page, etc.

The second part was the actual page. This was mostly variables, since the title should be different for each, and instructions. This is where the actual form code was written, but it was almost unreadable because of all the jumping in and out of PHP code, or using echo or HEREDOC statements to build the forms.

The third part was the Results section. This is where it would attempt to validate the data, and perform the final database option of adding, editing, or deleting, and display the results. Sometimes this section was bigger than the other two combined if a lot of work had to be done on the data before interacting with the database.

To make things more complicated, I usually did forms on a single page and split them up by how they interacted with the server. This is get and post. When you first request a page, you use GET to retrieve it from the server. When you're submitting data, you're using POST. So if the server got a GET request for the page, it would display the form. If it was POST, it would execute the form processing steps and then add it to the database. This meant my 3 part page was further split into 2 sections, with the Setup and Form parts in the GET section, and the Results part in the POST section.

The end result was a huge, complicated, almost unreadable page that worked, but god forbid I ever need to modify anything in it. It's ridiculous, I would be afraid to change anything because it was so hard to see what the results of that change would be. Would I break another part? How would I ever find that part again if it did break? What a mess!

Now using partial pages doesn't completely negate all that, but it does make it easier to manage. That changes the actual form from taking up easily 40+ lines for a simple form to a single line of code to render that as a partial page. This makes using separate pages for each action far more attractive. You still run into the problem of adjusting for a database change, but changing the form is simple. It's also easier to keep track of what you're doing when you don't have that big chunk of form code sitting in the middle of your work. It makes all the code (except the one line) for those pages only about the task of that page. It was also pointed out to me today that there are other options for doing the delete that don't require the form, so that makes things even easier.

Now the only trick is actually writing it. I'll report back on that later.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.