Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / General / June 2007

Tip: Looking for answers? Try searching our database.

Dynamic web pages using VirtualPathProvider

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Charles Zhang - 15 Jun 2007 01:35 GMT
I am creating dynamic web pages according to the user inputs from a web
page.

For instance, a user typed in a text, I would want the text being the
source code of the dynamic page.

My question is: How could I access session variables from class that
derives from VirtualPathProvider or VirtualFile or the control values of
previous web page?

I could not use query string or cookies due to the amount of the data.

I am using HostingEnvironment to retrieve application path information.
I guess there are some similar global instance that I might be able to
use to retrieve information for the request.

Thanks

Charles Zhang
Walter Wang [MSFT] - 15 Jun 2007 08:58 GMT
Hi Charles,

The session is provided by the System.Web.SessionState.SessionStateModule
as one of the http modules pipeline. However, a VirtualPathProvider or
VirtualFile is called at page compilation stage, at which moment the
modules are not initialized yet. Therefore you will not be able to use
Session in VirtualPathProvider or VirtualFile.

Why not use HttpContext.Current.Items to pass the information? Normally
it's used to pass data between different http modules, but I think you can
also use it to pass data to the dynamic web page.

Hope this helps.

Regards,
Walter Wang (wawang@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
Charles Zhang - 15 Jun 2007 16:51 GMT
I think HttpContext.Current.Items will do the trick for me? However, how
could I deal with thread issue or do I need to worry about threading at all?

One thing I can think is to use a application variable flag to indicate
if some other session is trying to access HttpContext.Current.Items. I
guess you might know better ways.

Thanks

> Hi Charles,
>
[quoted text clipped - 20 lines]
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
Charles Zhang - 15 Jun 2007 17:18 GMT
Just more details about what I am planning to do.

Each session will only have one item in HttpContext.Current.Items.
Therefore, the session ID will be the key for the item.

I embedded the session ID into the file name of dynamic page request so
that I can retrieve the session ID then retrieve the value I stored in
HttpContext.Current.Items.

A number of sessions might add new items, retrieve items from
HttpContext.Current.Items at the same time (Of course with different
keys), do I need to worry about concurrent access issue from different
threads or the threading issue is handled inside the directory object?

Thanks

Charles Zhang

> I think HttpContext.Current.Items will do the trick for me? However, how
> could I deal with thread issue or do I need to worry about threading at
[quoted text clipped - 32 lines]
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
Walter Wang [MSFT] - 18 Jun 2007 09:38 GMT
Hi Charles,

The HttpContext.Current is per-request, which means every worker thread has
its own Items collection; therefore different request/session will have
their own HttpContext.Current. If you spawn a new background thread from
the worker thread that is currently handling the request, the background
thread will not have this HttpContext.Current.

This also means a second request issued by the same user/session will also
have an brand new HttpContext.Current. This is different from how session
state works across different requests. From your previous code, it seems
you're only saving the state at the beginning of each request and use it
from the dynamic web page, that's why I suggested to use it; otherwise it
will not work if you need to access previous state in
VirtualPathProvider/VirtualFile.

Following are some reference articles you may find useful on
HttpContext/CallContext:

#Working With HttpContext.Current
http://www.odetocode.com/Articles/112.aspx

Regards,
Walter Wang (wawang@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
Walter Wang [MSFT] - 21 Jun 2007 04:15 GMT
Hi Charles,

Let me know if you have further questions. Thanks.

Regards,
Walter Wang (wawang@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.