Is this an appropriate use of PUBLIC variables?

[darrel]

I'm still not quite sure how best to handle the passing of data between
controls.

This is a method I'm using at the moment:

I have an XML file that contains a variety of page-centric variables. I have
one control that loads the XML file, reads through it, and grabs the
variables it needs. It then sets these to PUBLIC variables.

Then, other usercontrols simply request that variable.

This seems to work just fine, but I'm wondering if there's an issue with
this. Are publi variables shared across the application regardless of the
user, or are they confined to the specific usersession as well?

My concern is having two people accessing this simultaneously causing one
instance of the UC overwriting the public variables and having the other use
see them.

-Darrel

 

[Karl Seguin]

Darrel:
Think of a user control and a page as a class (it actually is). When the
user requests a page, an instance of the class is created. Instances of
classes for each user control on the page are also created. Public
variables belong to a specific instance of a class. In other words, when
two people visit the same page (even if its at exactly the same time), two
separate instances are created. Each instance has its own properties,
fields and functions (one of those you call "variables"). It's no
different than:

public class Test
public x as integer 'bad design, fields should be private, properties
public, but who cares for this
end class


dim test1 as new Test()
dim test2 as new Test()
test1.x = 3
test2.x = 4

test1 and test2 are two distinctly separate instances of the Test class.
Setting test2.x = 4 doesn't change the value of test1.x

Now, if your variable is marked as shared/static that's a whole other story,
in which case the opposite is true (shared variables ARE shared amongst all
instances of a class). BUt you didn't say that so I assume you are talking
about non-shared (ie, instance) members.

Karl

 

[darrel]

Think of a user control and a page as a class (it actually is). When the

user requests a page, an instance of the class is created.

I know that, but never actually fully thought of it properly. I'm not sure
why, but your statement cleared that up quite well. I was in the old
'include' line of thinking rather than 'instance of' way of thinking.

Public
variables belong to a specific instance of a class. In other words, when
two people visit the same page (even if its at exactly the same time), two
separate instances are created.

Makes perfect sense. Thanks for the clarification!

Now, if your variable is marked as shared/static that's a whole other story,
in which case the opposite is true (shared variables ARE shared amongst all
instances of a class). BUt you didn't say that so I assume you are talking
about non-shared (ie, instance) members.

Ah! OK, that explains the whole Shared thing a bit better too.

Thanks, Karl.

Now, a follow up question. And this is a question I've sort of asked before
I think so apologies if it sounds like I'm going in circles.

On a previous project, I had a template ASPX page. One of my UC's, as stated
above, would grab some variables from an XML file and set some properties.

Other UC's could then access these properties via:
ctype(Page, Page_Class).UC_class.myPublicProperty

This was nice as one UC was in charge of doing the heavy lifting of parsing
the XML files and the other UC's could simply grab what they needed from
that.

Now, the catch is that on my new project, I'm pulling the UC into a variety
of template ASPX pages, so the UC doesn't really know the Page_Class it
happens to be associated with. As such, I'm not really sure how to go about
getting the variable from another UC in that case. I'm still struggling with
the whole sharing of variables throughout the code thing...my existing
hangup from the ASP days, methinks. ;o)

-Darrel

 

[Karl Seguin]

Darrel:
Check out my tutorial on this at:
http://openmymind.net/communication/index.html

The short answer is likely for your pages to implement an interface.

Karl

 

[darrel]

The short answer is likely for your pages to implement an interface.

Hmm...These are new to me.

I've just read through both your tutorial and the one you link to.

I'm not fully understanding the purpose of an interface and, more
specifically, how that would be used to share data between controls.

Could I have one UC declare the interface, then the other UC implement it,
thereby inheriting any properties set during the declaration? Or are
interfaces essentially an alternative to using UCs in the first place?

-Darrel

 

[Karl Seguin]

No, the interface was meant to solve your page problem. You were saying
that normally you do:

Ctype(Page, Page_Class).UC_Class.myPublicProperty

but you can't do that from your UC because it could be used from multiple
pages...ergo ctype(Page, COULD_BE_ANYTHING_HERE) is your problem.

if you create an interface and have your pages implement that interface you
can do:

ctype(Page, YourInterface)

this is safe because your pages all implement the interface...just like
doing Ctype(Page, Object) is safe because all pages inherit from
object...you would end up with an interface with defines the user control to
get the value:

public interface ISharedValueExposer
readonly Property SomeControl as UC_Class
end interface

interfaces don't have implementation, but classes which implement the
interface must provide an implementation, so if you do:

class Page_Class blah
inherits Page
implements ISharedValueExposer

you have to implement the SomeControl property defined in the interface
ala:
public readonly Property SomeControl AS UC_Class Implements
ISharedValueExposer.SomeControl
get
return theControl
end get
end property


that's the basics anyways

Karl

 

[darrel]

but you can't do that from your UC because it could be used from multiple

pages...ergo ctype(Page, COULD_BE_ANYTHING_HERE) is your problem.

Right. I can't traverse the class hierarchy from the UC because it doesn't
know what parent page class loaded it.

if you create an interface and have your pages implement that interface you
can do:

ctype(Page, YourInterface)

Oh! Gotcha. OK, that makes sense now. I did some more reading and the
interface thing is beginning to make more sense now. It's basically a way to
force a consistent code structure across multiple classes, correct? And, it
seems, the bonus is that I can then reference it from the UC.

Ok...Off to play with this a bit...

THANKS!

-Darrel