Any ASP.NET 2 Experts here?

[bogeyman]

Here's the feature list for ASP.NET 3.0 (release 2009)

Heh! Very good

But seriously, I really wonder what people who claim to develop complex web apps in ASP.NET 2 are smoking. I need some of it, 'coz I don't understand how you can coax this huge pile of turds into doing anything MS didn't anticipate (which turns out to be most things not involving SQL-Server or Access (spit!!))

and VS.NET Clippy Says: -

Hey! Looks like you're writing a UI layer for complex web application !!!!!

Hey! Looks like you need to add some dynamic content rows with checkboxes and links with bound event handlers and stuff.... may I recommend the GridView!!!

Hey! Looks like you've spent several days trying to get the spastic GridView control to work properly. Sorry would have popped up sooner to tell you it doesn't work properly, and never will, but I was stuck to a fridge magnet!

Hey! It looks like you've discovered the lie that Winforms and Webforms can provide similar functionality and that ASP.NET has a reliable solution to state maintenance between round-trips!!!!

Hey! I see you're writing some PHP5 code... errrrmm..... ugghhhhhhhhh... gerroffff.... uuuuuuuh hhhhhhh hhhh!

[HankWangford]

Hank, the event should just call another webmethod on the same service using a single key/id.

I'm working around this by using simple hyperlinks that pass arguments on the target URI for now - e.g. "mypage.aspx?method=this&arg=that"

That works fine, except that I need to handle the 'event' call myself in Page_Load(), and it rather seems to defeat all this ASP.NET, server control cleverness.

Surely, this is a very basic thing to do. Why are trivial, simple things so hard with ASP.NET 2?

What are you doing with the next webmethod, handing off to another page or deleting data or????? If it's just a simple call which the webmethod acts on and returns nothing then I would use an ajax call negating the need for a postback but depends on what you doing........

[mcquiggd]

Having read the later posts you are probably attempting something that can be achieved in a much simpler way... need a bit more detail as to what you are trying to do with the data (e.g. update the records you originally returned from the first web service call?)...

If you have a Generic List of objects - or an Array - and are not updating them 'in page' but just want to return an ID to an event handler to do something, id probably just bind them to a Repeater, and in the ItemTemplate, write some HTML for formatting, and include some Buttons with Command Names and Arguments and specify their OnClick property as a method in your Code Behind file, which would look at the CommandName and CommandArguement properties (the former would be something like 'Delete', the later an ID such as '2'.

You don't need to rebind any events or recreate controls.

Heres a quick example of the above - I havent bothered with the CommandName as it is not required in a 'single button per row' scenario - if you need a more complex example let me know.

Code is available here: http://mcquiggd.drivehq.com/WebApplication1.zip

In your ASP.Net page:

       <asp:Repeater ID="repeater1" runat="server">
        
        <ItemTemplate>
        
            <!-- Add whatever HTML formatting you want here -->
            <div>
                <asp:Button ID="DeleteButton" runat="server" OnClick="DeleteButton_Click" CommandArgument='<%# Eval ("ObjectID") %>' Text = '<%# Eval ("ObjectID") %>'/>
            </div>
        </ItemTemplate>
    
    </asp:Repeater>

In your code behind:

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI.WebControls;


namespace WebApplication1
{
    public partial class _Default : System.Web.UI.Page
    {


        //Simple class to hold some data to bind to
        public class MyObject
        {
            private int _objectID;

            public MyObject(int objectID)
            {
                _objectID = objectID;
            }

            public int ObjectID
            {
                get
                {
                    return _objectID;
                }
            }
        }


        protected void Page_Load(object sender, EventArgs e)
        {
            //Add some sample data
            if (!IsPostBack)
            {
                //Create a generic List of objects
                List<MyObject> mcquiggdsObjects = new List<MyObject>();
                
                for (int i=1; i <10; i++)
                {
                    mcquiggdsObjects.Add(new MyObject(i));
                }

                //Only bind them to the repeater the first time
                //the page is called. On subsequent calls ViewState will
                //be used to rebuild the Repeater
                repeater1.DataSource = mcquiggdsObjects;
                repeater1.DataBind();
            }
        }


        //This is the bit that is of interest to you.
        //An event handler that will be fired by a click on any instance
        //of the button within the Repeater.
        protected void DeleteButton_Click(object sender, EventArgs e)
        {
            Button deleteButton = (Button)sender;

            Response.Write(String.Format("You want to delete Object {0} <br/>", deleteButton.CommandArgument));

            //Do whatever you need to do as you now have access to the ObjectID through the CommandArgument

        }
    }        
}

You can include other ASP.Net controls such as Image, Checkbox, within the ItemTemplate and bind their relevant Properties to those exposed by your Business Objects, using the same syntax as in the example above. Just wrap the Control declarations in <div> and <span> tags and handle layout with CSS classes, or wrap a table declaration around the Repeater and inside it add <tr> and <td> tags if you want it 'quick and dirty'.

Note the comment about how ViewState is used to rebuild the Repeater on subsequent postbacks. This is basically the Control Values, not the Object itself, so you wont be able to reconstruct the original Object in the event handler (there are ways round this, however).

Keep an eye on the size of the ViewState, and optionally consider using alternative Cacheing methods if you do need to reference the original Object.

[HankWangford]

Having read the later posts you are probably attempting something that can be achieved in a much simpler way... need a bit more detail as to what you are trying to do with the data (e.g. update the records you originally returned from the first web service call?)...

If you have a Generic List of objects - or an Array - and are not updating them 'in page' but just want to return an ID to an event handler to do something, id probably just bind them to a Repeater, and in the ItemTemplate, write some HTML for formatting, and include some Buttons with Command Names and Arguments and specify their OnClick property as a method in your Code Behind file, which would look at the CommandName and CommandArguement properties (the former would be something like 'Delete', the later an ID such as '2'.

You don't need to rebind any events or recreate controls.

Heres a quick example of the above - I havent bothered with the CommandName as it is not required in a 'single button per row' scenario - if you need a more complex example let me know.

Code is available here: http://mcquiggd.drivehq.com/WebApplication1.zip

In your ASP.Net page:

       <asp:Repeater ID="repeater1" runat="server">
        
        <ItemTemplate>
        
            <!-- Add whatever HTML formatting you want here -->
            <div>
                <asp:Button ID="DeleteButton" runat="server" OnClick="DeleteButton_Click" CommandArgument='<%# Eval ("ObjectID") %>' Text = '<%# Eval ("ObjectID") %>'/>
            </div>
        </ItemTemplate>
    
    </asp:Repeater>

In your code behind:

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI.WebControls;


namespace WebApplication1
{
    public partial class _Default : System.Web.UI.Page
    {


        //Simple class to hold some data to bind to
        public class MyObject
        {
            private int _objectID;

            public MyObject(int objectID)
            {
                _objectID = objectID;
            }

            public int ObjectID
            {
                get
                {
                    return _objectID;
                }
            }
        }


        protected void Page_Load(object sender, EventArgs e)
        {
            //Add some sample data
            if (!IsPostBack)
            {
                //Create a generic List of objects
                List<MyObject> mcquiggdsObjects = new List<MyObject>();
                
                for (int i=1; i <10; i++)
                {
                    mcquiggdsObjects.Add(new MyObject(i));
                }

                //Only bind them to the repeater the first time
                //the page is called. On subsequent calls ViewState will
                //be used to rebuild the Repeater
                repeater1.DataSource = mcquiggdsObjects;
                repeater1.DataBind();
            }
        }


        //This is the bit that is of interest to you.
        //An event handler that will be fired by a click on any instance
        //of the button within the Repeater.
        protected void DeleteButton_Click(object sender, EventArgs e)
        {
            Button deleteButton = (Button)sender;

            Response.Write(String.Format("You want to delete Object {0} <br/>", deleteButton.CommandArgument));

            //Do whatever you need to do as you now have access to the ObjectID through the CommandArgument

        }
    }        
}

You can include other ASP.Net controls such as Image, Checkbox, within the ItemTemplate and bind their relevant Properties to those exposed by your Business Objects, using the same syntax as in the example above. Just wrap the Control declarations in <div> and <span> tags and handle layout with CSS classes, or wrap a table declaration around the Repeater and inside it add <tr> and <td> tags if you want it 'quick and dirty'.

Note the comment about how ViewState is used to rebuild the Repeater on subsequent postbacks. This is basically the Control Values, not the Object itself, so you wont be able to reconstruct the original Object in the event handler (there are ways round this, however).

Keep an eye on the size of the ViewState, and optionally consider using alternative Cacheing methods if you do need to reference the original Object.

or use the PageStatePersister......keep viewstate bulk serverside, client simply holds a key to the data, OK if your not web farming

[mcquiggd]

Yup.. you can stick ViewState in several places

All depends on the usual variables you need to consider... performance, scalability, client 'profile' (e.g are most of your users still on 56k dialup)...

[mcquiggd]

Personally I find ASP.Net, especially version 2, to be very flexible.. and I have created, and continue to create, some pretty complex web front ends...

HttpHandlers, HttpModules, ObjectDataSources, Control Adaptors.... it's still evolving but it's pretty powerful stuff.

It's quite intimidating at first when you realise the scale of what is on offer with .Net 2 / ASP.Net 2 ... Microsoft have created some useful controls for most common scenarios, but it's possible and often preferable to either build upon them or bypass them and go directly to the framework underneath.

[AtW]

Personally I find ASP.Net, especially version 2, to be very flexible.. and I have created, and continue to create, some pretty complex web front ends...

That just proves you have bad taste...

[mcquiggd]

Oh no it doesn't.....

[HankWangford]

Personally I find ASP.Net, especially version 2, to be very flexible.. and I have created, and continue to create, some pretty complex web front ends...

HttpHandlers, HttpModules, ObjectDataSources, Control Adaptors.... it's still evolving but it's pretty powerful stuff.

It's quite intimidating at first when you realise the scale of what is on offer with .Net 2 / ASP.Net 2 ... Microsoft have created some useful controls for most common scenarios, but it's possible and often preferable to either build upon them or bypass them and go directly to the framework underneath.

I'm with you mc, never enjoyed working with a dev env so much, or been paid so much......dual benefits

Add in the yui and yui-ext and I cant contain myself

[TheMonkey]

Nice for the devs, crap for standards and the web is supposed to be stateless.

I hate the bastard who decided to deliver applications via the web - that should have been the niche for java applets etc.

Emulating everything is so unreliable.