This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 51678 - Clean up ColumnModel interface.
Summary: Clean up ColumnModel interface.
Status: CLOSED WONTFIX
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: 4.x
Hardware: PC Windows ME/2000
: P2 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords: API
Depends on:
Blocks:
 
Reported: 2004-11-19 15:24 UTC by Jan Jancura
Modified: 2010-04-29 09:20 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Jancura 2004-11-19 15:24:48 UTC
Ivan S.:
I traced the problem to the fact that the default
implementation of

org.netbeans.spi.viewmodel.ColumnModel.setVisible

has an empty body!

So I had to implement it myself in all my columns
(by factoring .

I was thrown off by the fact that description for
isVisible() says:
	True if column should be visible by _default_. 
I had set defined them to return a hard-coded true
or false based
on what I thought what the default should be.

-------------------------------------------------
Also it turns out that this visiblility isn't
persisted.
In fact none of the columns view attributes are
persisted by
core and it's up to the implementor. 
Was there just no time or is there a good reason
for having the client
of debuggercore muck with messy persistence?
Comment 1 Martin Entlicher 2005-12-12 14:16:56 UTC
Javadoc is not accurate and should be improved.
The persistence is up to the implementor, because in debugger modules is uses
org.netbeans.api.debugger.Properties to save the values persistently and this
class is inaccessible from the view model (the view model should not depend on
debugger).
Comment 2 ivan 2006-09-16 21:46:59 UTC
Martin, I don't understand the argument having to do with
debugger.Properties.
If viewmodel can't take advantage of some cool utility in another
package so what? That's not a good excuse to not do persistence :-)

Persistence to SunStudio is a bit more important because we utilize
more columns, especially in the bpts view.

I'm not against doing persistence on our own, but I wonder
whether it is doable. How do we persist properties of columns
we do not own? What if we have jpda and native debugger engines
both turned on? Won't the be "fighting for it" on restoration?
Comment 3 ivan 2006-10-13 21:49:32 UTC
Marking with SSX3.
This IZ at this point is just a discussion but I'd like to resume it and
get answers to my last questions.
Comment 4 Martin Entlicher 2006-10-16 10:15:14 UTC
We have a Preferences API now - see issue #73474. We might therefore use this
instead of org.netbeans.api.debugger.Properties, so we would not need the
dependency on debuggercore. Also org.netbeans.api.debugger.Properties could be
deprecated perhaps.
Comment 5 Antonin Nebuzelsky 2006-10-25 14:11:43 UTC
> We have a Preferences API now

Martin, we do not have preferences api in release55_mars! Only in trunk.

Is there an easy way to fix this in Mars on our side, or should Ivan do the
persisting himself? We have to come to a conclusion on this question.
Comment 6 Martin Entlicher 2006-10-25 17:15:43 UTC
IMHO the isVisible() and setVisible() methods in ColumnModel should have been
abstract, because they are not implemented an any usable way. So I encourage the
implementations of ColumnModel to also override isVisible() and setVisible()
methods (and the rest of poorly defined methods). The Javadoc is wrong, the word
"default" is misleading, of course.

Currently all implementations of ColumnModel in NetBeans:
org.netbeans.modules.debugger.jpda.ui.models.SourcesModel.AbstractColumn and
org.netbeans.modules.debugger.ui.models.ColumnModels.AbstractColumn do persist
all setters and getters, so other implementations can do the same.

The APIs are intentionally light, since TreeTableView Model module does not have
any dependency on debugger - it's an independent UI framework, it does not have
any assumptions about how default values should be maintained.

But since most of the methods in ColumnModels are not much usable (but for some
reason are not abstract), we may think of adding some meaningfull default
implementation. But it's a question whether that default implementation should
provide persistence. It might or might not be desired. I would really like to
postpone this for 6.0, where we have Persistence API and then we can add e.g. a
protected Preferences getPreferences() to ColumnModels, that would be overriden
by the implementor to return a non-null Preferences object that is intended for
the persistence storage.
Comment 7 Martin Entlicher 2006-10-27 17:11:29 UTC
The Javadoc is modified to match the actual behavior and code status:

/cvs/debuggercore/viewmodel/src/org/netbeans/spi/viewmodel/ColumnModel.java,v 
<--  ColumnModel.java
new revision: 1.8; previous revision: 1.7

So it should be clear now how it behaves.
Please let me know if you really need to have any changes in ColumnModel for MARS.
Comment 8 ivan 2006-10-30 19:55:53 UTC
Guys ... how do I save and restore properties of columns I don't own?

Comment 9 Martin Entlicher 2006-10-31 09:29:03 UTC
Well, maybe I'm missing something, but all columns in debugger core and JPDA do
persist all properties. So if dbx does the same for it's columns, all should be
fine.
Comment 10 ivan 2006-10-31 19:23:26 UTC
Duuh.
All right we'll emabark on doing our own persistence.

This IZ doesn't need SSX3 anymore.

Shall this IZ be closed or do you still intend to persist things
for all in some future?

  
Comment 11 Martin Entlicher 2006-11-01 09:18:39 UTC
O.K. Thanks.
Well, I'd close this for now, the Javadoc describes what the code does.
We might consider to use the Preferences API in the future, but IMHO it's best
to do the persistence on the client side according to the actual demands.
Comment 12 Antonin Nebuzelsky 2006-12-01 13:23:58 UTC
> All right we'll emabark on doing our own persistence.
> Shall this IZ be closed...?

Removing MARS keyword.
Comment 13 Quality Engineering 2010-04-29 09:20:13 UTC
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.