Home » Archived » Visual Editor (VE) » Pattern Style suggestion and GridBagConstraint question
| Pattern Style suggestion and GridBagConstraint question [message #65677] |
Fri, 08 October 2004 05:13  |
Eclipse User |
|
|
|
Originally posted by: fernandez_marce.yahoo.com
Hello, I'm working with Visual Editor/Swing. It's a very good tool, but I
wanted to ask: why VE creates one GridBagConstraint for every component in
the form? I think VE should create one GridBagConstraint object and calling
a new() for setting another component after an .add(button,
button_constraint) call.
What do you think about another pattern style like this:
private JPanel getnorth_panel() {
if (north_panel == null) {
GridBagConstraint gbc;
// Declaration Section
north_panel = new JPanel();
north_panel.setLayout(new GridBagLayout());
// Component No. 1 Section
gbc = new GridBagConstraint();
label1 = new JLabel();
label1.setText("Hello World!");
lablel1.setFont(new java.awt.Font("SansSerif", java.awt.Font.BOLD, 18));
gbc.gridx = 0;
gbc.gridy = 0;
gbc.gridheight=2;
gbc.weightx = 100.0D;
north_panel.add(label1, gbc);
// Component No. 2 Section
gbc = new GridBagConstraint();
text1 = new JTextField();
text1.setText("");
gbc.gridx = 1;
gbc.gridy = 0;
gbc.gridheight=2;
gbc.anchor = java.awt.GridBagConstraints.WEST;
north_panel.add(text1,gbc);
// Component No. x Section
// Create a new gbc using 'gbc' variable, set it up with to the new
component and add it to the container.
......
}
}
I think if VE groups code for every component in different sections, it is
more readable.
(I remember Netbeans creating code like this, it could be called "Netbeans
pattern) :D
Thanks
Marcelo
|
|
| |
| Re: Pattern Style suggestion and GridBagConstraint question [message #66847 is a reply to message #66458] |
Tue, 12 October 2004 21:31  |
| Eclipse User |
|
|
|
Originally posted by: fernandez_marce.yahoo.com
Joe Winchester wrote:
> Hi Marcelo,
>
>> Hello, I'm working with Visual Editor/Swing. It's a very good tool, but I
>> wanted to ask: why VE creates one GridBagConstraint for every component
>> in the form? I think VE should create one GridBagConstraint object and
>> calling a new() for setting another component after an .add(button,
>> button_constraint) call.
>
> The problem we have with the pattern you've described is that it creates
> an identity management issue. Imagine if you selected the first
> component and changed one of its constraint's properties. This would
> affect not only it but all other components sharing the same constraint
> that hadn't explicitly overridden that property. From a GUI perspective
> we'd need to indicate that somehow as it's not how other properties
> work. Also from a model point of view if the component that is
> responsible for initializing the first set of properties on the
> constraint was deleted what would happen to the downstream ones ? Would
> the overridden properties be carried forward onto the next component
> so they all remained unaltered, or would they just revert to whatever
> their current state was.
>
> We should think about this however as it does create for simpler code to
> have a single constraint, and also as you point out other GUI builders
> generate that pattern and VE user should be able to import source
> created by other IDE tools. Could you plesae open a bugzilla feature
> request for this ?
>
> Best regards,
>
> Joe Winchester
Mmm yeah... I was thinking the same when I looked back to a Netbeans code
example. But there is no problem about overriding properties. The Netbeans
solution is that if you generate a new GridBagConstraint() object before
setting that particular object constraints, the gbc variable is a reference
to another object in memory, without any properties; and the Garbage
Collector should take care of the previous ('older') GridBagConstraint
object.
Look at this:
// Declaration
GridBagConstraint gbc;
// Component No. 1 Section
gbc = new GridBagConstraint();
label1 = new JLabel();
// .... (Set label1 constraints in gbc.xxx)
north_panel.add(label1, gbc);
// Component No. 2 Section
gbc = new GridBagConstraint(); // Now gbc variable points TO ANOTHER Grid
Bag Constraint object... and GC should dispose the old one.
text1 = new JTextField();
north_panel.add(text1,gbc);
// Component No. x Section
// Create a new gbc using 'gbc' variable, set it u p with to the new
component and add it to the container.......
This approach doesn't make it easier to add as a new feature for VE?
Regards,
Marcelo
|
|
| |
| Re: Pattern Style suggestion and GridBagConstraint question [message #67348 is a reply to message #66908] |
Mon, 18 October 2004 15:53 |
| Eclipse User |
|
|
|
Originally posted by: mendelgili.netscape.net
Joe Winchester wrote:
> Hi Marcelo,
>
>> Mmm yeah... I was thinking the same when I looked back to a Netbeans code
>> example. But there is no problem about overriding properties. The
>> Netbeans
>> solution is that if you generate a new GridBagConstraint() object before
>> setting that particular object constraints, the gbc variable is a
>> reference
>> to another object in memory, without any properties; and the Garbage
>> Collector should take care of the previous ('older') GridBagConstraint
>> object.
>
>
> Got it, thanks. Yes - we could have a single variable and just re-use
> it. Please do open a bugzilla feature request for this.
>
> Best regards,
>
> Joe Winchester
This will require some thinking.... we currently model instance/allocation/properties
In this pattern, the same instance is used multiple times, potentially with different progression set of properties that
are Dependant on the order/location of the instance usage. It can be solved... but is not cheep :-(
Given that that constraints are local, after compiler optimization the current VE code pattern is likely to be as
efficient. The only big gripe I would have with the current code pattern is the weired names we give these
constraints.... be nice for to name to relate to the instance they are used for, so that it is more readable. e.g...
label1Constraint, text1Constraint etc.
|
|
| |
| Re: Pattern Style suggestion and GridBagConstraint question [message #601437 is a reply to message #66458] |
Tue, 12 October 2004 21:31 |
 Marcelo Fernandez
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Joe Winchester wrote:
> Hi Marcelo,
>
>> Hello, I'm working with Visual Editor/Swing. It's a very good tool, but I
>> wanted to ask: why VE creates one GridBagConstraint for every component
>> in the form? I think VE should create one GridBagConstraint object and
>> calling a new() for setting another component after an .add(button,
>> button_constraint) call.
>
> The problem we have with the pattern you've described is that it creates
> an identity management issue. Imagine if you selected the first
> component and changed one of its constraint's properties. This would
> affect not only it but all other components sharing the same constraint
> that hadn't explicitly overridden that property. From a GUI perspective
> we'd need to indicate that somehow as it's not how other properties
> work. Also from a model point of view if the component that is
> responsible for initializing the first set of properties on the
> constraint was deleted what would happen to the downstream ones ? Would
> the overridden properties be carried forward onto the next component
> so they all remained unaltered, or would they just revert to whatever
> their current state was.
>
> We should think about this however as it does create for simpler code to
> have a single constraint, and also as you point out other GUI builders
> generate that pattern and VE user should be able to import source
> created by other IDE tools. Could you plesae open a bugzilla feature
> request for this ?
>
> Best regards,
>
> Joe Winchester
Mmm yeah... I was thinking the same when I looked back to a Netbeans code
example. But there is no problem about overriding properties. The Netbeans
solution is that if you generate a new GridBagConstraint() object before
setting that particular object constraints, the gbc variable is a reference
to another object in memory, without any properties; and the Garbage
Collector should take care of the previous ('older') GridBagConstraint
object.
Look at this:
// Declaration
GridBagConstraint gbc;
// Component No. 1 Section
gbc = new GridBagConstraint();
label1 = new JLabel();
// .... (Set label1 constraints in gbc.xxx)
north_panel.add(label1, gbc);
// Component No. 2 Section
gbc = new GridBagConstraint(); // Now gbc variable points TO ANOTHER Grid
Bag Constraint object... and GC should dispose the old one.
text1 = new JTextField();
north_panel.add(text1,gbc);
// Component No. x Section
// Create a new gbc using 'gbc' variable, set it u p with to the new
component and add it to the container.......
This approach doesn't make it easier to add as a new feature for VE?
Regards,
Marcelo
|
|
| |
| Re: Pattern Style suggestion and GridBagConstraint question [message #601788 is a reply to message #66908] |
Mon, 18 October 2004 15:53 |
Gili Mendel
Messages: 338
Registered: July 2009 |
Senior Member |
|
|
Joe Winchester wrote:
> Hi Marcelo,
>
>> Mmm yeah... I was thinking the same when I looked back to a Netbeans code
>> example. But there is no problem about overriding properties. The
>> Netbeans
>> solution is that if you generate a new GridBagConstraint() object before
>> setting that particular object constraints, the gbc variable is a
>> reference
>> to another object in memory, without any properties; and the Garbage
>> Collector should take care of the previous ('older') GridBagConstraint
>> object.
>
>
> Got it, thanks. Yes - we could have a single variable and just re-use
> it. Please do open a bugzilla feature request for this.
>
> Best regards,
>
> Joe Winchester
This will require some thinking.... we currently model instance/allocation/properties
In this pattern, the same instance is used multiple times, potentially with different progression set of properties that
are Dependant on the order/location of the instance usage. It can be solved... but is not cheep :-(
Given that that constraints are local, after compiler optimization the current VE code pattern is likely to be as
efficient. The only big gripe I would have with the current code pattern is the weired names we give these
constraints.... be nice for to name to relate to the instance they are used for, so that it is more readable. e.g...
label1Constraint, text1Constraint etc.
|
|
|
Goto Forum:
Current Time: Thu Dec 26 21:56:30 GMT 2024
Powered by FUDForum. Page generated in 0.05595 seconds |
] 
Search
Help
Register
Login
Home
