M
Moheb Missaghi
Hi:
I am trying to use the Transfer statement in an .aspx file
to redirect
and send Form and QueryString collections to a different
page. A good
example where this is needed is a checkout page when you
click on the
Confirm button, and the client's shopping info (items,
amount, etc.)
have to be transferred to a credit card site. There are 3
requirements
here:
1. A bunch of server operations have to happen before the
redirection,
for example reset of the shopping cart, decrementing
the inventory,
writing to the order history, etc.
2. The page form has to be converted to that required by
the credit
card company.
3. A transfer statement to send the form contents to the
credit card
site.
Ideally, all of these have to happen in a single
transaction (all or
nothing). I started by trying the following on the server:
public void Confirm_Order(Object sender, EventArgs e)
{
ResetCart(username);
AddOrder(userame, time);
... code to create a form ...
Transfer(creditcardsite, true)
}
The shopping list was created by a Repeater control.
This seems concise, minimal and highlights the power
of .NET web forms
had it worked! Here are the problems I faced:
1. I couldn't find a way to change the contents of the
page form
(controls, values, etc.). There is no access provided
to a low
level http utility such as wininet (e.g. HINTERNET)
in .NET.
2. Once a page contains <% %> blocks, the form cannot be
changed
dynamically.
3. The overloaded Transfer method (public void Transfer
(string path,
bool preserveForm)) does not work because of the
ViewState
content. I tried clearing the ViewState, but that
didn't work
either. I like the power of ViewState, Web Form
philosophy, post
back, etc. and that all is implemented over the html
seemlessly but
it seems too hardcoded and inflexible. Considering that
the
ViewState is mainly implemented for a page at a time,
clearing it
prior to sending the control to another page should
work fine. The
only other way is to switch off ViewState in the
receiving page
(<%@ Page EnableViewState="false"
EnableViewStateMac="false" %>
which somewhat limits the receiving page. Also, I think
there is no
point of having two methods for the same functionality.
Redirect
and (public void Transfer(string path)) are the same
(at least
that's how it looks from the documentation).
4. OK so I disabled the ViewState in the receiving page
and could use
Transfer with preserveForm=true. I couldn't however
change the
clientIDs in the form (they are read onlies). Why
should this be? I
really like these server controls, but what difference
does it make
what specific html they produce as long as it all works?
At the end I had to do the following to get it to work
which is messy:
1. Re-wrote the checkout page with deleting the
runat="server" from
the form (runat="server" automatically forces the same
page to be
the action attribute of the rendered form). Put
action="gateway.aspx" where this is a page which does
all the
server actions prior to sending the the credit card
site.
2. Replaced the repeater with inline <% %> blocks to
create <input>
tags with names and values specified by the credit card
company
(the old ASP way).
3. Had to re-write other controls in the page which relied
on
runat="server" for the form to work in html.
4. Put all the server actions in Page_Load of the
gateway.aspx,
rerendered the form on this page by inlining and used
Javascript
onload to submit the form to the final page (credit
card site)
once it rendered.
This worked but was kind of disappointing. I love .NET and
its
powerful server programming functionalities but not at the
expense of
loosing control. Am I missing something?
Moheb
I am trying to use the Transfer statement in an .aspx file
to redirect
and send Form and QueryString collections to a different
page. A good
example where this is needed is a checkout page when you
click on the
Confirm button, and the client's shopping info (items,
amount, etc.)
have to be transferred to a credit card site. There are 3
requirements
here:
1. A bunch of server operations have to happen before the
redirection,
for example reset of the shopping cart, decrementing
the inventory,
writing to the order history, etc.
2. The page form has to be converted to that required by
the credit
card company.
3. A transfer statement to send the form contents to the
credit card
site.
Ideally, all of these have to happen in a single
transaction (all or
nothing). I started by trying the following on the server:
public void Confirm_Order(Object sender, EventArgs e)
{
ResetCart(username);
AddOrder(userame, time);
... code to create a form ...
Transfer(creditcardsite, true)
}
The shopping list was created by a Repeater control.
This seems concise, minimal and highlights the power
of .NET web forms
had it worked! Here are the problems I faced:
1. I couldn't find a way to change the contents of the
page form
(controls, values, etc.). There is no access provided
to a low
level http utility such as wininet (e.g. HINTERNET)
in .NET.
2. Once a page contains <% %> blocks, the form cannot be
changed
dynamically.
3. The overloaded Transfer method (public void Transfer
(string path,
bool preserveForm)) does not work because of the
ViewState
content. I tried clearing the ViewState, but that
didn't work
either. I like the power of ViewState, Web Form
philosophy, post
back, etc. and that all is implemented over the html
seemlessly but
it seems too hardcoded and inflexible. Considering that
the
ViewState is mainly implemented for a page at a time,
clearing it
prior to sending the control to another page should
work fine. The
only other way is to switch off ViewState in the
receiving page
(<%@ Page EnableViewState="false"
EnableViewStateMac="false" %>
which somewhat limits the receiving page. Also, I think
there is no
point of having two methods for the same functionality.
Redirect
and (public void Transfer(string path)) are the same
(at least
that's how it looks from the documentation).
4. OK so I disabled the ViewState in the receiving page
and could use
Transfer with preserveForm=true. I couldn't however
change the
clientIDs in the form (they are read onlies). Why
should this be? I
really like these server controls, but what difference
does it make
what specific html they produce as long as it all works?
At the end I had to do the following to get it to work
which is messy:
1. Re-wrote the checkout page with deleting the
runat="server" from
the form (runat="server" automatically forces the same
page to be
the action attribute of the rendered form). Put
action="gateway.aspx" where this is a page which does
all the
server actions prior to sending the the credit card
site.
2. Replaced the repeater with inline <% %> blocks to
create <input>
tags with names and values specified by the credit card
company
(the old ASP way).
3. Had to re-write other controls in the page which relied
on
runat="server" for the form to work in html.
4. Put all the server actions in Page_Load of the
gateway.aspx,
rerendered the form on this page by inlining and used
Javascript
onload to submit the form to the final page (credit
card site)
once it rendered.
This worked but was kind of disappointing. I love .NET and
its
powerful server programming functionalities but not at the
expense of
loosing control. Am I missing something?
Moheb