[Catalyst]

The new cross page postbacks are handy but my first attempt to use them resulted in null objects when I'd try to use PreviousPage.FindControl()

After no luck finding anything on the web I messed around a bit and found that if your original page uses Master pages then you have to work your way through a longer control hierarchy.

PreviousPage.Master.FindControl("contentplaceholder1").FindControl("whatiwant")

[marcamos]

Not to entirely dumb down this topic, but to those of us unfamiliar with ASP, what (in lamens terms) does this feature do or mean?

[Catalyst]

Short answer: It won't make much sense unless you do asp.net 2.0

Long answer:
Normally an asp.net page reloads itself when you interact with it in different ways, such as clicking a button. The button click even is then fired on the server and your code handles that event however you'd like.

So by default asp.net pages post their form data back to themselves and they maintain the status of all the controls on the page through these reloads.

For example in PHP, etc you might make an email form that send the data back to itself to check that everything is valid rather than posting the form straight to another page. You'd have to write some code for the page to reload all the form fields from the POST data if they needed to be corrected by the user. ASP.NET takes care of that automatically.

The more unusual thing to do in ASP.NET is to post the page's data to a different page, which is what the cross page postback allows you to do. You can then access information about all of the controls on the previous page.

Master pages is in a sense a way of templating a website without using include files.

The problem I ran into was that doing a cross page postback from a page that used a Master Page template, the controls were at a deeper level than normal so all the code samples out there didn't work.

[marcamos]

I'm shocked to say that I actually understand all that. In a slightly off-topic question, it appears you prefer asp.net over PHP. Is this true, or just the dev environment in this situation?

[Catalyst]

I always felt that classic ASP and PHP were about equal. PHP had some funny syntax I've never been crazy about but that's pretty minor.

When ASP.NET 1.0 came out I took a good look at it, read a book on it, and ultimately didn't really like it. When 2.0 came out I took another look and they'd changed so much about it and MS is going in such a better direction that it's a shame they're even called the same thing. I really like asp.net 2 and since my first site with it I haven't gone back.

It's not ASP.NET 2.0 specifically that I prefer over PHP/classic ASP. I think J2EE, ASP.NET, or Ruby on Rails are all comparable and all better.

[Karl Buckland]

Catalyst, on Oct 2 2006, 01:23 AM, said:

For example in PHP, etc you might make an email form that send the data back to itself to check that everything is valid rather than posting the form straight to another page. You'd have to write some code for the page to reload all the form fields from the POST data if they needed to be corrected by the user. ASP.NET takes care of that automatically.

But that realistically doesn't take more than 5 minutes does it? And you'll probably want to do some verification of that data anyway, so you'll be accessing those variables regardless?

I'm not going to get into a big PHP vs anything else debtate, but at the end of the day there are reasons for and against pretty much all of the different technologies available today. .NET, J2EE and Ruby on Rails all follow the MVC architecture (correct me if I'm wrong) and so in the long run that can make them easier to develop for, more scalable and more at an enterprise level. But I still prefer PHP .

[Catalyst]

Sirkent, on Oct 2 2006, 11:40 AM, said:

But that realistically doesn't take more than 5 minutes does it?

True, it was just a simple example.

Sirkent, on Oct 2 2006, 11:40 AM, said:

.NET, J2EE and Ruby on Rails all follow the MVC architecture (correct me if I'm wrong) and so in the long run that can make them easier to develop for, more scalable and more at an enterprise level. But I still prefer PHP .

The MVC model and stronger OOP really doesn't bear fruit until you're working on a certain complexity of site, and everyone's got their language preference of course - as you say they all have their good and bad. My personal interest just happens to be in the architected web application direction.