OOP: True hierarchical parent/child class interaction? Namespaces?

[Paul]

Hello,

I'm coming from a PHP background and am working on a large-scale VB.NET
project. One of the cornerstones of this project is a reusable form
class, to standardize our web forms.

My goal is to have a true hierarchical parent form class with child
form element classes. The programmatic code would be something like
this, ideally (sorry about the lame names, but it's just for demo):

MyForm = New SuperFormClass()
MyFormRadio1 = New SuperFormClass.RadioButton()
MyFormRadio1.Label = "Please select something."
MyFormRadio1.Id = "radio_blah"
MyFormRadio1.AppendToParent()
MyForm.Render()

So I want the child form element to work extensively with *that
particular instance* of the parent form class. I can't make a
RadioButton without a SuperFormClass, so I want SuperFormClass to act
as a container - with its own properties and methods.

I need to know the most practical way to pull this off. My research so
far has steered me towards nested classes, but I'm now investigating
namespaces. Most of the issue right now is syntax; I know how I'd code
this in PHP, for sure, and need to essentially translate it. I also of
course need to know if VB.NET will support this type of structure!

If anyone can help I'd appreciate it - and I'd be happy to answer more
specific questions. Thanks.

- Paul

 

[Phil G.]

Hi Paul,

If I don't understand your requirement or am making a 'stupid' suggestion
then just ignore me and I'll go away!

With vb.net (as with other oop languages) you can create a default class, as
in your SuperFormClass. You can then create other classes based on this
class by using the inherits keyword. By inheriting a class you can (or will)
have the functionality of the base 'inherited' class as well as being able
to add additional code (and objects) to the new class.

When you create a new form, by default it inherits from
system.windows.forms.form. Therefore your code will show:-

Inherits System.Windows.Forms.Form

Change this to Inherits SuperFormClass

Does this help?

Good luck, Phil

 

[Paul]

Thanks, Phil.

This is a web form, so I'm not working with System.Windows.Forms.Form
at all. What I'm doing in the interim here is using nested classes
(which may change later), and having all of the form element classes
inherit SuperFormClass - pretty much per your recommendation.

The only downside I can see is that I can also go ahead and declare new
instances of those form elements without declaring a new instance of
the SuperFormClass. Thus, I think my question has shifted from the
above to, "How can I restrict children to require the parent to be
declared, first?"

- Paul

 

[Phil G.]

I'm thinking that I'm getting out of my depth but, if I'm on the right lines
then you need to create an interface for your elements.

Rgds, Phil

 

[Cor Ligthert [MVP]]

Paul,

I have never seen the posibilities to use an inherited 'form' in aspnet.
(a Webform exist from a template in html and the so called code behind)

Try to use as less forms as necessary in ASPNET. A user is always
communicationg with one form at a time with the server. Simple hiding of
panels gives much more performance and makes your life easier.

However you can of course create your template forms.

Another thing is that ASPNET designing will dramaticly change with the
version 2.0.

We where not able to use an Iframe until that we saw a simple message from
Terry Burns (OHM) in another newsgroup how to do that. Still we are not
lucky because we needs to much access to use it. AFAIK will the masterpage
in 2.0 implements this.

This is our website by the way.
http://www.windowsformsdatagridhelp.com/default.aspx

From which will probably change the look completly short after the official
release of Net 2.0

I hope that this gives some information.

Cor

 

[Phill. W]

So I want the child form element to work extensively with *that
particular instance* of the parent form class. I can't make a
RadioButton without a SuperFormClass, so I want SuperFormClass
to act as a container - with its own properties and methods.

Change the Access Specifiers for Controls' Constructors to be Friend
(only your Assembly can create them) and add Public Functions to the
SuperFormClass to create and return you an instance of each Control.

Class SuperForm
Protected Function AddRadioButton() as CustomRadioButton

Class CustomRadioButton
Friend Sub New( ByVal oaParent as SuperForm )

The only down-side to this is that the IDE will insist on having a niladic,
[probably] Public Constructor before you can Design the Control.

HTH,
Phill W.

 

[Paul]

Heh... I thought I had a handle on this, and now I'm not sure about any
of it.

When it gets distilled, what I ultimately want (or believe I want!) is
an object that can have subobjects. Those subobjects shouldn't be able
to be created without the containing object - but, more importantly - I
should be able to create them programmatically, as in my root post on
this thread.

I did spot an error in my original post, too, which might be leading to
some of the confusion. Here is the end goal in code.


Paul Aug 19, 10:11 am show options
Newsgroups: microsoft.public.dotnet.languages.vb
From: "Paul" <[email protected]> - Find messages by this author
Date: 19 Aug 2005 08:11:33 -0700
Local: Fri, Aug 19 2005 10:11 am
Subject: OOP: True hierarchical parent/child class interaction?
Namespaces?
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Remove | Report Abuse

Hello,

I'm coming from a PHP background and am working on a large-scale VB.NET
project. One of the cornerstones of this project is a reusable form
class, to standardize our web forms.

My goal is to have a true hierarchical parent form class with child
form element classes. The programmatic code would be something like
this, ideally (sorry about the lame names, but it's just for demo):

MyForm = New SuperFormClass()
MyFormRadio1 = New MyForm.RadioButton()
MyFormRadio1.Label = "Please select something."
MyFormRadio1.Id = "radio_blah"
MyFormRadio1.AppendToParent()
MyForm.Render()

Note that when I declare MyFormRadio1, I'm calling for a new
RadioButton under MyForm - not SuperFormClass. This makes sense to me
logically.

Now, if anyone feels I'm barking up the wrong tree that's quite fine
and I'm open to alternatives. As I said before, the goal is to have a
bunch of little subobjects that can amass into one big object.

- Paul

 

[Paul]

.... and Google Groups seemed to barf on my message. Sorry about that.
Here's the whole thing once again:

Heh... I thought I had a handle on this, and now I'm not sure about any
of it.

When it gets distilled, what I ultimately want (or believe I want!) is
an object that can have subobjects. Those subobjects shouldn't be able
to be created without the containing object - but, more importantly - I
should be able to create them programmatically, as in my root post on
this thread.

I did spot an error in my original post, too, which might be leading to
some of the confusion. Here is the end goal in code.

MyForm = New SuperFormClass()
MyFormRadio1 = New MyForm.RadioButton() ' note this line is updated
MyFormRadio1.Label = "Please select something."
MyFormRadio1.Id = "radio_blah"
MyFormRadio1.AppendToParent()
MyForm.Render()

Note that when I declare MyFormRadio1, I'm calling for a new
RadioButton under MyForm - not SuperFormClass. This makes sense to me
logically.

Now, if anyone feels I'm barking up the wrong tree that's quite fine
and I'm open to alternatives. As I said before, the goal is to have a
bunch of little subobjects that can amass into one big object.

- Paul