Mixing GET and POST generates inconsistence in URLS...

Hi to all,
I have an aesthetic problem to solve. I'm working on the managing part
of a site. Some pages can be called with a query string like this:
http://mysite.com/manage.aspx?code=300
The manage.aspx web form uses the view state, has some web controls that can
cause post back and so on: it's a classic POST web form. In that page
there's a navigation control that changes (virtually) the query string.
Virtually means that the query string is not actually changed but the web
form behaves as the query string was changed. Suppose that with the
manage.aspx you can manage a product: you can modify the product name, the
product description or you can navigate to a different product and manage
that different product maintaining the state of the page. All that can be
done by POST and not by GET. But initially the page has been called by using
a GET... and the query string remains "cross posting". In other words the
first call is made as above and the next posts could be related to different
products so the query string should disappear... But it remains there
creating the URL inconsistency that hurts me so much!
Is there anyone having a solution for my problem?
Thanks,
GabrieleIn most cases, the issue is how Page_Load is used. As an event, Page_Load is
an even to "Load a Page". I know this sounds "well, duh"-ish, but so many
people have code like so:
Page_Load()
{
if(!Page.IsPostback)
{
//Tons of Code here
}
else
{
//Tons of other code here
}
}
This is problematic, as the Page_Load is now handling part of the logic for
the postback events. For me, the first rule is Page_Load only loads the page
... period. Any POST event is handled by its event handler.
If you follow this, Page_Load can easily handle QueryString args, like so:
Page_Load()
{
if(!Page.IsPostback)
{
string qsArg = Request.QueryString("X");
if(qsArg!=String.Empty)
{
//This is set up from QS arg
}
else
{
//This is a raw form, with no QS arg
}
}
else
{
//No else, unless you have code that applies
//to EVERY postback
}
}
Hope this helps.
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
***************************
Think Outside the Box!
***************************
"Gabriele Zannoni" wrote:

> Hi to all,
> I have an aesthetic problem to solve. I'm working on the managing part
> of a site. Some pages can be called with a query string like this:
> http://mysite.com/manage.aspx?code=300
> The manage.aspx web form uses the view state, has some web controls that c
an
> cause post back and so on: it's a classic POST web form. In that page
> there's a navigation control that changes (virtually) the query string.
> Virtually means that the query string is not actually changed but the web
> form behaves as the query string was changed. Suppose that with the
> manage.aspx you can manage a product: you can modify the product name, the
> product description or you can navigate to a different product and manage
> that different product maintaining the state of the page. All that can be
> done by POST and not by GET. But initially the page has been called by usi
ng
> a GET... and the query string remains "cross posting". In other words the
> first call is made as above and the next posts could be related to differe
nt
> products so the query string should disappear... But it remains there
> creating the URL inconsistency that hurts me so much!
> Is there anyone having a solution for my problem?
> Thanks,
> Gabriele
>
>
You're right. The structure of my pages is as you said, the problem is
another.
The first time I call a page there are some params in the query string like:
http://mysite.com/manage.aspx?code=300
I press a button on the page that causes a postback; after the roundtrip the
url in the browser contains the same query string
(http://mysite.com/manage.aspx?code=300) but it's no more significant
because that "code" value should have been changed during the postback. So,
what I want is to have, after the postback, my browser connected to
http://mysite.com/manage.aspx. Is that a bad idea?
Thank you for your response,
Gabriele
"Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@.comcast.netNoSpamM> wrote
in message news:B237FE20-F621-4568-B2CD-98F729F89D62@.microsoft.com...
> In most cases, the issue is how Page_Load is used. As an event, Page_Load
is
> an even to "Load a Page". I know this sounds "well, duh"-ish, but so many
> people have code like so:
> Page_Load()
> {
> if(!Page.IsPostback)
> {
> //Tons of Code here
> }
> else
> {
> //Tons of other code here
> }
> }
> This is problematic, as the Page_Load is now handling part of the logic
for
> the postback events. For me, the first rule is Page_Load only loads the
page
> ... period. Any POST event is handled by its event handler.
> If you follow this, Page_Load can easily handle QueryString args, like so:
> Page_Load()
> {
> if(!Page.IsPostback)
> {
> string qsArg = Request.QueryString("X");
> if(qsArg!=String.Empty)
> {
> //This is set up from QS arg
> }
> else
> {
> //This is a raw form, with no QS arg
> }
> }
> else
> {
> //No else, unless you have code that applies
> //to EVERY postback
> }
> }
> Hope this helps.
> --
> Gregory A. Beamer
> MVP; MCP: +I, SE, SD, DBA
> ***************************
> Think Outside the Box!
> ***************************
> "Gabriele Zannoni" wrote:
>
part
can
web
the
manage
be
using
the
different