Persistent SS SO Additions 2004-03-17 - By a
Back
HI Bill
My ha penny,
I've had varied successes both using an uberPersistentSO and using slots to
store variables and object and using multiple SO's and a single slot.
My requirements have been very dependent on the application and its requirements
a
-- -- Original Message -- --
From: Bill Sanders
To: flashcomm@(protected)
Sent: Wednesday, March 17, 2004 9:26 PM
Subject: Re: [FlashComm] Persistent SS SO Additions
Hi John,
I was just wondering what's been found to be the best way to store and access
SS persistent SOs. It's not the setProperty() or getProperty, or even returning
them to the client side. Rather, I guess the question has to do with how to
most effectively and efficiently store the SO's -- more of an organization
question, really.
Jesse's response is helpful, but I'm not certain what he means by a namespace
within an existing SO. (I've been working with ASP.NET recently, and namespace
refers to a group of classes of ASP.NET's 3,400 classes!) I guess with a
persistent SO, you can store the ID as well as anything else in a separate slot
.
In one app I make, I concatenated the name and IP address and then broke them
apart on the client side, and I think that was a little clunky, and I was
looking for an elegant solution.
Thanks,
Bill
On Wednesday, March 17, 2004, at 02:26 PM, John Robinson wrote:
Bill,
I'm not really sure what you mean? Err.. what is the issue exactly?
John
On Wednesday, March 17, 2004, at 02:11 PM, Bill Sanders wrote:
Hello All,
I'm working on that promised chapter on Persistent SS Shared Objects, and
I've run into a bit of a conundrum. (By the way if Brian Lesser's materials on
FCS at www.ryerson.ca are any indication, Brian's book is going to be fantastic
!) Having worked so long with non-persistent ss so's, I've never given a second
thought to the storage issue. One solution is to use unique names for each
additional so, and that works fine.
The other approach is to open a persistent so (fso) and pull out an
existing array and then push new materials on top of the array to effectively
reassign elements to the array. [I think Brian had something like this.]
A long time ago I believe Colin Moock created a Guest Book using some
kind of persistent so's, but I'm wondering if any of you have arrived at an
optimal solution for this issue.
TIA
Bill
__ ____ ____ ____ ____ ____ ____ _____
bill sanders | sandLight productions | http://www.sandlight.com | bloomfield,
ct | 860.242.2260
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859 (See http://iso-8859.ora-code.com)-1">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>HI Bill</FONT></DIV>
<DIV><FONT face=Arial size=2>My ha penny,</FONT></DIV>
<DIV><FONT face=Arial size=2>I've had varied successes both using an
uberPersistentSO and using slots to store variables and object and using
multiple SO's and a single slot.</FONT></DIV>
<DIV><FONT face=Arial size=2>My requirements have been very dependent on the
application and its requirements</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>a</FONT> </DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT:
#000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">-- -- Original Message -- -- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=wdsanders@(protected) href="mailto:wdsanders@(protected)">Bill
Sanders</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
title=flashcomm@(protected)
href="mailto:flashcomm@(protected)">flashcomm@(protected)
</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, March 17, 2004 9:26
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [FlashComm] Persistent SS
SO
Additions</DIV>
<DIV><BR></DIV>Hi John,<BR><BR>I was just wondering what's been found to be
the best way to store and access SS persistent SOs. It's not the setProperty(
)
or getProperty, or even returning them to the client side. Rather, I guess
the
question has to do with how to most effectively and efficiently store the SO
's
-- more of an organization question, really.<BR><BR>Jesse's response is
helpful, but I'm not certain what he means by a namespace within an existing
SO. (I've been working with ASP.NET recently, and namespace refers to a group
of classes of ASP.NET's 3,400 classes!) I guess with a persistent SO, you can
store the ID as well as anything else in a separate slot.<BR><BR>In one app I
make, I concatenated the name and IP address and then broke them apart on the
client side, and I think that was a little clunky, and I was looking for an
elegant solution.<BR><BR>Thanks,<BR>Bill<BR><BR><BR><BR><BR>On Wednesday,
March 17, 2004, at 02:26 PM, John Robinson wrote:<BR><BR>
<BLOCKQUOTE>Bill,<BR><BR>I'm not really sure what you mean? Err.. what is
the issue exactly?<BR><BR>John<BR><BR>On Wednesday, March 17, 2004, at 02
:11
PM, Bill Sanders wrote:<BR><BR>
<BLOCKQUOTE>Hello All,<BR><BR>I'm working on that promised chapter on
Persistent SS Shared Objects, and I've run into a bit of a conundrum. (By
the way if Brian Lesser's materials on FCS at www.ryerson.ca are any
indication, Brian's book is going to be fantastic!) Having worked so long
with non-persistent ss so's, I've never given a second thought to the
storage issue. One solution is to use unique names for each additional so
,
and that works fine.<BR><BR>The other approach is to open a persistent so
(fso) and pull out an existing array and then push new materials on top
of
the array to effectively reassign elements to the array. [I think Brian
had something like this.]<BR><BR>A long time ago I believe Colin Moock
created a Guest Book using some kind of persistent so's, but I'm
wondering
if any of you have arrived at an optimal solution for this
issue.<BR><BR>TIA<BR>Bill<BR></BLOCKQUOTE></BLOCKQUOTE><?fontfamily><
?param Arial>__ ____ ____ ____ ____ ____ ____ _____<BR>bill
sanders | sandLight productions | http://www.sandlight.com | bloomfield, ct |
860.242.2260<BR><?/fontfamily>
<BLOCKQUOTE><BR><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
|
|
