Any good tutorials or scripts that explain how to display page elements
depending on the person either being logged in or by their password
level?
In asp it would be like this
<%
MM_authorizedUsers="3"
MM_grantAccess=false
If Session("MM_Username") <> "" Then
If (false Or CStr(Session("MM_UserAuthorization"))="") Or _
(InStr(1,MM_authorizedUsers,Session("MM_UserAuthorization"))>=1) Then
MM_grantAccess = true
End If
End If
If MM_grantAccess Then ' *** Show If User Logged In
%>
<tr>
<td><div align="center"><img src="images/admin123.gif"
width="45" height="39"></div></td>
<td bgcolor="#CCCCCC" class="formbold"><div align="center"
class="formbold"><font color="#FFFFFF"><a
href="admin/main.asp?clientID=<%=(rsUser.Fields.Item("clientID").Value)%
>">Administration</a></font></div></td>
<td bgcolor="#FFFFFF" class="formbold"> </td>
</tr>
<%
End If ' *** Show If User Logged In
%>
Dave
-----Original Message-----
From: paul smith [mailto:[EMAIL PROTECTED]]
Sent: Saturday, December 14, 2002 7:28 PM
To: CF-Talk
Subject: RE: For the gurus: Question about state management with CLIENT
sc ope
Sorry, Dave. I guess I wasn't clear enuf. The original had "...it's
intended..." referring to client scope.
My comment about "practicality" referred to client scope not to session
scope. I was simply pointing out that it can be practical to use client
scope. I did not mean to imply session variables were not practical. I
was reacting to the suggestion that client scope was "intended more for
long-term user data storage" I'm not exactly sure what the writer meant
by
this, but I didn't want the suggestion that client scope should not be
used
to maintain state to just lie there.
As always, conclusions are application-dependent. In the application I
spend most of my time on, every page has database queries, and the ms
spent
on pulling client variables out of a database is not where the time is
being spent. In addition, I don't use the default client variable
database
storage method that requires parsing a #-delimited list to get each
client
variable. My client variable database has a specific column for each
client
variable.
best, paul
At 05:13 PM 12/14/02 -0500, you wrote:
> > > The Client scope isn't really intended to behave the
> > > same way as the Session scope - it's intended more
> > > for long-term user data storage, rather than storing
> > > data during an individual visit.
> >
> > It's intent is one thing. It's practicality is another.
> >
> > I never use session scope to maintain state. I use client
> > scope and store client variables in a database. I let the
> > database worry about what it is good at - locking, so I
> > don't have to worry about it.
>
>While this may ease your coding, especially with versions prior to
CFMX, I
>would disagree with your implication that it's not practical to use the
>Session scope.
>
>It's pretty expensive to add a database query to every page, which is
what
>you're doing when you use the Client scope. Storing short-term data in
>memory is much, much cheaper, and perfectly safe if you write your code
>correctly.
>
>Dave Watts, CTO, Fig Leaf Software
>http://www.figleaf.com/
>voice: (202) 797-5496
>fax: (202) 797-5444
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Your ad could be here. Monies from ads go to support these lists and provide more
resources for the community. http://www.fusionauthority.com/ads.cfm
