Skip to main content

Navigation-methods for interface "DataModel"

8 replies [Last post]
lorson
Offline
Joined: 2006-02-17

Hi,

I'm trying to get my feeds wet with the JDNC-class-library. So please be patient with me. Just one question to the JDNC-team:

Why interface "org.jdesktop.swing.data.DataModel" lacks to have navigation-methods like first, last, next, previous?

There are methods like "setRecordIndex" and "getRecordCount" but I think navigation-methods are crucial for each "DataModel". I hope I didn't miss something important. So please correct me if I'm wrong.

I also tried to get my feeds wet with JSR 227. Oracle already has an implementation of that JSR. You can read the documentation of Oracle's own ADF-Library on OTN. JSR 227 has a so-called "Iterator-Binding" or "DataControl" which is approximately the same like interface "DataModel" in JDNC.

Here is a short description of Oracle's DataModel/Iterator-Class:

create, delete

find
execute (= refresh)

first, last, next, previous

nextSet, previousSet

setCurrentRowWithKey
setCurrentRowWithKeyValue

I wonder if the existing documentation of JSR 227 or more precisely Oracle's ADF-CRUD-Library would be sufficient to
"implement" that (non-existing) JSR 227. I really think that JSR 227 is extremely important for the Java-community and especially for Java-desktop-development.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
lorson
Offline
Joined: 2006-02-17

Hi Jeannette,

You are basically right. One doesn't need navigation-methods. But why should I write

if (model.getRecordIndex() < model.getRecordCount() -1) {
model.setRecordIndex( model.getRecordIndex() + 1);
} // else
throw MassiveNoisyAndPowerfullErrorException

instead of moveNext or next? Convenience is a good thing and navigation-methods are standard for all CRUD-APIs I'm aware of.

But read that story:
TURNER'S VIEWPOINT:
Why Do Java Developers Like to Make Things So Hard?
http://www.linuxworld.com/story/44251.htm

What a bad guy ;-)
Do we (the Java-developers) really like to make things so hard? Why are Java's XML-API's so complicated? JDNC is here to make things easier and it is dedicated for the so-called corporate developer. And that's usually the VB- or PowerBuilder-guy who sits just behind you (as Richard already said)

Gerhard

Kleopatra

Gerhard,

>
> You are basically right. One doesn't need navigation-methods. But why should I write
>
> if (model.getRecordIndex() < model.getRecordCount() -1) {
> model.setRecordIndex( model.getRecordIndex() + 1);
> } // else
> throw MassiveNoisyAndPowerfullErrorException
>
> instead of moveNext or next? Convenience is a good thing and navigation-methods are standard for all CRUD-APIs I'm aware of.

you do it once per CRUD-API, at most It will be part of the jdnc, I
only question the necessity to do it in the DataModel itself. Depending
on perspective the additional methods can be viewed as either "cosmetic"
or as a necessary service to guarantee a "reasonable" completeness of
the type specification.

Personnally I tend to the former (small is beautiful :-) but there can
very well be sound arguments in favor of the latter, any thoughts?

>
> But read that story:
> TURNER'S VIEWPOINT:
> Why Do Java Developers Like to Make Things So Hard?
> http://www.linuxworld.com/story/44251.htm
>
> What a bad guy ;-)

Greetings
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Hi Gerhard,

>
> Why interface "org.jdesktop.swing.data.DataModel" lacks to have navigation-methods like first, last, next, previous?
>
> There are methods like "setRecordIndex" and "getRecordCount" but I think navigation-methods are crucial for each "DataModel". I hope I didn't miss something important. So please correct me if I'm wrong.

Just curious: why do you think them "crucial"? They are convenience for
setRecordIndex(0), setRecordIndex(getRecordCount() - 1), and so on ...
(with the obvious boundary checks) and as such mere sugar. Interfaces
should be concise, small and non-redundant. (Obviously, I disagree with
Richard on this matter :-)

There should (and I bet will be :-) be some "navigation" - but not
contained in DataModel, IMO.

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rbair
Offline
Joined: 2003-07-08

Hey Jeanette,

[snip]
> Just curious: why do you think them "crucial"? They
> are convenience for
> setRecordIndex(0), setRecordIndex(getRecordCount() -
> 1), and so on ...
> (with the obvious boundary checks) and as such mere
> sugar. Interfaces
> should be concise, small and non-redundant.
> (Obviously, I disagree with
> Richard on this matter :-)

:) I agree with your points 100%. The first/next/prev/last methods are redundant, and I'd hate to clutter up the API with the methods. But, I also don't want another API for doing navigation (the idea of having a non-visual controller of some kind added into the mix seems like overkill). A JNavigator gui control might be nice, for some kinds of apps (like, simple Access/VB types of apps).

The only reason I can think of as to why first/next/prev/last methods would be a good idea is that programmers migrating from the access/vb world are probably going to be expecting these methods, and might get frustrated with the API without their "sugar fix" :). Indeed, even you had the methods implemented in one of your early experiments, didn't you? ;) Think of it as, ...marketing.

Richard

Kleopatra

Hi Richard,

>
> The only reason I can think of as to why first/next/prev/last methods would be a good idea is that programmers migrating from the access/vb world are probably going to be expecting these methods, and might get frustrated with the API without their "sugar fix" :).

they can have it - in the N-layer it will be present by default - but
that does not imply that it necessarily be part of the DataModel in the
X-layer :-)

> Indeed, even you had the methods implemented in one of your early experiments, didn't you? ;)

no - it was and is a separate class, I don't view a small class with
limited but nicely bounded responsibilites as "overkill" BTW, I like
your Progression - though I would add change notification to it's
responsibilities :-)

Greetings
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rbair
Offline
Joined: 2003-07-08

Good Mornin' Jeanette,

> > The only reason I can think of as to why first/next/prev/last methods would be a good idea is that programmers migrating from the access/vb world are probably going to be expecting these methods, and might get frustrated with the API without their "sugar fix" :).
>
> they can have it - in the N-layer it will be present by default - but that does not imply that it necessarily be part of the DataModel in the X-layer :-)

I'd have no problem with that. Although I'm personally kind of skeptical that there should be a simplified version of DataModel in the N-layer since besides these navigational methods I'm not sure what else could be simplified. But that's just a gut feeling. It might have more to do with the fact that I haven't had breakfast yet than anything else :)

> > Indeed, even you had the methods implemented in one of your early experiments, didn't you? ;)
>
> no - it was and is a separate class, I don't view a small class with limited but nicely bounded responsibilites as "overkill"

Fair enough! Touche!

>BTW, I like your Progression - though I would add change notification to it's responsibilities :-)

Thanks. That's a really good point -- I'll be sure to put that on my todo list.

Richard

Kleopatra

>
> Good Mornin' Jeanette,

Good Evenin' Richard

>
> I'd have no problem with that. Although I'm personally kind of skeptical that there should be a simplified version of DataModel in the N-layer since besides these navigational methods I'm not sure what else could be simplified. But that's just a gut feeling. It might have more to do with the fact that I haven't had breakfast yet than anything else :)

Will they ever see the DataModel? Might be unlikely, with all those
addictive xml-files around for configuration :-)

Greetings
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rbair
Offline
Joined: 2003-07-08

Hi lorson,

I'm not on the JDNC team, but I'll give a whack at the first half of your question.

We (the community) have been playing around with navigational methods but haven't come to a consensus about where to implement the methods. I personally favor putting them in the DataModel as well. You can see a sample implementation in the jdnc-incubator project (jdnc-incubator.dev.java.net) in this package: https://jdnc-incubator.dev.java.net/source/browse/jdnc-incubator/src/jav...

Also, there is a demo here: https://jdnc-incubator.dev.java.net/source/browse/jdnc-incubator/src/dem...

Richard