Home » Archived » Visual Editor (VE) » Design editor preview not work when subclassing AbstractTableModel
| Design editor preview not work when subclassing AbstractTableModel [message #6615] |
Mon, 01 December 2003 09:03  |
Eclipse User |
|
|
|
T have a jScrollpane and a table inside. Till there is all ok, but when I
inserted a tablemodel to specify table behaviour, it looks VE can't evaluate
my code.
The table at javabean view is shown with a little red x icon and on onover
it shows:
java.lang.InstantiationException (IWAVO1251E new
javax.swing.JTable(getTableModel())) is too complicated to be evaluated.
getTable code:
private javax.swing.JTable getJTable() {
if (jTable == null) {
jTable = new javax.swing.JTable(getTableModel());
jTable.setShowGrid(true);
jTable.setShowHorizontalLines(true);
}
return jTable;
}
Here the model is created :
private TableModel getTableModel() {
if (dtm == null) {
dtm = new AbstractTableModel() {
public Class getColumnClass(int c) {
return getValueAt(0, c).getClass();
}
public String getColumnName(int i) {
return i == 0 ? "Sele
|
|
| | | | | | | |
| Re: Design editor preview not work when subclassing AbstractTableModel [message #7452 is a reply to message #7431] |
Mon, 01 December 2003 18:20  |
| Eclipse User |
|
|
|
Originally posted by: emerson.tre-sc.gov.br
I created an inner class (not anonymous). At first I tried to make it
static.
But in this way I can't access attributes of my subclass of JFrame class,
since i got an error that I can't reference the list that is member of my
frame. Could it be better to put those needed attributes inside my
DataModel. But i need then in other methods of my main Frame. I can put
get methods on this attributes and use it from those methods. What is the
prefered way.
If i made the class model final I got the error :
- NoSuchMethodException (TesteFrame@FilesTableModel)
Sorry if the questions are swing related, just want to know what's the
better way with VE.
TesteFrame@FilesTableModel:
public final class FilesTableModel extends AbstractTableModel {
public Class getColumnClass(int c) {
return getValueAt(0, c).getClass();
}
public String getColumnName(int i) {
return i == 0 ? "Seleção" : "Arquivo";
}
public int getColumnCount() {
return 3;
}
public int getRowCount() {
return arquivos.size();
}
public Object getValueAt(int rowIndex, int columnIndex) {
if (columnIndex == 0) {
return (Boolean) arquivosSelecao.get(rowIndex);
} else if (columnIndex == 1) {
return ((File) arquivos.get(rowIndex)).getName();
} else
return (Long) new Long(((File)
arquivos.get(rowIndex)).length());
}
}
Thnaks a lot for your response !!! :)
Joe Winchester wrote:
> Hi Emerson,
> > Now it show the table right but the visual model has the red 'x' saying it
> > was too complicated :) I think VE doesn't accept anonymous classes to be
> > parsed. Am i right?
> Here's the reasons we currently don't support inner classes as method
arguments.
> We parse the string OK and realize it's anonymous, the problem is one of
> evaluation. Consider the statements
> jButton.setBackground(java.awt.Color.red);
> or
> jButton.setText("Foo");
> For both of these we evaluate the set method argument and work out what it
> represents. For the first one it's a static field called red on the class
> java.awt.Color, on the second it's a String literal. We can then use the
APIs in
> the java.lang.reflect package to actually create the red color object or the
Foo
> string. The parser and evaluator we use deals with a wide variety of
expressions
> including arrays, cast statements, etc...
> For an inner class however there is nothing we could think of doing.
Consider the
> code
> jTable.setModel(new AbstractTableModel()){
> public int getColumnCount(){
> return 4;
> }
> //... etc... rest of overridden methods
> }
> There is no actual class that we can instantiate here. The Visual Editor
parses
> and evaluates method argument expressions on the pre-saved Java source that
may
> not necessarily have been compiled. Even if it did then to get an inner
class
> instance we'd have to actually instantiate the outer class and there may be
errors
> that prevent this. One thing we could possibly do is try and create a fake
class
> that looks like the inner class so we base it off the same method bodies,
but what
> if it referenced state of the containg class such as
> int foo = 4;
> Table.setModel(new AbstractTableModel()){
> public int getColumnCount(){
> return foo;
> }
> //... etc... rest of overridden methods
> }
> Even if we did fake out our own separate class that subclassed
AbstractTableModel
> we'd have to do some smoke and mirrors to get the references to the outer
class
> resolved correctly.
> If the class is a static inner class or a real separate named TableModel
class
> then it can be instantiated in its own right using the java.lang.reflect
APIs and
> we can evaluate it. This is the reason this solution works.
> Because we can't handle inner classes Iin our current release we realize
there is
> an inner class and just put the error sign up. It should however not be a
redX
> but a blue exclamation mark - the redX is supposed to indicate a potential
runtime
> error whereas we wanted blue exclaimation marks to indicate that there was
no real
> user error and instead was a Visual Editor limitation that we realize that
what
> you're looking at in design time is going to look different at runtime
because
> some of the method expressions couldn't be evaluated and applied. I'll test
this
> and create a bugzilla if I can re-create it being redX and not blue warning.
> I hope this explanation helps to understand why we put the error up. We do
need a
> better way to tackle this however so if anyone has any great ideas about how
to
> evaluate inner class expressions then please let us know.
> Best regards,
> Joe
|
|
| |
| Re: Design editor preview not work when subclassing AbstractTableModel [message #7473 is a reply to message #7452] |
Mon, 01 December 2003 19:38 |
| Eclipse User |
|
|
|
Hi Emerson,
> I created an inner class (not anonymous). At first I tried to make it
> static.
> But in this way I can't access attributes of my subclass of JFrame class,
> since i got an error that I can't reference the list that is member of my
> frame
This is sort of catch 22 for you. If you make the class static the Visual Editor
can instantiate it OK using java.lang.reflect APIs but you can't reference state
in the outer class instance. What you could do is have this state as properties
on the static inner class so having instantiated it you called set methods on the
model that passed these as field references.
Another option is to just subclass the JTable and put the extra behavior in the
subclass, giving it extra properties directly. This might not win any OO
separation awards but it would work because as far as the VE is concerned it's
just another black box.
One thing to consider, is that generally in an application the runtime data shown
in a JTable/JList might not be available at design time, and in fact it might not
be possible to access as lots of preliminary steps like logging onto back ends may
have not occurred because the design time VE is just concerned with the class
being edited rather than a larger application. Is your table model actually going
to work in design time, or are you putting up preview type data ? If it's preview
data then the reason we show the table by default with some rows and columns is to
give the designer a feel for how it's going to look in the current font, although
we have to make an assumption about the nunmber of columns. Maybe we should do
more work on the preview that we create to allow you to vary things like column
count, column width to get a better preview sense of how it's going to look at
runtime, but not try and actually run the table model live because this might even
really hurt performance if it had to sit on an unavailable connection wait during
editing.
Best regards,
Joe
|
|
|
| Re: Design editor preview not work when subclassing AbstractTableModel [message #7524 is a reply to message #7452] |
Tue, 02 December 2003 09:11 |
| Eclipse User |
|
|
|
Originally posted by: mendelgili.netscape.net
The best approach for using VE and a table model, is to create a
separate class for the table model (that can be instantiated with a null
constructor), with a set of properties (to initialize it properly, if
needed). Drop the table model on the FF, set properties using the
Property Sheet, and set the model to the getter method.
Emerson Cargnin wrote:
> I created an inner class (not anonymous). At first I tried to make it
> static.
>
> But in this way I can't access attributes of my subclass of JFrame class,
> since i got an error that I can't reference the list that is member of my
> frame. Could it be better to put those needed attributes inside my
> DataModel. But i need then in other methods of my main Frame. I can put
> get methods on this attributes and use it from those methods. What is the
> prefered way.
> If i made the class model final I got the error :
>
> - NoSuchMethodException (TesteFrame@FilesTableModel)
>
> Sorry if the questions are swing related, just want to know what's the
> better way with VE.
>
>
> TesteFrame@FilesTableModel:
>
> public final class FilesTableModel extends AbstractTableModel {
> public Class getColumnClass(int c) {
> return getValueAt(0, c).getClass();
> }
> public String getColumnName(int i) {
> return i == 0 ? "Seleção" : "Arquivo";
> }
> public int getColumnCount() {
> return 3;
> }
> public int getRowCount() {
> return arquivos.size();
> }
> public Object getValueAt(int rowIndex, int columnIndex) {
> if (columnIndex == 0) {
> return (Boolean) arquivosSelecao.get(rowIndex);
> } else if (columnIndex == 1) {
> return ((File) arquivos.get(rowIndex)).getName();
> } else
> return (Long) new Long(((File)
> arquivos.get(rowIndex)).length());
> }
> }
>
>
> Thnaks a lot for your response !!! :)
>
> Joe Winchester wrote:
>
>
>>Hi Emerson,
>
>
>>>Now it show the table right but the visual model has the red 'x' saying it
>>>was too complicated :) I think VE doesn't accept anonymous classes to be
>>>parsed. Am i right?
>
>
>>Here's the reasons we currently don't support inner classes as method
>
> arguments.
>
>>We parse the string OK and realize it's anonymous, the problem is one of
>>evaluation. Consider the statements
>
>
>>jButton.setBackground(java.awt.Color.red);
>>or
>>jButton.setText("Foo");
>
>
>>For both of these we evaluate the set method argument and work out what it
>>represents. For the first one it's a static field called red on the class
>>java.awt.Color, on the second it's a String literal. We can then use the
>
> APIs in
>
>>the java.lang.reflect package to actually create the red color object or the
>
> Foo
>
>>string. The parser and evaluator we use deals with a wide variety of
>
> expressions
>
>>including arrays, cast statements, etc...
>
>
>>For an inner class however there is nothing we could think of doing.
>
> Consider the
>
>>code
>
>
>>jTable.setModel(new AbstractTableModel()){
>> public int getColumnCount(){
>> return 4;
>> }
>> //... etc... rest of overridden methods
>>}
>
>
>>There is no actual class that we can instantiate here. The Visual Editor
>
> parses
>
>>and evaluates method argument expressions on the pre-saved Java source that
>
> may
>
>>not necessarily have been compiled. Even if it did then to get an inner
>
> class
>
>>instance we'd have to actually instantiate the outer class and there may be
>
> errors
>
>>that prevent this. One thing we could possibly do is try and create a fake
>
> class
>
>>that looks like the inner class so we base it off the same method bodies,
>
> but what
>
>>if it referenced state of the containg class such as
>
>
>>int foo = 4;
>>Table.setModel(new AbstractTableModel()){
>> public int getColumnCount(){
>> return foo;
>> }
>> //... etc... rest of overridden methods
>>}
>
>
>>Even if we did fake out our own separate class that subclassed
>
> AbstractTableModel
>
>>we'd have to do some smoke and mirrors to get the references to the outer
>
> class
>
>>resolved correctly.
>
>
>>If the class is a static inner class or a real separate named TableModel
>
> class
>
>>then it can be instantiated in its own right using the java.lang.reflect
>
> APIs and
>
>>we can evaluate it. This is the reason this solution works.
>
>
>>Because we can't handle inner classes Iin our current release we realize
>
> there is
>
>>an inner class and just put the error sign up. It should however not be a
>
> redX
>
>>but a blue exclamation mark - the redX is supposed to indicate a potential
>
> runtime
>
>>error whereas we wanted blue exclaimation marks to indicate that there was
>
> no real
>
>>user error and instead was a Visual Editor limitation that we realize that
>
> what
>
>>you're looking at in design time is going to look different at runtime
>
> because
>
>>some of the method expressions couldn't be evaluated and applied. I'll test
>
> this
>
>>and create a bugzilla if I can re-create it being redX and not blue warning.
>
>
>>I hope this explanation helps to understand why we put the error up. We do
>
> need a
>
>>better way to tackle this however so if anyone has any great ideas about how
>
> to
>
>>evaluate inner class expressions then please let us know.
>
>
>>Best regards,
>
>
>>Joe
>
>
>
|
|
| | |
| Re: Design editor preview not work when subclassing AbstractTableModel [message #8904 is a reply to message #8405] |
Sun, 07 December 2003 17:44 |
| Eclipse User |
|
|
|
Hi "Bodo Hüsemann",
> Joe stated that doing this:
Uh oh - I knew I sould have kept quiet
> It happens that
> jTable = new javax.swing.JTable(QueryThreadPanel.DEFAULT_ROWCOUNT,2);
> is "to complicated to be evaluated" with a red sign, but in my eyes is the
> same as the above example shown by joe. What is the trick in this case?
The class QueryThreadPanel needs to be qualified with the package name, e.g.
jTable = new
javax.swing.JTable(com.mycorp.mypackage.QueryThreadPanel.DEF AULT_ROWCOUNT,2);
Basically any class names must be fully qualified right now, under some
circumstances you can get away with not doing this (such as static method
calls), but not for static fields and also not for class names in arguments.
This is a known limitation and we're looking to to improve the whole area of
code parsing patterns and code snippit evaluation.
> Thanks for your help and this wonderful tool,
I love it when folks like your good self use phrases like "wonderful tool" to
describe the Visual Editor. When it was in WebSphere Studio Application
Developer a lot of the feedback we received contained different adjectives :-)
Best regards,
Joe
|
|
|
| Re: Design editor preview not work when subclassing AbstractTableModel [message #570748 is a reply to message #6615] |
Mon, 01 December 2003 09:21 |
| Eclipse User |
|
|
|
Emerson Cargnin wrote:
> T have a jScrollpane and a table inside. Till there is all ok, but when I
> inserted a tablemodel to specify table behaviour, it looks VE can't evaluate
> my code.
> The table at javabean view is shown with a little red x icon and on onover
> it shows:
> java.lang.InstantiationException (IWAVO1251E new
> javax.swing.JTable(getTableModel())) is too complicated to be evaluated.
>
> getTable code:
>
> private javax.swing.JTable getJTable() {
> if (jTable == null) {
> jTable = new javax.swing.JTable(getTableModel());
> jTable.setShowGrid(true);
> jTable.setShowHorizontalLines(true);
> }
> return jTable;
> }
>
> Here the model is created :
> private TableModel getTableModel() {
> if (dtm == null) {
> dtm = new AbstractTableModel() {
> public Class getColumnClass(int c) {
> return getValueAt(0, c).getClass();
> }
> public String getColumnName(int i) {
> return i == 0 ? "Seleção" : "Arquivo";
> }
> public int getColumnCount() {
> return 3;
> }
> public int getRowCount() {
> return arquivos.size();
> }
> public Object getValueAt(int rowIndex, int columnIndex) {
> if (columnIndex == 0) {
> return (Boolean) arquivosSelecao.get(rowIndex);
> } else if (columnIndex == 1) {
> return ((File) arquivos.get(rowIndex)).getName();
> } else
> return (Long) new Long(
> ((File) arquivos.get(rowIndex)).length());
> }
> };
> }
> return dtm;
> }
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.545 / Virus Database: 339 - Release Date: 27/11/2003
>
>
To set a table model, you will have and external class (or a static
class) to drop it on the FF (create an instance variable with an "ivj"
prefix).
The target VM will need to be able and instantiate it, to set the Table
Model's property. The "ivj" prefix, designate to JVE that the
non-visual (in this case the table model) is to be parsed/modeled.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=47564 for more
information.
|
|
|
| Re: Design editor preview not work when subclassing AbstractTableModel [message #570803 is a reply to message #6638] |
Mon, 01 December 2003 12:28 |
| Eclipse User |
|
|
|
I solved it in other way :
Just used the non-parameter constructor to create the
jTable = new javax.swing.JTable();
jTable.setModel(getTableModel());
> To set a table model, you will have and external class (or a static
> class) to drop it on the FF (create an instance variable with an "ivj"
> prefix).
> The target VM will need to be able and instantiate it, to set the Table
> Model's property. The "ivj" prefix, designate to JVE that the
> non-visual (in this case the table model) is to be parsed/modeled.
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=47564 for more
> information.
Gili Mendel wrote:
> Emerson Cargnin wrote:
> > T have a jScrollpane and a table inside. Till there is all ok, but when I
> > inserted a tablemodel to specify table behaviour, it looks VE can't
evaluate
> > my code.
> > The table at javabean view is shown with a little red x icon and on onover
> > it shows:
> > java.lang.InstantiationException (IWAVO1251E new
> > javax.swing.JTable(getTableModel())) is too complicated to be evaluated.
> >
> > getTable code:
> >
> > private javax.swing.JTable getJTable() {
> > if (jTable == null) {
> > jTable = new javax.swing.JTable(getTableModel());
> > jTable.setShowGrid(true);
> > jTable.setShowHorizontalLines(true);
> > }
> > return jTable;
> > }
> >
> > Here the model is created :
> > private TableModel getTableModel() {
> > if (dtm == null) {
> > dtm = new AbstractTableModel() {
> > public Class getColumnClass(int c) {
> > return getValueAt(0, c).getClass();
> > }
> > public String getColumnName(int i) {
> > return i == 0 ? "Seleção" : "Arquivo";
> > }
> > public int getColumnCount() {
> > return 3;
> > }
> > public int getRowCount() {
> > return arquivos.size();
> > }
> > public Object getValueAt(int rowIndex, int columnIndex) {
> > if (columnIndex == 0) {
> > return (Boolean) arquivosSelecao.get(rowIndex);
> > } else if (columnIndex == 1) {
> > return ((File) arquivos.get(rowIndex)).getName();
> > } else
> > return (Long) new Long(
> > ((File) arquivos.get(rowIndex)).length());
> > }
> > };
> > }
> > return dtm;
> > }
> >
> >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.545 / Virus Database: 339 - Release Date: 27/11/2003
> >
> >
|
|
|
| Re: Design editor preview not work when subclassing AbstractTableModel [message #570836 is a reply to message #6638] |
Mon, 01 December 2003 12:29 |
| Eclipse User |
|
|
|
(sorry, I send before finish)
I solved it in other way :
Just used the non-parameter constructor to create the table and after it
used the setModel afterwards.
jTable = new javax.swing.JTable();
jTable.setModel(getTableModel());
> To set a table model, you will have and external class (or a static
> class) to drop it on the FF (create an instance variable with an "ivj"
> prefix).
> The target VM will need to be able and instantiate it, to set the Table
> Model's property. The "ivj" prefix, designate to JVE that the
> non-visual (in this case the table model) is to be parsed/modeled.
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=47564 for more
> information.
Gili Mendel wrote:
> Emerson Cargnin wrote:
> > T have a jScrollpane and a table inside. Till there is all ok, but when I
> > inserted a tablemodel to specify table behaviour, it looks VE can't
evaluate
> > my code.
> > The table at javabean view is shown with a little red x icon and on onover
> > it shows:
> > java.lang.InstantiationException (IWAVO1251E new
> > javax.swing.JTable(getTableModel())) is too complicated to be evaluated.
> >
> > getTable code:
> >
> > private javax.swing.JTable getJTable() {
> > if (jTable == null) {
> > jTable = new javax.swing.JTable(getTableModel());
> > jTable.setShowGrid(true);
> > jTable.setShowHorizontalLines(true);
> > }
> > return jTable;
> > }
> >
> > Here the model is created :
> > private TableModel getTableModel() {
> > if (dtm == null) {
> > dtm = new AbstractTableModel() {
> > public Class getColumnClass(int c) {
> > return getValueAt(0, c).getClass();
> > }
> > public String getColumnName(int i) {
> > return i == 0 ? "Seleção" : "Arquivo";
> > }
> > public int getColumnCount() {
> > return 3;
> > }
> > public int getRowCount() {
> > return arquivos.size();
> > }
> > public Object getValueAt(int rowIndex, int columnIndex) {
> > if (columnIndex == 0) {
> > return (Boolean) arquivosSelecao.get(rowIndex);
> > } else if (columnIndex == 1) {
> > return ((File) arquivos.get(rowIndex)).getName();
> > } else
> > return (Long) new Long(
> > ((File) arquivos.get(rowIndex)).length());
> > }
> > };
> > }
> > return dtm;
> > }
> >
> >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.545 / Virus Database: 339 - Release Date: 27/11/2003
> >
> >
|
|
|
| Re: Design editor preview not work when subclassing AbstractTableModel [message #570872 is a reply to message #6638] |
Mon, 01 December 2003 12:38 |
| Eclipse User |
|
|
|
Now it show the table right but the visual model has the red 'x' saying it
was too complicated :) I think VE doesn't accept anonymous classes to be
parsed. Am i right?
Gili Mendel wrote:
> Emerson Cargnin wrote:
> > T have a jScrollpane and a table inside. Till there is all ok, but when I
> > inserted a tablemodel to specify table behaviour, it looks VE can't
evaluate
> > my code.
> > The table at javabean view is shown with a little red x icon and on onover
> > it shows:
> > java.lang.InstantiationException (IWAVO1251E new
> > javax.swing.JTable(getTableModel())) is too complicated to be evaluated.
> >
> > getTable code:
> >
> > private javax.swing.JTable getJTable() {
> > if (jTable == null) {
> > jTable = new javax.swing.JTable(getTableModel());
> > jTable.setShowGrid(true);
> > jTable.setShowHorizontalLines(true);
> > }
> > return jTable;
> > }
> >
> > Here the model is created :
> > private TableModel getTableModel() {
> > if (dtm == null) {
> > dtm = new AbstractTableModel() {
> > public Class getColumnClass(int c) {
> > return getValueAt(0, c).getClass();
> > }
> > public String getColumnName(int i) {
> > return i == 0 ? "Seleção" : "Arquivo";
> > }
> > public int getColumnCount() {
> > return 3;
> > }
> > public int getRowCount() {
> > return arquivos.size();
> > }
> > public Object getValueAt(int rowIndex, int columnIndex) {
> > if (columnIndex == 0) {
> > return (Boolean) arquivosSelecao.get(rowIndex);
> > } else if (columnIndex == 1) {
> > return ((File) arquivos.get(rowIndex)).getName();
> > } else
> > return (Long) new Long(
> > ((File) arquivos.get(rowIndex)).length());
> > }
> > };
> > }
> > return dtm;
> > }
> >
> >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.545 / Virus Database: 339 - Release Date: 27/11/2003
> >
> >
> To set a table model, you will have and external class (or a static
> class) to drop it on the FF (create an instance variable with an "ivj"
> prefix).
> The target VM will need to be able and instantiate it, to set the Table
> Model's property. The "ivj" prefix, designate to JVE that the
> non-visual (in this case the table model) is to be parsed/modeled.
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=47564 for more
> information.
|
|
| |
| Re: Design editor preview not work when subclassing AbstractTableModel [message #571269 is a reply to message #7345] |
Mon, 01 December 2003 17:11 |
| Eclipse User |
|
|
|
Hi Emerson,
> Now it show the table right but the visual model has the red 'x' saying it
> was too complicated :) I think VE doesn't accept anonymous classes to be
> parsed. Am i right?
Here's the reasons we currently don't support inner classes as method arguments.
We parse the string OK and realize it's anonymous, the problem is one of
evaluation. Consider the statements
jButton.setBackground(java.awt.Color.red);
or
jButton.setText("Foo");
For both of these we evaluate the set method argument and work out what it
represents. For the first one it's a static field called red on the class
java.awt.Color, on the second it's a String literal. We can then use the APIs in
the java.lang.reflect package to actually create the red color object or the Foo
string. The parser and evaluator we use deals with a wide variety of expressions
including arrays, cast statements, etc...
For an inner class however there is nothing we could think of doing. Consider the
code
jTable.setModel(new AbstractTableModel()){
public int getColumnCount(){
return 4;
}
//... etc... rest of overridden methods
}
There is no actual class that we can instantiate here. The Visual Editor parses
and evaluates method argument expressions on the pre-saved Java source that may
not necessarily have been compiled. Even if it did then to get an inner class
instance we'd have to actually instantiate the outer class and there may be errors
that prevent this. One thing we could possibly do is try and create a fake class
that looks like the inner class so we base it off the same method bodies, but what
if it referenced state of the containg class such as
int foo = 4;
Table.setModel(new AbstractTableModel()){
public int getColumnCount(){
return foo;
}
//... etc... rest of overridden methods
}
Even if we did fake out our own separate class that subclassed AbstractTableModel
we'd have to do some smoke and mirrors to get the references to the outer class
resolved correctly.
If the class is a static inner class or a real separate named TableModel class
then it can be instantiated in its own right using the java.lang.reflect APIs and
we can evaluate it. This is the reason this solution works.
Because we can't handle inner classes Iin our current release we realize there is
an inner class and just put the error sign up. It should however not be a redX
but a blue exclamation mark - the redX is supposed to indicate a potential runtime
error whereas we wanted blue exclaimation marks to indicate that there was no real
user error and instead was a Visual Editor limitation that we realize that what
you're looking at in design time is going to look different at runtime because
some of the method expressions couldn't be evaluated and applied. I'll test this
and create a bugzilla if I can re-create it being redX and not blue warning.
I hope this explanation helps to understand why we put the error up. We do need a
better way to tackle this however so if anyone has any great ideas about how to
evaluate inner class expressions then please let us know.
Best regards,
Joe
|
|
|
| Re: Design editor preview not work when subclassing AbstractTableModel [message #571331 is a reply to message #7431] |
Mon, 01 December 2003 18:02 |
| Eclipse User |
|
|
|
Thnaks a lot for your response !!! :)
Joe Winchester wrote:
> Hi Emerson,
> > Now it show the table right but the visual model has the red 'x' saying it
> > was too complicated :) I think VE doesn't accept anonymous classes to be
> > parsed. Am i right?
> Here's the reasons we currently don't support inner classes as method
arguments.
> We parse the string OK and realize it's anonymous, the problem is one of
> evaluation. Consider the statements
> jButton.setBackground(java.awt.Color.red);
> or
> jButton.setText("Foo");
> For both of these we evaluate the set method argument and work out what it
> represents. For the first one it's a static field called red on the class
> java.awt.Color, on the second it's a String literal. We can then use the
APIs in
> the java.lang.reflect package to actually create the red color object or the
Foo
> string. The parser and evaluator we use deals with a wide variety of
expressions
> including arrays, cast statements, etc...
> For an inner class however there is nothing we could think of doing.
Consider the
> code
> jTable.setModel(new AbstractTableModel()){
> public int getColumnCount(){
> return 4;
> }
> //... etc... rest of overridden methods
> }
> There is no actual class that we can instantiate here. The Visual Editor
parses
> and evaluates method argument expressions on the pre-saved Java source that
may
> not necessarily have been compiled. Even if it did then to get an inner
class
> instance we'd have to actually instantiate the outer class and there may be
errors
> that prevent this. One thing we could possibly do is try and create a fake
class
> that looks like the inner class so we base it off the same method bodies,
but what
> if it referenced state of the containg class such as
> int foo = 4;
> Table.setModel(new AbstractTableModel()){
> public int getColumnCount(){
> return foo;
> }
> //... etc... rest of overridden methods
> }
> Even if we did fake out our own separate class that subclassed
AbstractTableModel
> we'd have to do some smoke and mirrors to get the references to the outer
class
> resolved correctly.
> If the class is a static inner class or a real separate named TableModel
class
> then it can be instantiated in its own right using the java.lang.reflect
APIs and
> we can evaluate it. This is the reason this solution works.
> Because we can't handle inner classes Iin our current release we realize
there is
> an inner class and just put the error sign up. It should however not be a
redX
> but a blue exclamation mark - the redX is supposed to indicate a potential
runtime
> error whereas we wanted blue exclaimation marks to indicate that there was
no real
> user error and instead was a Visual Editor limitation that we realize that
what
> you're looking at in design time is going to look different at runtime
because
> some of the method expressions couldn't be evaluated and applied. I'll test
this
> and create a bugzilla if I can re-create it being redX and not blue warning.
> I hope this explanation helps to understand why we put the error up. We do
need a
> better way to tackle this however so if anyone has any great ideas about how
to
> evaluate inner class expressions then please let us know.
> Best regards,
> Joe
|
|
|
| Re: Design editor preview not work when subclassing AbstractTableModel [message #571383 is a reply to message #7431] |
Mon, 01 December 2003 18:20 |
| Eclipse User |
|
|
|
I created an inner class (not anonymous). At first I tried to make it
static.
But in this way I can't access attributes of my subclass of JFrame class,
since i got an error that I can't reference the list that is member of my
frame. Could it be better to put those needed attributes inside my
DataModel. But i need then in other methods of my main Frame. I can put
get methods on this attributes and use it from those methods. What is the
prefered way.
If i made the class model final I got the error :
- NoSuchMethodException (TesteFrame@FilesTableModel)
Sorry if the questions are swing related, just want to know what's the
better way with VE.
TesteFrame@FilesTableModel:
public final class FilesTableModel extends AbstractTableModel {
public Class getColumnClass(int c) {
return getValueAt(0, c).getClass();
}
public String getColumnName(int i) {
return i == 0 ? "Seleção" : "Arquivo";
}
public int getColumnCount() {
return 3;
}
public int getRowCount() {
return arquivos.size();
}
public Object getValueAt(int rowIndex, int columnIndex) {
if (columnIndex == 0) {
return (Boolean) arquivosSelecao.get(rowIndex);
} else if (columnIndex == 1) {
return ((File) arquivos.get(rowIndex)).getName();
} else
return (Long) new Long(((File)
arquivos.get(rowIndex)).length());
}
}
Thnaks a lot for your response !!! :)
Joe Winchester wrote:
> Hi Emerson,
> > Now it show the table right but the visual model has the red 'x' saying it
> > was too complicated :) I think VE doesn't accept anonymous classes to be
> > parsed. Am i right?
> Here's the reasons we currently don't support inner classes as method
arguments.
> We parse the string OK and realize it's anonymous, the problem is one of
> evaluation. Consider the statements
> jButton.setBackground(java.awt.Color.red);
> or
> jButton.setText("Foo");
> For both of these we evaluate the set method argument and work out what it
> represents. For the first one it's a static field called red on the class
> java.awt.Color, on the second it's a String literal. We can then use the
APIs in
> the java.lang.reflect package to actually create the red color object or the
Foo
> string. The parser and evaluator we use deals with a wide variety of
expressions
> including arrays, cast statements, etc...
> For an inner class however there is nothing we could think of doing.
Consider the
> code
> jTable.setModel(new AbstractTableModel()){
> public int getColumnCount(){
> return 4;
> }
> //... etc... rest of overridden methods
> }
> There is no actual class that we can instantiate here. The Visual Editor
parses
> and evaluates method argument expressions on the pre-saved Java source that
may
> not necessarily have been compiled. Even if it did then to get an inner
class
> instance we'd have to actually instantiate the outer class and there may be
errors
> that prevent this. One thing we could possibly do is try and create a fake
class
> that looks like the inner class so we base it off the same method bodies,
but what
> if it referenced state of the containg class such as
> int foo = 4;
> Table.setModel(new AbstractTableModel()){
> public int getColumnCount(){
> return foo;
> }
> //... etc... rest of overridden methods
> }
> Even if we did fake out our own separate class that subclassed
AbstractTableModel
> we'd have to do some smoke and mirrors to get the references to the outer
class
> resolved correctly.
> If the class is a static inner class or a real separate named TableModel
class
> then it can be instantiated in its own right using the java.lang.reflect
APIs and
> we can evaluate it. This is the reason this solution works.
> Because we can't handle inner classes Iin our current release we realize
there is
> an inner class and just put the error sign up. It should however not be a
redX
> but a blue exclamation mark - the redX is supposed to indicate a potential
runtime
> error whereas we wanted blue exclaimation marks to indicate that there was
no real
> user error and instead was a Visual Editor limitation that we realize that
what
> you're looking at in design time is going to look different at runtime
because
> some of the method expressions couldn't be evaluated and applied. I'll test
this
> and create a bugzilla if I can re-create it being redX and not blue warning.
> I hope this explanation helps to understand why we put the error up. We do
need a
> better way to tackle this however so if anyone has any great ideas about how
to
> evaluate inner class expressions then please let us know.
> Best regards,
> Joe
|
|
| |
| Re: Design editor preview not work when subclassing AbstractTableModel [message #571440 is a reply to message #7452] |
Mon, 01 December 2003 19:38 |
| Eclipse User |
|
|
|
Hi Emerson,
> I created an inner class (not anonymous). At first I tried to make it
> static.
> But in this way I can't access attributes of my subclass of JFrame class,
> since i got an error that I can't reference the list that is member of my
> frame
This is sort of catch 22 for you. If you make the class static the Visual Editor
can instantiate it OK using java.lang.reflect APIs but you can't reference state
in the outer class instance. What you could do is have this state as properties
on the static inner class so having instantiated it you called set methods on the
model that passed these as field references.
Another option is to just subclass the JTable and put the extra behavior in the
subclass, giving it extra properties directly. This might not win any OO
separation awards but it would work because as far as the VE is concerned it's
just another black box.
One thing to consider, is that generally in an application the runtime data shown
in a JTable/JList might not be available at design time, and in fact it might not
be possible to access as lots of preliminary steps like logging onto back ends may
have not occurred because the design time VE is just concerned with the class
being edited rather than a larger application. Is your table model actually going
to work in design time, or are you putting up preview type data ? If it's preview
data then the reason we show the table by default with some rows and columns is to
give the designer a feel for how it's going to look in the current font, although
we have to make an assumption about the nunmber of columns. Maybe we should do
more work on the preview that we create to allow you to vary things like column
count, column width to get a better preview sense of how it's going to look at
runtime, but not try and actually run the table model live because this might even
really hurt performance if it had to sit on an unavailable connection wait during
editing.
Best regards,
Joe
|
|
|
| Re: Design editor preview not work when subclassing AbstractTableModel [message #571620 is a reply to message #7452] |
Tue, 02 December 2003 09:11 |
| Eclipse User |
|
|
|
The best approach for using VE and a table model, is to create a
separate class for the table model (that can be instantiated with a null
constructor), with a set of properties (to initialize it properly, if
needed). Drop the table model on the FF, set properties using the
Property Sheet, and set the model to the getter method.
Emerson Cargnin wrote:
> I created an inner class (not anonymous). At first I tried to make it
> static.
>
> But in this way I can't access attributes of my subclass of JFrame class,
> since i got an error that I can't reference the list that is member of my
> frame. Could it be better to put those needed attributes inside my
> DataModel. But i need then in other methods of my main Frame. I can put
> get methods on this attributes and use it from those methods. What is the
> prefered way.
> If i made the class model final I got the error :
>
> - NoSuchMethodException (TesteFrame@FilesTableModel)
>
> Sorry if the questions are swing related, just want to know what's the
> better way with VE.
>
>
> TesteFrame@FilesTableModel:
>
> public final class FilesTableModel extends AbstractTableModel {
> public Class getColumnClass(int c) {
> return getValueAt(0, c).getClass();
> }
> public String getColumnName(int i) {
> return i == 0 ? "Seleção" : "Arquivo";
> }
> public int getColumnCount() {
> return 3;
> }
> public int getRowCount() {
> return arquivos.size();
> }
> public Object getValueAt(int rowIndex, int columnIndex) {
> if (columnIndex == 0) {
> return (Boolean) arquivosSelecao.get(rowIndex);
> } else if (columnIndex == 1) {
> return ((File) arquivos.get(rowIndex)).getName();
> } else
> return (Long) new Long(((File)
> arquivos.get(rowIndex)).length());
> }
> }
>
>
> Thnaks a lot for your response !!! :)
>
> Joe Winchester wrote:
>
>
>>Hi Emerson,
>
>
>>>Now it show the table right but the visual model has the red 'x' saying it
>>>was too complicated :) I think VE doesn't accept anonymous classes to be
>>>parsed. Am i right?
>
>
>>Here's the reasons we currently don't support inner classes as method
>
> arguments.
>
>>We parse the string OK and realize it's anonymous, the problem is one of
>>evaluation. Consider the statements
>
>
>>jButton.setBackground(java.awt.Color.red);
>>or
>>jButton.setText("Foo");
>
>
>>For both of these we evaluate the set method argument and work out what it
>>represents. For the first one it's a static field called red on the class
>>java.awt.Color, on the second it's a String literal. We can then use the
>
> APIs in
>
>>the java.lang.reflect package to actually create the red color object or the
>
> Foo
>
>>string. The parser and evaluator we use deals with a wide variety of
>
> expressions
>
>>including arrays, cast statements, etc...
>
>
>>For an inner class however there is nothing we could think of doing.
>
> Consider the
>
>>code
>
>
>>jTable.setModel(new AbstractTableModel()){
>> public int getColumnCount(){
>> return 4;
>> }
>> //... etc... rest of overridden methods
>>}
>
>
>>There is no actual class that we can instantiate here. The Visual Editor
>
> parses
>
>>and evaluates method argument expressions on the pre-saved Java source that
>
> may
>
>>not necessarily have been compiled. Even if it did then to get an inner
>
> class
>
>>instance we'd have to actually instantiate the outer class and there may be
>
> errors
>
>>that prevent this. One thing we could possibly do is try and create a fake
>
> class
>
>>that looks like the inner class so we base it off the same method bodies,
>
> but what
>
>>if it referenced state of the containg class such as
>
>
>>int foo = 4;
>>Table.setModel(new AbstractTableModel()){
>> public int getColumnCount(){
>> return foo;
>> }
>> //... etc... rest of overridden methods
>>}
>
>
>>Even if we did fake out our own separate class that subclassed
>
> AbstractTableModel
>
>>we'd have to do some smoke and mirrors to get the references to the outer
>
> class
>
>>resolved correctly.
>
>
>>If the class is a static inner class or a real separate named TableModel
>
> class
>
>>then it can be instantiated in its own right using the java.lang.reflect
>
> APIs and
>
>>we can evaluate it. This is the reason this solution works.
>
>
>>Because we can't handle inner classes Iin our current release we realize
>
> there is
>
>>an inner class and just put the error sign up. It should however not be a
>
> redX
>
>>but a blue exclamation mark - the redX is supposed to indicate a potential
>
> runtime
>
>>error whereas we wanted blue exclaimation marks to indicate that there was
>
> no real
>
>>user error and instead was a Visual Editor limitation that we realize that
>
> what
>
>>you're looking at in design time is going to look different at runtime
>
> because
>
>>some of the method expressions couldn't be evaluated and applied. I'll test
>
> this
>
>>and create a bugzilla if I can re-create it being redX and not blue warning.
>
>
>>I hope this explanation helps to understand why we put the error up. We do
>
> need a
>
>>better way to tackle this however so if anyone has any great ideas about how
>
> to
>
>>evaluate inner class expressions then please let us know.
>
>
>>Best regards,
>
>
>>Joe
>
>
>
|
|
|
| Re: Design editor preview not work when subclassing AbstractTableModel [message #572244 is a reply to message #7431] |
Fri, 05 December 2003 08:06 |
| Eclipse User |
|
|
|
Originally posted by: bodo.huesemann.gmx.net
Hi,
Joe stated that doing this:
>
> jButton.setBackground(java.awt.Color.red);
> or
> jButton.setText("Foo");
is parsable for the VE. Now I created a jTable and the following getter in
a bean with this:
class...{
public final static int DEFAULT_ROWCOUNT = 10;
private javax.swing.JTable getJTable() {
if(jTable == null) {
jTable = new javax.swing.JTable(QueryThreadPanel.DEFAULT_ROWCOUNT,2);
....
jTable.setEnabled(true);
}
return jTable;
}
....
}
It happens that
jTable = new javax.swing.JTable(QueryThreadPanel.DEFAULT_ROWCOUNT,2);
is "to complicated to be evaluated" with a red sign, but in my eyes is the
same as the above example shown by joe. What is the trick in this case?
Thanks for your help and this wonderful tool,
Bodo
|
|
| |
| Re: Design editor preview not work when subclassing AbstractTableModel [message #572695 is a reply to message #8405] |
Sun, 07 December 2003 17:44 |
| Eclipse User |
|
|
|
Hi "Bodo Hüsemann",
> Joe stated that doing this:
Uh oh - I knew I sould have kept quiet
> It happens that
> jTable = new javax.swing.JTable(QueryThreadPanel.DEFAULT_ROWCOUNT,2);
> is "to complicated to be evaluated" with a red sign, but in my eyes is the
> same as the above example shown by joe. What is the trick in this case?
The class QueryThreadPanel needs to be qualified with the package name, e.g.
jTable = new
javax.swing.JTable(com.mycorp.mypackage.QueryThreadPanel.DEF AULT_ROWCOUNT,2);
Basically any class names must be fully qualified right now, under some
circumstances you can get away with not doing this (such as static method
calls), but not for static fields and also not for class names in arguments.
This is a known limitation and we're looking to to improve the whole area of
code parsing patterns and code snippit evaluation.
> Thanks for your help and this wonderful tool,
I love it when folks like your good self use phrases like "wonderful tool" to
describe the Visual Editor. When it was in WebSphere Studio Application
Developer a lot of the feedback we received contained different adjectives :-)
Best regards,
Joe
|
|
|
Goto Forum:
Current Time: Fri May 09 18:16:37 EDT 2025
Powered by FUDForum. Page generated in 0.05721 seconds |
Home