Wrox Programmer Forums
Go Back   Wrox Programmer Forums > ASP.NET and ASP > ASP.NET 2.0 > BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0
| Search | Today's Posts | Mark Forums Read
BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0
This is the forum to discuss the Wrox book ASP.NET 2.0 Website Programming: Problem - Design - Solution by Marco Bellinaso; ISBN: 9780764584640
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old July 18th, 2009, 02:40 PM
Authorized User
 
Join Date: Jun 2009
Posts: 32
Thanks: 17
Thanked 0 Times in 0 Posts
Default I've finally finished MEmbership and UserProfiling chapter, but I have a few question

Hello,


Heh, I’ve completed the Membership and User profiling chapter ( I’ also learning Asp.Net as I go and that’s why it takes a bit longer ) and I have few questions ( I apologize if there are too many questions for a single thread, but I don't want to be spamming this forum with too many threads – if that’s a problem, please tell me )

BTW - The first four questions refer to ManageUsers Administrative Page ( page 170 )


1) I assume only reason why “SearchByEmail” and “SearchText” attributes need to be stored in ViewState ( and thus persisted across postbacks ) is for cases when administrator deletes a user and we want GridView to display same users (say those whose email name includes letter L ) as it displayed before page issued a posted back due to clicking a delete button?



2) lblTotUsers and lblOnlineUsers display a total number of registered users and a number of users currently online, respectively. The values assigned to these two labels are calculated only on first postback ( value for lblTotUsers is also calculated when user gets deleted ).


But shouldn’t values for lblTotUsers and lblOnlineUsers be calculated on each postback since new users could be created or logged in between the two concurrent postbacks?




3) I don’t see any point in setting Attribute[“SearchByEmail] inside rptAlphabet_ItemCommand() event handler, since “SearchByEmail” attribute will always be set and saved accordingly elsewhere?!



4)
Code:
         bool searchByEmail = false;
       if ( !string.IsNullOrEmpty(gvwUsers.Attributes["SearchByEmail"]) )
               searchByEmail = bool.Parse(gvwUsers.Attributes["SearchByEmail"]);
This is most likely totally useless question, but why did we in above code set searchByEmail variable to false? Is it just a convention or…? As far as I can tell, gwsUsers.Attributes[“SearchByEmail”] will never be null or empty string, so I would think the following code would also work:

Code:
        bool searchByEmail;
        if ( !string.IsNullOrEmpty(gvwUsers.Attributes["SearchByEmail"]) )
                searchByEmail = bool.Parse(gvwUsers.Attributes["SearchByEmail"]);



5)
Following code is featured on page 177 inside EditUser class:

Code:
public partial class class EditUser: BasePage
{
         protected void Page_Load(object sender, EventArgs e)
        {
                 userName = this.Request.QueryString[“UserName”];
                                ...
        }
Is there a reason why in above code “UserName” parameter is extracted from query string on each postback and not just on first postback?





6) Register.aspx page ( page 159 ):

Inside CreateUserWizard control author has set both ContinueDestinationPageUrl and FinishDestinationPageUrl attributes to ~/Deafult.aspx. But I don’t see a point in setting ContinueDestinationPageUrl attribute, since as far as I can tell, user will never move to CompleteWizardStep due to WizardStep defined before CompleteWizardStep always redirecting user to Default.aspx page. Thus, I don’t even see a point in even declaring CompleteWizardStep in the first place?!


Thank you
 
Old July 18th, 2009, 11:06 PM
Friend of Wrox
Points: 1,749, Level: 16
Points: 1,749, Level: 16 Points: 1,749, Level: 16 Points: 1,749, Level: 16
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2007
Location: San Diego, CA, USA.
Posts: 477
Thanks: 10
Thanked 19 Times in 18 Posts
Default

Quote:
Originally Posted by carewithl View Post
1) I assume only reason why “SearchByEmail” and “SearchText” attributes need to be stored in ViewState ( and thus persisted across postbacks ) is for cases when administrator deletes a user and we want GridView to display same users (say those whose email name includes letter L ) as it displayed before page issued a posted back due to clicking a delete button?



2) lblTotUsers and lblOnlineUsers display a total number of registered users and a number of users currently online, respectively. The values assigned to these two labels are calculated only on first postback ( value for lblTotUsers is also calculated when user gets deleted ).


But shouldn’t values for lblTotUsers and lblOnlineUsers be calculated on each postback since new users could be created or logged in between the two concurrent postbacks?
I believe both of these cases are for application performance. If I can take #2 first, if you hit the server to check for those values again then... you have to wait for it to do so. Since those values are unlikely to change significantly while you're working on one web page, why bother? How many new people are going to register while you're working on that page, probably none, and while some users may log in or log off, you've still got a decent idea of how many people are online even if it's a couple minutes old. If not, you just hit refresh.

#1, and I'm a little fuzzier on this part but I think....

When you do a search you are hitting a data store, not having the book I'll just guess database and beg forgiveness if I'm wrong. In any case, returning information from any data store is usually one of the slowest operations you can do for a web page. While storing lots of information in the ViewState is not great for application performance either, it beats waiting for a whole new search to be returned by the database (which is especially annoying since you'd be waiting all that time for the EXACT SAME information you just retrieved 60 seconds before).

So you save the results of the search to ViewState. Otherwise the page that's posted back would have no access to that information; you would effectively lose search results everytime you posted back.
__________________
-------------------------

Whatever you can do or dream you can, begin it. Boldness has genius, power and magic in it. Begin it now.
-Johann von Goethe

When Two Hearts Race... Both Win.
-Dove Chocolate Wrapper

Chroniclemaster1, Founder of www.EarthChronicle.com
A Growing History of our Planet, by our Planet, for our Planet.
The Following User Says Thank You to chroniclemaster1 For This Useful Post:
carewithl (July 20th, 2009)
 
Old July 20th, 2009, 06:07 PM
Authorized User
 
Join Date: Jun 2009
Posts: 32
Thanks: 17
Thanked 0 Times in 0 Posts
Default

Hello,

Quote:
Originally Posted by chroniclemaster1 View Post
In any case, returning information from any data store is usually one of the slowest operations you can do for a web page.
Uhm, I thought that accessing DB was one of fastest operations, not slowests?!

Quote:
Originally Posted by chroniclemaster1 View Post
So you save the results of the search to ViewState. Otherwise the page that's posted back would have no access to that information; you would effectively lose search results everytime you posted back.
I assume if ManageUsers Administrative Page didn't also have an option to delete a user, then there wouldn't be any need for saving SearchByEmail” and “SearchText” attributes across postbacks?!


thanx mate




Similar Threads
Thread Thread Starter Forum Replies Last Post
Question about Asp.net Membership chobo2 ASP.NET 3.5 Basics 3 April 2nd, 2009 04:02 PM
Membership / User question rsearing ASP.NET 3.5 Professionals 29 February 21st, 2009 12:45 PM
Chapter 4 - Membership and Identity cindeost BOOK: Beginning ASP.NET 2.0 and Databases 0 November 17th, 2008 10:55 PM
Custom Membership provider question aspcoder BOOK: Beginning ASP.NET 3.5 : in C# and VB BOOK ISBN: 978-0-470-18759-3 3 July 27th, 2008 09:59 AM
Membership - Ref: Chapter 8 JayLou BOOK: Wrox's ASP.NET 2.0 Visual Web Developer 2005 Express Edition Starter ISBN: 978-0-7645-8807-5 0 April 11th, 2007 10:24 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.