Proper usage of Frames, Subframes, and Interfaces

[Eric Bresie]

I'm sure this is a newbie sort of questions...so forgive me ahead of
time..

I want to work with a base Class A (which extends JFrame) which makes
a basic frame. This frame contains a number of panels where assorted
buttons, fields, etc are added to a number of panels which will be
used in all classes derrived from this class.

There is shared panel which is created to contain additional
components which will be added in the extended class.

I want a new Class B which extends class A. In class B, I want to
added elements into the shared panel defined in class A.

How is the best way to do this?

I tried having something like:

public class A extends JFrame {
JPanel contentPane ;
JPanel sharedPanel ;
JPanel fieldPanel ;
JPanel buttonPanel ;

public A() {
contentPane = (JPanel)this.getContentPane();
sharedPanel = new JPanel();
fieldPanel = new JPanel();
buttonPanel = new JPanel();

// configure Panes ...

// buttons added to buttonPanel
// fields added to fieldPanel
}

}

public class B extends A {

public B() {
// fields added to sharedPanel
sharedPanel.add( /* assorted components added here */ );
}
}

I'm using a GUI development tool, so this may be whats throwing me off
some, but when I do this similar scenario, it doesn't seem to allow me
to add the components correctly like this.

I also tried doing something like....

public class B extends A {

public B() {
this.setContentPane(sharedPanel);

this.getContentPane().add( /* assorted components added here
*/ );
}
}

Which doesn't seem to work correctly either..

How is the proper way to do this?

--

I'm kind of new to interfaces, so I'm not sure about this..

I want to have additional classes also extended from A which will have
overloaded functions...is this a case where I should define an
interface which each derrived class (like class B) would implement? I
want to have something like Class A having a defined
defaultFunction(), then class B overload this defaultFunction() but
also call the super() version of the function to ensure correct
handling of base class variables.


Eric Bresie
(e-mail address removed)

 

[Jon A. Cruz]

I'm sure this is a newbie sort of questions...so forgive me ahead of
time..

I want to work with a base Class A (which extends JFrame) which makes
a basic frame. This frame contains a number of panels where assorted
buttons, fields, etc are added to a number of panels which will be
used in all classes derrived from this class.

Try to go at your design from the other direction.

Do not start with the UI. Start with the functionality that your program
will need, and the abstract information that it needs to model. Build
that up, and then as a final step 'hang' your UI on it.

In other words, do the bones and muscles first, then once you have all
that sketched out then go and make some clothes for your creation.

Separate information from presentation.

 

[Eric Bresie]

Try to go at your design from the other direction.

Do not start with the UI. Start with the functionality that your program
will need, and the abstract information that it needs to model. Build
that up, and then as a final step 'hang' your UI on it.

In other words, do the bones and muscles first, then once you have all
that sketched out then go and make some clothes for your creation.

Separate information from presentation.

It already designed separately in this respect...I am also working
with existing code, so it is a little bit difficult to totally
recreate everything completely in that respect.

Basically, we are working on a messaging system. We have a message
which must conform to a specific format to pass information to other
similar systems. We use an editing component to produce these
messages. I want a jframe derrived frame to be used as the basis,
where all the send buttons and address information will always be the
same...the message content will be different for each type of message.

For each new message, I want to derrive a new message editing frame
for that speicif message, showing the different fields for each new
message in the message section of the base class.

I hope to convert the currently implemented messages to use this new
OO derrived design eventually, but I think my implementation using
existing code is causing some of my confusion.

To avoid some of the specifics, I gave the previous abstract version
to try and make things similar to understand.

Let me try one more time...

If I have a JFrame (Frame1), with a JPanel (Panel1) on this frame
defined in a BaseClass...what is the proper way to put items on Panel1
from a derrived class (DerrivedClass extends BaseClass; ).

Not written in completely true java (pseudo.java maybe I admit,
but the basic idea I'm asking is...is the correct way to do it

(In DerrivedClass)
BaseClass.Panel1.add(new Component("Something"));

or

Panel1.add(new Component());

or

BaseClass.getContent().Panel1.add(new Component())

or

super.getContent().Panel1.add(new Component())

or

super.Panel1.add(new Component())

or

Do I need to provide some get/set functions to interact with that
panel and work from there?

or

Do it some other way which I'm sure I'm probably completely
overlooking..


Eric

 

[Jon A. Cruz]

Basically, we are working on a messaging system. We have a message
which must conform to a specific format to pass information to other
similar systems. We use an editing component to produce these
messages. I want a jframe derrived frame to be used as the basis,
where all the send buttons and address information will always be the
same...the message content will be different for each type of message.

For each new message, I want to derrive a new message editing frame
for that speicif message, showing the different fields for each new
message in the message section of the base class.

That's the key right there. That information is most relavent to giving
you the solution you need.

To avoid some of the specifics, I gave the previous abstract version
to try and make things similar to understand.

But that's exactly what you should not do. As they say, "The devil is in
the details". Abstract too much, and you lose context. In your case you
stripped out all the context of *what* you were trying to do, and only
asked about *how* you thought you should reach that goal.

Let me try one more time...

If I have a JFrame (Frame1), with a JPanel (Panel1) on this frame
defined in a BaseClass...what is the proper way to put items on Panel1
from a derrived class (DerrivedClass extends BaseClass; ).

Hmmm.... I'm not sure that's getting to exactly what you need to ask.
However, we'll have to think about it.

OK. Thought about it.

I don't think I want to tell you how to do that.

From your longer description, that does not sound as good.



Ok. So what we *do* know about your needs (The 'what' you need to
accomplish):

* You deal with 'Messages'

* Messages must conform to some format to interoperate with other systems.

* You use and editing component to produce these Messages.

* I am guessing that you need to present an editing component that has
entry fields pertinent to the Message type in question


Now, onto your choice for implementation to solve the problem:

* Currently you think that you want to derive a custom editing UI frame
for each Message type.

* You want to get to an more OO design.


Now, unless there are more hidden requirements, this would be how I
would chose to address it:


First, I am assuming you have some "Message" class. That's your data
model. Good.

Ooops. We just hit a problem. How do these Messages differ? What kind of
properties do they have? How do the screens for different messages differ?

Hmm... let's get into some psuedo java for the use of the proposed system.


MessageEditor edit = new MessageEditor( XXXX

Oops. Problem. What makes Messages different? Class? Name? Static 'enum'?

in foo constructor:

MessageEditor edit = new MessageEditor( "Type1" ); // Maybe string?
editArea.setEditor( edit ); // called each time you switch to editing a
different type.

There. Done.

OK. You mentioned a send button and address info. The send button
definitely sounds like a transport function, not a part of editing a
message. I know it's a hair-splitting distinction, but it does matter here.

In this case, the same thing that creates and holds the MessageEditor
would also setup the "send" button:

later in foo constructor:

JButton btn = new JButton( "Send" );
btn.addActionListener( new ActionListener(){
void actionPerformed(ActionEvent evt)
{
sendCurrentMessage();
}
} );

then later, somewhere in the foo class:

public void sendCurrentMessage()
{
Message msg = editArea.getEditor().getMessage();
MessageAddressing addr = addressArea.getAddressing();
messageTransport.send( msg, addr );
}




Hmm.... ok. But we still haven't gotten to the actual UI yet.

class MessageEditor extends JPanel
{
Message msg;
MessageListener listener;
UIDescription descr;

public MessageEditor( String messageType )
{
setLayout( new GridBagLayout() );

// Assuming that there is a nice message factory method
msg = Message.create( messageType );

// Assuming that you went with the beans model for your Messages
listener = new MessageListener();
// MessageListener implements both of the interfaces needed:
msg.addPropertyChangeListener( listener );
msg.addVetoableChangeListener( listener );

// This next object will be used by both buildUI() and by the
// MessageListener subclass.
UIDescription descr = getUIDescription( messageType );
buildUI();
}


void buildUI( UIDescription descr )
{
// OK. Here is the meat of the problem.
// Depending on the subtle details, this can vary wildly.

Enumeration enum = descr.getElements();
while ( enum.hasMoreElements() )
{
UIItem item = (UIItem)enum.nextElement();
switch ( item.getWidgetType() )
{
case Message.BOOLEAN:
{
JCheckBox widget = new JCheckBox( item.label );
widget.setActionCommand( item.getPropertyName() );
// that magic class again:
widget.addActionListener( listener );
item.setJComponent( widget );
add( widget, item.getGBConstraints() );
}
....
}
}
}


Now, when MessageListener gets an actionPerformed() call, it just calls
getActionCommand() on the event, and looks that up in the descr list to
see which MessageProperty that maps to. And it can then update the UI
JComponent and the msg instance at the same time. Additionally, when a
propertyChange() gets called, the MessageListener class updates just the
UI widget mapped to the property.


and... BINGO! no subclasses of the editing frame needed. Also, if the
descriptions are stored in a resource that is loaded at runtime, you can
tweak the layout and even add new messages without ever compiling a
single line of new code.

Do it some other way which I'm sure I'm probably completely
overlooking..

Hopefully this might give you a little more insight as to what I was
describing.