Layout Advice

[Steven Edison]

Hi,

Our company currently has a client/server based app. Now the need
has arisen to tap some of the functionality from a webpage. This
means the client will disappear and a subset of functionality will
be needed from the web.

Normally a user logs in from the client, then functionality will send
commands to the server to accomplish certain things.

I also have a traditional unmanaged COM object that wraps this
functionality for 3rd party developers to use.

//pseudo code
ServerConn conn = new ServerConn ();
int UserID = conn.Authenticate(UserName, Password);
if(UserID != -1)
{
//do some stuff
}
conn.Close();

Since there needs to be a user logged in, I'd like to tie the object
to a session. Here's the kicker. The "stuff" that needs to be done
needs to be done from JavaScript without postbacks. For example
clicking an arrow to move a camera. The movement of that camera
has to be tied to a "logged in" user. I had considered doing a
web service, but wasn't sure how that would maintain a logged in
user, then consume the web service within the JavaScript

So I need to be able to:

Connection [Server-Side Script]
Log In [Server-Side Script]
Perform functions with hardware [Client-Side JavaScript]
Close Connection [Server-Side Script]

I had also considered wrapping the client-side needs in a page,
and have the arrows, for example, call the page with XMLHttpRequest.
I also wasn't sure if that would use the same logged in session.

Thanks for the advice ahead of time.

Steven

 

[Cowboy \(Gregory A. Beamer\)]

I would consider using AJAX, as you can create the server side "appearance"
of a postback without going away from the client side JavaScript model. You
do not have to choose Microsoft's implementation, as there are open source
implementations, but I would consider the MS method first, as it is
supported directly in VS 2008.

 

[Michael Nemtsev [MVP]]

Hello Steven,

Ok, you have 2 choices
First is implementing ICallbackEventHandler which "hides" all your calls
to server, but there are a lot of manual jobs
Secord, rely on ajax, where everything implemented for you, even Logging
to the server - see http://www.asp.net/AJAX/Documentati...vices/AuthenticationServiceClass/default.aspx


Btw, to consumer services from javascript u recommed to rely on ajax and
JSON serialization - google to find more samples.
For example there u can find a good sample how to consume WCF services directly
from javascript http://msdn2.microsoft.com/en-us/library/bb514961.aspx

---
WBR,
Michael Nemtsev [.NET/C# MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo


SE> Hi,
SE>
SE> Our company currently has a client/server based app. Now the need
SE> has arisen to tap some of the functionality from a webpage. This
SE> means the client will disappear and a subset of functionality will
SE> be needed from the web.
SE>
SE> Normally a user logs in from the client, then functionality will
SE> send commands to the server to accomplish certain things.
SE>
SE> I also have a traditional unmanaged COM object that wraps this
SE> functionality for 3rd party developers to use.
SE>
SE> //pseudo code
SE> ServerConn conn = new ServerConn ();
SE> int UserID = conn.Authenticate(UserName, Password);
SE> if(UserID != -1)
SE> {
SE> //do some stuff
SE> }
SE> conn.Close();
SE>
SE> Since there needs to be a user logged in, I'd like to tie the object
SE> to a session. Here's the kicker. The "stuff" that needs to be done
SE> needs to be done from JavaScript without postbacks. For example
SE> clicking an arrow to move a camera. The movement of that camera
SE> has to be tied to a "logged in" user. I had considered doing a
SE> web service, but wasn't sure how that would maintain a logged in
SE> user, then consume the web service within the JavaScript
SE> So I need to be able to:
SE>
SE> Connection [Server-Side Script]
SE> Log In [Server-Side Script]
SE> Perform functions with hardware [Client-Side JavaScript]
SE> Close Connection [Server-Side Script]
SE> I had also considered wrapping the client-side needs in a page,
SE> and have the arrows, for example, call the page with XMLHttpRequest.
SE> I also wasn't sure if that would use the same logged in session.
SE> Thanks for the advice ahead of time.
SE>
SE> Steven
SE>

 

[Steven Edison]

Gregory,

Socket connections to the server would need to be initiated from the web
server.
I did a couple of sample AJAX webs, but still am not really that comfortable
with them, would the above be possible? There will be multiple sockets
needed to talk to the server to accomplish everything.

I don't really see how that COULD be possible, when the user clicks an arrow
a socket command would need to leave the webserver to go to our
application's
server.

Steven

I would consider using AJAX, as you can create the server side
"appearance" of a postback without going away from the client side
JavaScript model. You do not have to choose Microsoft's implementation, as
there are open source implementations, but I would consider the MS method
first, as it is supported directly in VS 2008.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box! |
*************************************************

Hi,

Our company currently has a client/server based app. Now the need
has arisen to tap some of the functionality from a webpage. This
means the client will disappear and a subset of functionality will
be needed from the web.

Normally a user logs in from the client, then functionality will send
commands to the server to accomplish certain things.

I also have a traditional unmanaged COM object that wraps this
functionality for 3rd party developers to use.

//pseudo code
ServerConn conn = new ServerConn ();
int UserID = conn.Authenticate(UserName, Password);
if(UserID != -1)
{
//do some stuff
}
conn.Close();

Since there needs to be a user logged in, I'd like to tie the object
to a session. Here's the kicker. The "stuff" that needs to be done
needs to be done from JavaScript without postbacks. For example
clicking an arrow to move a camera. The movement of that camera
has to be tied to a "logged in" user. I had considered doing a
web service, but wasn't sure how that would maintain a logged in
user, then consume the web service within the JavaScript

So I need to be able to:

Connection [Server-Side Script]
Log In [Server-Side Script]
Perform functions with hardware [Client-Side JavaScript]
Close Connection [Server-Side Script]

I had also considered wrapping the client-side needs in a page,
and have the arrows, for example, call the page with XMLHttpRequest.
I also wasn't sure if that would use the same logged in session.

Thanks for the advice ahead of time.

Steven

 

[Steven Edison]

Michael,

AJAX does the postbacks in pieces, right? instead of the
whole page? So my arrow would make a small post instead of
"full" page? And this would maintain everything within the same
session. Right?

Thanks for your help. I'll look into your links. It sounds like a good
fit.

Steven

Hello Steven,

Ok, you have 2 choices
First is implementing ICallbackEventHandler which "hides" all your calls
to server, but there are a lot of manual jobs
Secord, rely on ajax, where everything implemented for you, even Logging
to the server - see
http://www.asp.net/AJAX/Documentati...vices/AuthenticationServiceClass/default.aspx

Btw, to consumer services from javascript u recommed to rely on ajax and
JSON serialization - google to find more samples.
For example there u can find a good sample how to consume WCF services
directly from javascript
http://msdn2.microsoft.com/en-us/library/bb514961.aspx

---
WBR, Michael Nemtsev [.NET/C# MVP] :: blog:
http://spaces.live.com/laflour
"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

SE> Hi,
SE> SE> Our company currently has a client/server based app. Now the need
SE> has arisen to tap some of the functionality from a webpage. This
SE> means the client will disappear and a subset of functionality will
SE> be needed from the web.
SE> SE> Normally a user logs in from the client, then functionality will
SE> send commands to the server to accomplish certain things.
SE> SE> I also have a traditional unmanaged COM object that wraps this
SE> functionality for 3rd party developers to use.
SE> SE> //pseudo code
SE> ServerConn conn = new ServerConn ();
SE> int UserID = conn.Authenticate(UserName, Password);
SE> if(UserID != -1)
SE> {
SE> //do some stuff
SE> }
SE> conn.Close();
SE> SE> Since there needs to be a user logged in, I'd like to tie the
object
SE> to a session. Here's the kicker. The "stuff" that needs to be done
SE> needs to be done from JavaScript without postbacks. For example
SE> clicking an arrow to move a camera. The movement of that camera
SE> has to be tied to a "logged in" user. I had considered doing a
SE> web service, but wasn't sure how that would maintain a logged in
SE> user, then consume the web service within the JavaScript
SE> So I need to be able to:
SE> SE> Connection [Server-Side Script]
SE> Log In [Server-Side Script]
SE> Perform functions with hardware [Client-Side JavaScript]
SE> Close Connection [Server-Side Script]
SE> I had also considered wrapping the client-side needs in a page,
SE> and have the arrows, for example, call the page with XMLHttpRequest.
SE> I also wasn't sure if that would use the same logged in session.
SE> Thanks for the advice ahead of time.
SE> SE> Steven
SE>

 

[Michael Nemtsev [MVP]]

Hello Steven,

it's not the actual postback. it's callback to server, without sending all
page params
but it depends what are u using. UpdatePanels are fat and send all viewstates
and etc.
but manual postbacks are really light

---
WBR,
Michael Nemtsev [.NET/C# MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo


SE> Michael,
SE>
SE> AJAX does the postbacks in pieces, right? instead of the
SE> whole page? So my arrow would make a small post instead of
SE> "full" page? And this would maintain everything within the same
SE> session. Right?
SE> Thanks for your help. I'll look into your links. It sounds like a
SE> good fit.
SE>
SE> Steven
SE>
SE> SE>

Hello Steven,

Ok, you have 2 choices

First is implementing ICallbackEventHandler which "hides" all your
calls

to server, but there are a lot of manual jobs

Secord, rely on ajax, where everything implemented for you, even
Logging

to the server - see

http://www.asp.net/AJAX/Documentation/Live/ClientReference/Sys.Servic
es/AuthenticationServiceClass/default.aspx

Btw, to consumer services from javascript u recommed to rely on ajax
and
JSON serialization - google to find more samples.
For example there u can find a good sample how to consume WCF
services
directly from javascript
http://msdn2.microsoft.com/en-us/library/bb514961.aspx
---
WBR, Michael Nemtsev [.NET/C# MVP] :: blog:
http://spaces.live.com/laflour
"The greatest danger for most of us is not that our aim is too high
and we
miss it, but that it is too low and we reach it" (c) Michelangelo
SE> Hi,
SE> SE> Our company currently has a client/server based app. Now the
need
SE> has arisen to tap some of the functionality from a webpage. This
SE> means the client will disappear and a subset of functionality
will
SE> be needed from the web.
SE> SE> Normally a user logs in from the client, then functionality
will
SE> send commands to the server to accomplish certain things.
SE> SE> I also have a traditional unmanaged COM object that wraps
this
SE> functionality for 3rd party developers to use.
SE> SE> //pseudo code
SE> ServerConn conn = new ServerConn ();
SE> int UserID = conn.Authenticate(UserName, Password);
SE> if(UserID != -1)
SE> {
SE> //do some stuff
SE> }
SE> conn.Close();
SE> SE> Since there needs to be a user logged in, I'd like to tie the
object
SE> to a session. Here's the kicker. The "stuff" that needs to be
done
SE> needs to be done from JavaScript without postbacks. For example
SE> clicking an arrow to move a camera. The movement of that camera
SE> has to be tied to a "logged in" user. I had considered doing a
SE> web service, but wasn't sure how that would maintain a logged in
SE> user, then consume the web service within the JavaScript
SE> So I need to be able to:
SE> SE> Connection [Server-Side Script]
SE> Log In [Server-Side Script]
SE> Perform functions with hardware [Client-Side JavaScript]
SE> Close Connection [Server-Side Script]
SE> I had also considered wrapping the client-side needs in a page,
SE> and have the arrows, for example, call the page with
XMLHttpRequest.
SE> I also wasn't sure if that would use the same logged in session.
SE> Thanks for the advice ahead of time.
SE> SE> Steven
SE>

 

[bruce barker]

the icallbackhandlers are not much lighter. they use the same client postback
code as an update panel (send all form data including viewstate to server)
and run server side processing. the return payload may be lighter.

ajax webservice calls can lighter as only the service parameters are sent


-- bruce (sqlwork.com)

Hello Steven,

it's not the actual postback. it's callback to server, without sending all
page params
but it depends what are u using. UpdatePanels are fat and send all viewstates
and etc.
but manual postbacks are really light

---
WBR,
Michael Nemtsev [.NET/C# MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo


SE> Michael,
SE>
SE> AJAX does the postbacks in pieces, right? instead of the
SE> whole page? So my arrow would make a small post instead of
SE> "full" page? And this would maintain everything within the same
SE> session. Right?
SE> Thanks for your help. I'll look into your links. It sounds like a
SE> good fit.
SE>
SE> Steven
SE>
SE> SE>

Hello Steven,

Ok, you have 2 choices

First is implementing ICallbackEventHandler which "hides" all your
calls

to server, but there are a lot of manual jobs

Secord, rely on ajax, where everything implemented for you, even
Logging

to the server - see

http://www.asp.net/AJAX/Documentation/Live/ClientReference/Sys.Servic
es/AuthenticationServiceClass/default.aspx

Btw, to consumer services from javascript u recommed to rely on ajax
and
JSON serialization - google to find more samples.
For example there u can find a good sample how to consume WCF
services
directly from javascript
http://msdn2.microsoft.com/en-us/library/bb514961.aspx
---
WBR, Michael Nemtsev [.NET/C# MVP] :: blog:
http://spaces.live.com/laflour
"The greatest danger for most of us is not that our aim is too high
and we
miss it, but that it is too low and we reach it" (c) Michelangelo
SE> Hi,
SE> SE> Our company currently has a client/server based app. Now the
need
SE> has arisen to tap some of the functionality from a webpage. This
SE> means the client will disappear and a subset of functionality
will
SE> be needed from the web.
SE> SE> Normally a user logs in from the client, then functionality
will
SE> send commands to the server to accomplish certain things.
SE> SE> I also have a traditional unmanaged COM object that wraps
this
SE> functionality for 3rd party developers to use.
SE> SE> //pseudo code
SE> ServerConn conn = new ServerConn ();
SE> int UserID = conn.Authenticate(UserName, Password);
SE> if(UserID != -1)
SE> {
SE> //do some stuff
SE> }
SE> conn.Close();
SE> SE> Since there needs to be a user logged in, I'd like to tie the
object
SE> to a session. Here's the kicker. The "stuff" that needs to be
done
SE> needs to be done from JavaScript without postbacks. For example
SE> clicking an arrow to move a camera. The movement of that camera
SE> has to be tied to a "logged in" user. I had considered doing a
SE> web service, but wasn't sure how that would maintain a logged in
SE> user, then consume the web service within the JavaScript
SE> So I need to be able to:
SE> SE> Connection [Server-Side Script]
SE> Log In [Server-Side Script]
SE> Perform functions with hardware [Client-Side JavaScript]
SE> Close Connection [Server-Side Script]
SE> I had also considered wrapping the client-side needs in a page,
SE> and have the arrows, for example, call the page with
XMLHttpRequest.
SE> I also wasn't sure if that would use the same logged in session.
SE> Thanks for the advice ahead of time.
SE> SE> Steven
SE>

 

[Steven Edison]

Thanks guys. This worked great after a day of familiarizing my self with
AJAX and
putting in some samples it's working great!

Steven

Hello Steven,

Ok, you have 2 choices
First is implementing ICallbackEventHandler which "hides" all your calls
to server, but there are a lot of manual jobs
Secord, rely on ajax, where everything implemented for you, even Logging
to the server - see
http://www.asp.net/AJAX/Documentati...vices/AuthenticationServiceClass/default.aspx

Btw, to consumer services from javascript u recommed to rely on ajax and
JSON serialization - google to find more samples.
For example there u can find a good sample how to consume WCF services
directly from javascript
http://msdn2.microsoft.com/en-us/library/bb514961.aspx

---
WBR, Michael Nemtsev [.NET/C# MVP] :: blog:
http://spaces.live.com/laflour
"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

SE> Hi,
SE> SE> Our company currently has a client/server based app. Now the need
SE> has arisen to tap some of the functionality from a webpage. This
SE> means the client will disappear and a subset of functionality will
SE> be needed from the web.
SE> SE> Normally a user logs in from the client, then functionality will
SE> send commands to the server to accomplish certain things.
SE> SE> I also have a traditional unmanaged COM object that wraps this
SE> functionality for 3rd party developers to use.
SE> SE> //pseudo code
SE> ServerConn conn = new ServerConn ();
SE> int UserID = conn.Authenticate(UserName, Password);
SE> if(UserID != -1)
SE> {
SE> //do some stuff
SE> }
SE> conn.Close();
SE> SE> Since there needs to be a user logged in, I'd like to tie the
object
SE> to a session. Here's the kicker. The "stuff" that needs to be done
SE> needs to be done from JavaScript without postbacks. For example
SE> clicking an arrow to move a camera. The movement of that camera
SE> has to be tied to a "logged in" user. I had considered doing a
SE> web service, but wasn't sure how that would maintain a logged in
SE> user, then consume the web service within the JavaScript
SE> So I need to be able to:
SE> SE> Connection [Server-Side Script]
SE> Log In [Server-Side Script]
SE> Perform functions with hardware [Client-Side JavaScript]
SE> Close Connection [Server-Side Script]
SE> I had also considered wrapping the client-side needs in a page,
SE> and have the arrows, for example, call the page with XMLHttpRequest.
SE> I also wasn't sure if that would use the same logged in session.
SE> Thanks for the advice ahead of time.
SE> SE> Steven
SE>