By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,357 Members | 1,021 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,357 IT Pros & Developers. It's quick & easy.

breaking the model

P: n/a
Hi,

A newcomer to .Net (I've held out as long as I can.).
I am using VS.Net 2003.
I am writing some web apps and I am confronted with the usual issues that
one faces when coming from a Windows, Apache, Mysql, PHP (WAMP) background.

Is it a common practice, or even acceptable, to insert addition form tags to
avoid the issues of passing form data to another webform, triggering
validator controls for unrelated input controls, etc. ?

Any comments, welcome.
Mike

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 17 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a

"Spam Catcher" <sp**********@rogers.com> wrote in message
news:Xn*********************************@127.0.0.1 ...
"Mike Gaab" <mi****@montana.com> wrote in
news:11*************@spool6-east.superfeed.net:
Is it a common practice, or even acceptable, to insert addition form
tags to avoid the issues of passing form data to another webform,
triggering validator controls for unrelated input controls, etc. ?
I don't really understand what you're saying here. An ASP.NET application
usually has only 1 FORM tag per page. I have never needed more than 1 form
tag.


Does this mean your webpages have only one submit button per page?
You decide what to do with the data on the page during PostBack : )


Coming from the WAMP world, that is trivial.

Additional comment:
I am just not used to being limited to one form per page and how
ASP.Net passes form data to another webform page. For example,
since ASP.Net is emulating the desktop event model, one has to use things
like Server.Transfer to get form data to another page. This just seems a
little clunky. On the other hand, ASP.Net does some really clever stuff that
I enjoy very much.

Mike


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 17 '05 #2

P: n/a
Hi Mike,

The ASP.Net object model is designed to work something like a Windows Form,
and emulate state as well as events by various mechanisms, such as PostBack
(the WebForm submitting to itself), ViewState, and so on. As HTTP is
stateless, there is a rather substantial infrastructure to support this
emulation.

It is really quite elegant, all things considered. So, if you can get your
head around the object model, you can see that Server.Transfer and
Response.Redirect are more in line with that object model. The browser
represents the interface, and the server is the business logic that drives
it. Now, that said, it is certainly possible to add an additional,
non-server form to a page, and have that form post to another ASP.Net page
in the same application. However, this more or less breaks the object model,
as anything outside the WebForm is not a Server Control, and does not follow
the object model. Having another form on a page is sometimes useful for
posting to another Application or Domain, but other than that, I think that
once you get used to the ASP.Net object model, it will "click" and you will
feel quite comfortable with it.

There is something to be said for convention. It provides common ground, and
eliminates the necessity to remember a variety of different methodologies,
as well as making development in a team, or taking on work from another
developer much easier (less of a learning curve). I would suggest you stick
with it, and see if you don't grow to like it a lot.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

"Mike Gaab" <mi****@montana.com> wrote in message
news:11*************@spool6-east.superfeed.net...
Hi,

A newcomer to .Net (I've held out as long as I can.).
I am using VS.Net 2003.
I am writing some web apps and I am confronted with the usual issues that
one faces when coming from a Windows, Apache, Mysql, PHP (WAMP)
background.

Is it a common practice, or even acceptable, to insert addition form tags
to avoid the issues of passing form data to another webform, triggering
validator controls for unrelated input controls, etc. ?

Any comments, welcome.
Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet
News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption
=----

Dec 17 '05 #3

P: n/a

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Om**************@TK2MSFTNGP12.phx.gbl...
Hi Mike,

The ASP.Net object model is designed to work something like a Windows
Form, and emulate state as well as events by various mechanisms, such as
PostBack (the WebForm submitting to itself), ViewState, and so on. As HTTP
is stateless, there is a rather substantial infrastructure to support this
emulation.

It is really quite elegant, all things considered. So, if you can get your
head around the object model, you can see that Server.Transfer and
Response.Redirect are more in line with that object model. The browser
represents the interface, and the server is the business logic that drives
it. Now, that said, it is certainly possible to add an additional,
non-server form to a page, and have that form post to another ASP.Net page
in the same application. However, this more or less breaks the object
model, as anything outside the WebForm is not a Server Control, and does
not follow the object model. Having another form on a page is sometimes
useful for posting to another Application or Domain, but other than that,
I think that once you get used to the ASP.Net object model, it will
"click" and you will feel quite comfortable with it.

There is something to be said for convention. It provides common ground,
and eliminates the necessity to remember a variety of different
methodologies, as well as making development in a team, or taking on work
from another developer much easier (less of a learning curve). I would
suggest you stick with it, and see if you don't grow to like it a lot.


Hi Kevin,

Yeah, I agree.

A few questions...

When I use Server.Transfer( "some.aspx") or
Server.Transfer("some.aspx", true), there doesn't seem to be any difference
in functionality. The docs say that the boolean preserves form and query
string data from the calling webform but I can still get at the form data by
either using the Request object or by getting a reference of the calling
webform via the Context.Handler property
and calling the appropriate get method(s).

The docs also say that Server.Transfer stops execution of the previous
webform. If that is the case, then how can I can a reference to it? I guess
I am thinking that stopping execution is
equivalent to destroy.

One last thing, the URL in the browser still points to the calling
webform page.

Please explain. Thanks.

Mike

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 17 '05 #4

P: n/a
Sure Mike,
When I use Server.Transfer( "some.aspx") or
Server.Transfer("some.aspx", true), there doesn't seem to be any
difference in functionality. The docs say
Yes, the docs are a bit confusing. Setting the second parameter to false is
what clears the Collections.

The docs also say that Server.Transfer stops execution of the previous webform. If that is the case, then how can I can a reference to it? I
guess I am thinking that stopping execution is
equivalent to destroy.
Exactly. It stops the previous Page class from continuing its execution. The
class is not destroyed. The difference is that the previous page is no
longer processing the Request. You have "transferred" execution to the new
Page class.
One last thing, the URL in the browser still points to the calling
webform page.
That is true, and correct. Server.Transfer is a server-side transfer of
execution. The execution of the HTTP Request is handed off to another Page
class. The Request is not changed. The difference between Server.Transfer
and Response.Redirect, is that Response.Redirect actually sends a Response
back to the client browser, telling it to request another URL. Therefore,
the URL of the Request changes, as it is actually a second Request from the
client. Server.Transfer only changes the server-side handler of the current
HTTP Request.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

"Mike Gaab" <mi****@montana.com> wrote in message
news:11*************@spool6-east.superfeed.net...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Om**************@TK2MSFTNGP12.phx.gbl...
Hi Mike,

The ASP.Net object model is designed to work something like a Windows
Form, and emulate state as well as events by various mechanisms, such as
PostBack (the WebForm submitting to itself), ViewState, and so on. As
HTTP is stateless, there is a rather substantial infrastructure to
support this emulation.

It is really quite elegant, all things considered. So, if you can get
your head around the object model, you can see that Server.Transfer and
Response.Redirect are more in line with that object model. The browser
represents the interface, and the server is the business logic that
drives it. Now, that said, it is certainly possible to add an additional,
non-server form to a page, and have that form post to another ASP.Net
page in the same application. However, this more or less breaks the
object model, as anything outside the WebForm is not a Server Control,
and does not follow the object model. Having another form on a page is
sometimes useful for posting to another Application or Domain, but other
than that, I think that once you get used to the ASP.Net object model, it
will "click" and you will feel quite comfortable with it.

There is something to be said for convention. It provides common ground,
and eliminates the necessity to remember a variety of different
methodologies, as well as making development in a team, or taking on work
from another developer much easier (less of a learning curve). I would
suggest you stick with it, and see if you don't grow to like it a lot.


Hi Kevin,

Yeah, I agree.

A few questions...

When I use Server.Transfer( "some.aspx") or
Server.Transfer("some.aspx", true), there doesn't seem to be any
difference in functionality. The docs say that the boolean preserves form
and query string data from the calling webform but I can still get at the
form data by either using the Request object or by getting a reference of
the calling webform via the Context.Handler property
and calling the appropriate get method(s).

The docs also say that Server.Transfer stops execution of the previous
webform. If that is the case, then how can I can a reference to it? I
guess I am thinking that stopping execution is
equivalent to destroy.

One last thing, the URL in the browser still points to the calling
webform page.

Please explain. Thanks.

Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet
News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption
=----

Dec 18 '05 #5

P: n/a

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Sure Mike,
When I use Server.Transfer( "some.aspx") or
Server.Transfer("some.aspx", true), there doesn't seem to be any
difference in functionality. The docs say
Yes, the docs are a bit confusing. Setting the second parameter to false
is what clears the Collections.


So the default setting is true, is that is why setting it true seems to have
no effect?


The docs also say that Server.Transfer stops execution of the previous
webform. If that is the case, then how can I can a reference to it? I
guess I am thinking that stopping execution is
equivalent to destroy.
Exactly. It stops the previous Page class from continuing its execution.
The class is not destroyed. The difference is that the previous page is no
longer processing the Request. You have "transferred" execution to the new
Page class.
One last thing, the URL in the browser still points to the calling
webform page.


That is true, and correct. Server.Transfer is a server-side transfer of
execution. The execution of the HTTP Request is handed off to another Page
class. The Request is not changed.


The forms data then is in the Request object. Is using the Request object
a better solution than setting up the calling object to transfer the data
via
a series of get calls? Or is it just a matter of preference?
The difference between Server.Transfer and Response.Redirect, is that
Response.Redirect actually sends a Response back to the client browser,
telling it to request another URL. Therefore, the URL of the Request
changes, as it is actually a second Request from the client.
Server.Transfer only changes the server-side handler of the current HTTP
Request.


Do you know if that causes any confusion for users? Using Redirect seems
to be a little inefficient?

Thanks, Mike


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 18 '05 #6

P: n/a
Hi Mike,
So the default setting is true, is that is why setting it true seems to
have
no effect?
Correct.
The forms data then is in the Request object. Is using the Request object
a better solution than setting up the calling object to transfer the data
via
a series of get calls? Or is it just a matter of preference?
I'm having a little trouble understanding this one. Yes, the posted form
data is in the Request object. The Request object is created by parsing an
HTTP Request; in this case, the form POST Request from the Page.

Now, where I'm somewhat fuzzy is with the second part of the question. What
do you mean by "the calling object?" What do you mean by "setting up the
calling object to transfer data via a series of get calls?" Perhaps I can
explain a little bit (?) more of the technical aspect of this and answer
your question without understanding it fully.

The ASP.Net object model works in an HTTP environment. HTTP is a series of
client Requests and server Responses, kind of like a conversation between
client and server. But due to the stateless nature of HTTP, neither the
client nor the server can remember that previous message, or even that a
previous message was sent. Every HTTP Request/Response occurs "in a vacuum,"
so to speak. This is the primary reason why ASP.Net applications are
problematic to write. You want the server to have some memory of the context
of what is being done, in order to behave like an application. The way that
Microsoft has addressed this issue is via a set of mechanisms to emulate
state, and to maintain server state.

State can indeed be maintained on the server, in memory, in a database, via
any number of storage mechanisms. The trick is to associate the state with
each client, as the clients' Requests are not remembered after each Response
is sent. So, Application state, being global to the Application, is not a
problem. But client state is. The way that client state is maintained is
basically two-fold.

One is the use of the Request coming from the client. An HTTP Request can
include a certain amount of header data, QueryString data in the URL, form
data in form fields sent via POST, and any Cookies for that domain stored on
the client. The server can set cookies, which are returned with the
Response, and it can read the Cookies which are always included in the
client Request. Now, some Cookies are persistent, having an expiration
date/time in them, which causes them to be stored on the client's hard
drive. But Cookies without an expiration are referred to as "Session
Cookies." By default, they are stored only in the memory of the browser, and
expire when the browser navigates away from the web site, or closes. Many
browsers do not allow persistent Cookies, but most browsers do allow Session
Cookies. So, the first Request from the client causes the server to create a
memory space for that client, in a Collection stored in the Application,
which is called a Session. The Session is assigned a unique ID, and that ID
is sent as a Session Cookie to the client browser. From there, as long as
the client continues to send Requests, the Cookie makes round trips with
each Request/Response. Since the server is never notified that the client is
no longer there, it waits for 20 minutes for a Request, and if no Request is
received during that interval, it deletes the Session for that client,
freeing up memory on the server.

The other method for maintaining State is to pass data to the client, and
receive it back via Query String or form POST. Hence, you have the PostBack
model. This includes not only the form fields created by the Controls you
put into the page, but several hidden form fields, including a hidden form
field called "ViewState" that keeps track of the state of the Controls when
the last Response was sent to the client. When the user makes changes to the
form fields on the client, the values of these form fields are posted with
the Request, and the server compares them to the ViewState data to see what
has changed, and possibly respond to it.

Events are created by adding some JavaScript client-side event handlers that
put data into a couple of other hidden form fields, and then post the form
to the server. The server-side app looks at these hidden form fields to find
out what client-side events have occurred, and creates real server-side
Events to react to them.

All of this is built into the ASP.Net object model, and though you should be
aware of it, you generally don't have to think much about it; it handles
itself. It is important, though, to understand the object model, as well as
how HTTP works, in order to make intelligent choices about what to code on
the server.

So, now, we have the HTTP Request/Response, and we have 2
indirectly-connected applications, one on the client (the browser and the
HTML document loaded into it), and one on the server. It is the one on the
server that I want to discuss now, in order to hopefully answer your
question. Now, once the Request is received from the client, we are no
longer talking about Pages and Requests, and all that other client-side web
stuff; we are talking about a server application, which behaves on the
server just like any other application. Event though you have a class called
"System.Web.UI.Page," it isn't a "page" at all, or a document even. It is a
class. It is an executable business component. Any other System.Web.UI.Page
class on the server is also not a document, but a business entity in the
application. So, when you use Server.Transfer, you are simply calling on
another class to finish processing. You are transferring execution control
to another class.

Now, the Request object, as I said, is parsed from the HTTP Request received
from the client. It is not the same as the HTTP Request itself, which is
simply a text document. It is a class that contains data and process. The
data has been extracted from the HTTP Request, and the process is executable
code that can manipulate the data. It is the same with the HttpContext. The
HttpContext is a class that contains data and process extracted from the
HTTP Request, and from the web server. HTTP is no loger part of the
equation. The HTTP Request was sent, received from the client, parsed, and
classes were built from it. It then went the way of all flesh, disappearing
into the void. HTTP will not be a part of the equation again until the
server-side application hands off the finished HTML document, as a stream
containing text, to the web server again. At that point, the web server will
create an HTTP Response message to the client.

So, it's best to remember that, although these classes have names, and use
terms that are reminiscent of HTTP, they are not, in fact, doing anything at
all with HTTP. They are simply an application processing data.

Now, how does Response.Redirect work? Simple. Rather than creating a full
HTML document, an HTTP Response with a "302" Status code is formed. The
"302" Status code indicates that a resource has moved temporarily to another
URL, and the Response header contains the other URL to Request. Again,
however, the Page class itself doesn't send the Response. It simply creates
it and hands it off to the web server.

So, on the server-side, there is no such thing as "transfer the data via a
series of get calls" on the server. There is no HTTP operating in the
ASP.Net application. When using Server.Transfer, program execution is simply
transferred to another class.

Now, as to when to use Response.Redirect, and when to use Server.Tranfer,
well, you know of one reason already. The URL of the browser changes to the
new Page URL if you use Response.Redirect. This is useful when you want to
treat the second Page class as if it is really another web page. Rembmber
that on the client, it *is* another web page. Using Server.Transfer, on the
other hand, is useful if you want to treat the HTML output of the second
Page class as if it was indeed part of the first Page, which was requested
by the client.

As for performance issues, yes, there is another Round-trip involved with
Response.Redirect, but there are also any number of Round-trips associated
with the PostBack model. ASP.Net is designed to optimize server resources as
much as possible under this scenario. The only real issue is latency on the
client. But again, a Redirect Response is a very small HTTP message. In
other words, I wouldn't be concerned about it. I would be concerned instead
with which method is most appropriate in terms of how you want the app to
work.

Whew! I hope that helped!
Do you know if that causes any confusion for users? Using Redirect seems
to be a little inefficient?
After reading my explanation, I hope you can see why I said that the
"inefficiency" of using Response.Redirect should not be an issue. In fact,
you have put your finger on the button with this question. How do you want
the client user to perceive the Responses sent by your app?

Think of the client browser as a user interface, and the server-side app as
a set of business objects that interact with it remotely. Your goal, in
terms of the user interface, is to make it user-friendly. If you keep that
in mind, I don't think you'll have any trouble figuring out what to use and
when.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

"Mike Gaab" <mi****@montana.com> wrote in message
news:11*************@spool6-east.superfeed.net...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Sure Mike,
When I use Server.Transfer( "some.aspx") or
Server.Transfer("some.aspx", true), there doesn't seem to be any
difference in functionality. The docs say


Yes, the docs are a bit confusing. Setting the second parameter to false
is what clears the Collections.


So the default setting is true, is that is why setting it true seems to
have
no effect?


The docs also say that Server.Transfer stops execution of the previous
webform. If that is the case, then how can I can a reference to it? I
guess I am thinking that stopping execution is
equivalent to destroy.


Exactly. It stops the previous Page class from continuing its execution.
The class is not destroyed. The difference is that the previous page is
no longer processing the Request. You have "transferred" execution to the
new Page class.
One last thing, the URL in the browser still points to the calling
webform page.


That is true, and correct. Server.Transfer is a server-side transfer of
execution. The execution of the HTTP Request is handed off to another
Page class. The Request is not changed.


The forms data then is in the Request object. Is using the Request object
a better solution than setting up the calling object to transfer the data
via
a series of get calls? Or is it just a matter of preference?
The difference between Server.Transfer and Response.Redirect, is that
Response.Redirect actually sends a Response back to the client browser,
telling it to request another URL. Therefore, the URL of the Request
changes, as it is actually a second Request from the client.
Server.Transfer only changes the server-side handler of the current HTTP
Request.


Do you know if that causes any confusion for users? Using Redirect seems
to be a little inefficient?

Thanks, Mike


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet
News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption
=----

Dec 18 '05 #7

P: n/a

"Spam Catcher" <sp**********@rogers.com> wrote in message
news:Xn**********************************@127.0.0. 1...
"Mike Gaab" <mi****@montana.com> wrote in
news:11*************@spool6-east.superfeed.net:
Does this mean your webpages have only one submit button per page?
No, you can have multiple submit buttons. Each submit button raises it's
own event handler.


Thanks, I totally overlooked that. I am still thinking as if I am
in the WAMP world.
Additional comment:
I am just not used to being limited to one form per page and how
ASP.Net passes form data to another webform page. For example,
since ASP.Net is emulating the desktop event model, one has to use
things like Server.Transfer to get form data to another page. This
just seems a little clunky. On the other hand, ASP.Net does some
really clever stuff that I enjoy very much.


Take a look at HTTPContext variables - they allow you to transfer data
from one page to another.


Like the Request object?
In most cases, you don't redirect directly to a second page in ASP.NET.


When you say "directly", are you referring to a form's action attribute?

Mike


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 18 '05 #8

P: n/a

"Spam Catcher" <sp**********@rogers.com> wrote in message
news:Xn**********************************@127.0.0. 1...
"Mike Gaab" <mi****@montana.com> wrote in
news:11*************@spool6-east.superfeed.net:
Take a look at HTTPContext variables - they allow you to transfer data
from one page to another.


How about a simple example...

Mike

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 18 '05 #9

P: n/a

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:ui*************@TK2MSFTNGP11.phx.gbl...
I'm having a little trouble understanding this one. Yes, the posted form
data is in the Request object. The Request object is created by parsing an
HTTP Request; in this case, the form POST Request from the Page.

Now, where I'm somewhat fuzzy is with the second part of the question.
What do you mean by "the calling object?" What do you mean by "setting up
the calling object to transfer data via a series of get calls?"


this is where i got the idea
http://www.codeproject.com/aspnet/Da...ingBtPages.asp
A WAMP scenrio:

1. User fills out an html form that contains a single textbox on Page A

2. Submits the html form on Page A to the server specifying the
SimpleAddition app to process the single textbox value.

3. The SimpleAddition app adds the value to itself and then returns that
value to the browser in Page B (with the browser showing that Page B was
returned).

How would you accomplish this simple task in webforms?

Thanks,
Mike

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 19 '05 #10

P: n/a

"Spam Catcher" <sp**********@rogers.com> wrote in message
news:Xn*********************************@127.0.0.1 ...
"Mike Gaab" <mi****@montana.com> wrote in news:1134940437_4343@spool6-
east.superfeed.net:
Take a look at HTTPContext variables - they allow you to transfer data
from one page to another.


How about a simple example...


Here you go:

http://aspnet.4guysfromrolla.com/articles/060904-1.aspx


Thanks.
Mike

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 19 '05 #11

P: n/a

"Spam Catcher" <sp**********@rogers.com> wrote in message
news:Xn*********************************@127.0.0.1 ...
"Mike Gaab" <mi****@montana.com> wrote in news:1134961425_4863@spool6-
east.superfeed.net:
How would you accomplish this simple task in webforms?


http://aspnet.4guysfromrolla.com/articles/060904-1.aspx

HTTPContext Items.


Thanks again.
An aside, I think MS's docs are harder to follow than a form
like Javadocs.

Mike

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 19 '05 #12

P: n/a
Hi Mike,

I'm not sure what "the SimpleAddition app" is supposed to be. In following
your message, keeping the HTTP environment in mind, I derived the following
scenario:

1. Browser requests Page A by its URL.
2. User submits form on Page A. The URL for this form action attribute is ?
3. The "SimpleAdditionApp" processes the request.
4. Page B is returned to the browser, showing Page b's URL.

Now, according to this scenario, you have 2 possibilities:

1. The URL for the "SimpleAdditionApp" is the URL for Page B.
2. The URL for the "SimpleAdditionApp" is not the URL for Page B. The
"SimpleAdditionApp" redirects the browser to Page B.

Now, in both cases, you could certainly do this with .Net.
"TheSimpleAdditionApp" sounds like a class for doing math. If so, it could
be housed in its own Page, or it could be a business class that any Page
could use.

Using the ASP.Net PostBack event model, Page A would submit to itself. It
would then call on the "SimpleAdditionApp" class to do the processing. It
would then either store the resulting data in Session State, or Redirect to
Page B with a QueryString containing the result.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

"Mike Gaab" <mi****@montana.com> wrote in message
news:11*************@spool6-east.superfeed.net...

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:ui*************@TK2MSFTNGP11.phx.gbl...
I'm having a little trouble understanding this one. Yes, the posted form
data is in the Request object. The Request object is created by parsing
an HTTP Request; in this case, the form POST Request from the Page.

Now, where I'm somewhat fuzzy is with the second part of the question.
What do you mean by "the calling object?" What do you mean by "setting up
the calling object to transfer data via a series of get calls?"


this is where i got the idea
http://www.codeproject.com/aspnet/Da...ingBtPages.asp
A WAMP scenrio:

1. User fills out an html form that contains a single textbox on Page A

2. Submits the html form on Page A to the server specifying the
SimpleAddition app to process the single textbox value.

3. The SimpleAddition app adds the value to itself and then returns that
value to the browser in Page B (with the browser showing that Page B was
returned).

How would you accomplish this simple task in webforms?

Thanks,
Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet
News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption
=----

Dec 19 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.