Mailing List
Home
Forum Home
Flash Pro
Subjects
Subject: RE: Firework Effect
Web Service Results
Flash Interface with 10mb xml file
AW: [Flashcoders] Switch/Case vs If/else
AW: [Flashcoders] Switch/Case vs If/else
Flash MX 2004 Sucks
Reading and displaying RSS feeds in Flash MX
Flash and QuickTime VR
Textfield prototype question
XML to Object help
Order of events per frame
MX2004 Dataset itemClassName
memory management removeMovieClip /
Event Dispatcher between classes
Help: MX 2004 How to script a print button to print the entire sli
ScrollPane component doesn 't auto update
setInterval bug identified and fixed
setInterval bug identified and fixed
Listener Object 's best practice
 
Persistent SS SO Additions

Persistent SS SO Additions

2004-03-18       - By Bill Sanders

 Back
Reply:     1     2     3  

Jesse.

Thank you again. I've had my head in ASP.NET for too much time. I've
used a little different strategy. I have created a pseudo-array by
placing a counter variable into another persistent slot and
concatenating the counter value to the user's name. So I can have more
than 1 person with with same name (e.g., Jesse Warden23 and Jesse
Warden54)  Based on what you, Brian,  Peldi, and aYo have said and
done--not to mention the docs and help from Asa [plus SO work we did in
our book], I think that using an extra slot is probably the best
solution.

I'm nearing the end of the work on Persistent SSSO's and hope to have
that available soon as a "chapter," but before I do that, I'll make the
app available to this list.

By the by--here's where the source of confusion was with your use of
"namespace" -- there are at least 5 definitions:

NAMESPACE

(1) The set of names in a naming system.

(2)A logical grouping of the names used within a program. Also called
name scope.

(3) A library of classes in .NET. <=This is the one I was thinking of!

(4) XML namespace: In XML, a namespace is a collection of names,
identified by a URI reference, that are used in XML documents as element
types and attribute names. In order for XML documents to be able to use
elements and attributes that have the same name but come from different
sources, there must be a way to differentiate between the markup
elements that come from the different sources.

(5) DNS namespace: DNS is the name service provided by the Internet for
TCP/IP networks. DNS is broken up into domains, a logical organization
of computers that exist in a larger network. The domains exist at
different levels and connect in a hierarchy that resembles the root
structure of a tree. Each domain extends from the node above it,
beginning at the top with the root-level domain. Under the root-level
domain are the top-level domains, under those are the second-level
domains, and on down into subdomains. DNS namespace identifies the
structure of the domains that combine to form a complete domain name.
For example, in the domain name sub.secondary.com, "com" is the
top-level domain, "secondary" identifies the secondary domain name
(commonly a site hosted by an organization and/or business), and "sub"
identifies a subdomain within the larger network. This entire DNS domain
structure is called the DNS namespace. The name assigned to a domain or
computer relates to its po!
sition in the namespace.

Cheers,
Bill
On Thursday, March 18, 2004, at 08:56 AM, Jesse Warden wrote:

> Namespace was a reference to how Central handles applciation instances.
> ?
> Basically, you get a unique ID + a unique application ID for your
> applicatio.? Because you can open multiple instances of a Central app
> window, you can have the same appID, but a different windowID.?
> THerefore, a truly unique ID is a combination of the 2.
> ?
> It's similiar to how Peldi constructed the namespaces for components in
> Flashcom, both client and server-side (check the archives for both
> Peldi and Srinivas answered my questions about how to have server-side
> components find eachother.
> ?
> Obviously, for an SO, it's much simplier, but ensures you'll always
> have a unqiue name, like how just about every Communication Component
> is named:
> ?
> this.name = ( this._name == null ? "_DEFAULT_" : this._name );
> ?this.prefix = "FCChat." + this.name + ".";
> ?
> the namespace for the component in the framewokr is:
> ?
> "_DEFAULT_chat_mc"
> ?
> His prefix for calling methods on the server-side is:
> ?
> "FCChat._DEFAULT_chat_mc."
> ?
> where the last part is appeneded via server-side... I think.
> ?
> At any rate, you can see that utilizing uniuqe application names +
> client names, you can get a good nameing scheme for your project.? As
> aYo said, though, it's based on your project as you know, but if I had
> to handle it, I'd do some combo of the above.
>
>
> -- --Original Message-- --
> From: Bill Sanders [mailto:wdsanders@(protected)]
> Sent: Wednesday, March 17, 2004 04:26 PM
> To: flashcomm@(protected)
> 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
>
>
>
>
__ ____ ____ ____ ____ ____ ____ _____
bill sanders | sandLight productions | http://www.sandlight.com |
bloomfield, ct | 860.242.2260