Edit items (hyperlinks) in a repeater with a single edit button

Question

I've got a repeater which is bound to a List<> generated from an XML file. The file consists of two nodes, ID and Item.

<Items><ID>0</ID>
<Item><![CDATA[<a target='blank' href="http://www.cnn.com">CNN News</a> ]]></Item>

I need to provide Edit functionality to allow a user to edit the url and the text of each item in the repeater. I don't want separate Edit/Save buttons for each row; too much clutter. I guess that means a single Edit/Save button, which would essentially result in the XML file being "created" anew on each Save. Or, might there be a better way to do this?

I guess I'm asking two things:

1. A design suggestion on how to make a list of URLs editable (both url and text). Two separate text boxes I guess?

2. How to handle edits.

Thanks.

Answer 1

1. Yes, two separate fields is the way to go here
2. As far as editing, you can have two panels for your ItemTemplate . One for View and one for Edit . The Edit panel's visibility is set to false by default. Each row has an "Edit" button with the item's ID as its CommandArgument , that when pressed, you set a Session variable with the ID of the item clicked. Then when you rebind your repeater, you check each item's ID against the Session edit ID variable. If they match, you set the View panel's visibility to false and the Edit panel's visibility to true. The Edit panel has two buttons, one for Save and one for Cancel. Once the user clicks Save or Edit, you do any back-end processing, clear the Session variable and rebind the repeater. Although there are built in controls that have edit functionality "built-in", I find the control I am alloted by using the Repeater is superior.

I've used this method numerous times and it works great!

If you need any code to illustrate any of the point above, feel free to ask.

As a side not, your XML looks a little strange. There doesn't seem to be a parent node to represent each URL/ID pair. It this an oversight, a typo, or am I missing something here?

EDIT:

This is a good way to utilize ViewState in your scenario:

    private enum PageStates
    {
        None = 0,
        View = 1,
        Edit = 2
    }

    /// <summary>
    /// The current state of the page
    /// </summary>
    private PageStates PageState
    {
        get
        {
            if (ViewState["PageState"] == null)
                ViewState["PageState"] = PageStates.View; //default to view state

            return (PageStates)ViewState["PageState"];
        }
        set
        {
            ViewState["PageState"] = value;
        }
    }

By encapsulating ViewState access in a property, any changes to the method of storing the variable (Session, DB, etc) are abstracted away from any code that accesses it.