Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Frameworks Revisited!
Message
From
05/02/1999 16:42:33
 
 
To
05/02/1999 15:28:08
General information
Forum:
Visual FoxPro
Category:
Third party products
Miscellaneous
Thread ID:
00182668
Message ID:
00184530
Views:
17
>Using your pseudo-code as the example. . .
>#1 >Ask client for it's session id?
>#2 >If client doesn't have session id, assign a session ID, request login.
>#3 >Store login info with session ID.
>#4 >Do thing this code does.
>#5 >Exit
>
>How do I accomplish #1 - #3 in VFP?

Well... in a web application situation you generally use a Cookie to hold the session ID. This is how the ASP session object works also. With every post to the VFP ap/component the cookie is passed back to the server. As I said before, the component must re-set it self to that session.

In a non-web situation with a standalone .EXE you could use NT Authenticate user API.

If your component is hosted in MTS, you could use the MTS object to get the role or user and reestablish session info.


>Variables storage
>Does VFP 'getmain' RAM to hold all memory variables defined in the program?... its system memvars too?
>If so, does the 'periodic garbage collection' (that some are fond of presuming VFP does) operate on that?

Got me.

>Overlays
>Does VFP make use of overlays in its EXE (or DLL?) code that is assembled?
>If so, how can it ever operate correctly as 'stateless'?

What does the overlaying of code have to do with 'stateless' component? That seems to be more an issue of thread safe processing than statefull vs stateless components.


>ActiveX components
>Are these 'stateless' in all cases, or does one have to be told if that is the case?

Perhaps a good question, but I more thing of ActiveX as UI things.

>I have other things I wonder about, but these portray the gist of my concerns.

Hmmm...

>I sure would be GREATLY comforted if there was some passage (from a VFP official source), somewhere, which someone could cite which stastes clearly that this can be done successfully and/or lists any restrictions in doing so.
>

Would be nice if there was a 'Resource Kit' like there is for windows that describes the technical aspects of the software and how certain things work, and why they work the way they do.


BOb

>
>>>John,
>>>
>>>I believe that this is a crucial and critical piece of information.
>>>
>>>Where can I obtain some confirmation that VFP will, under any circumstance (or even under what particular circumstances) create re-entrant (ie "stateless", to use your (and possibly the proper) terminology) EXEs (and DLLs?)?
>>>
>>>Surely this must be documented somewhere, and I have yet to come across anything wich even suggests it to be true.
>>>
>>>Jim N
>>
>>This is exactally what you are doing when you write application for the web using Web Connection, or even when using FoxISAPI...
>>
>>You have to write your code so that nothing within the object is expected to persists. This doesn't mean that you can persist information with a statless object, you have to store the information and relate it to the user or client as opposed to the current running code.
>>
>>For eample, when you write an exe that has a UI that is run on someones PC, you can store info in goAPP.UserID since this application always maintains its state, it has one user, and it can store info within it self.
>>
>>With a stateless object you can't do that. You have to query the client... then restore session info you might have stored about that client. Some pseudo code follows...
>>
>>Ask client for it's session id?
>>If client doesn't have session id, assign a session ID, request login.
>>Store login info with session ID.
>>Do thing this code does.
>>Exit
>>
>>SO... this object is stateless... since several clients are using its services it can't store info within itself that is related to something outside of itself.
>>
>>With web programs you use the idea of Sessions. You maintain a database of sessions with info that your ap as a whole may need to access. Every object would have to restore this session info and store any changes to it.
>>
>>This is how I can have a shopping cart, many shopping carts, call processed with the same code. At any time a client could call the 'AddMyTotal' method... that method would have to ask... ok, what is your cartid... then look up that info in a database and add up the total.
>>
>>You can certainly do this with a VFP ap.
>>
>>BOb
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform