Thread: Attempting to get to next level in API

I'm not too bad using primitive variables, but I'm having a fairly rough time trying to productively use the API. An example it recently used TreeMap and it took me a while to discover that it made shallow copies. Examples had used string literals to put stuff into TreeMap, so when I used a variable, it was not obvious at first. In this case I put the stuff into two Vectors first (K & V) and then entered it into TreeMap, and this worked fine. Anyway, I'm bumping into stuff like type mismatches and syntactic subtlties all the time. It makes it hard to plan my code and finding work-arounds is nerve racking. Having to amke little programs to see if a work-around works gets discouraging.

Books packed with running code examples are really helpful. My favorite author is Herb Schildt.

Nevertheless, I feel somewhat at wit's end. Any suggestions helpful.


TIA

At the command line using an old 1.4 I had lying around I had gotten to the point where I was retrieving records that I had indexed, an offshoot of having been making lists extracted from MARC files, which I had been doing for a while in a variety of languages. Then I coveted Swing. I have gotten to a point where I had strung together the components to get an index running as a for instance. There are two ways to get at a record

1) put int into JTextField. Ignore if out of range, else put record into JTextArea.

2) JList loaded with DefaultListModel which has read titles out of file. The first version I decided to just read the index from JList to get the int to retrieve the record, just to see if it works & worry about retrieving the correct record later. By luck, the sample file had been in order by title proper, of which there is exactly one per record. I was stunned when the record that popped out was the right one.

The way I had ordered the titles and fed them into the JList in order was through my Index class, which uses a TreeMap. When the index is fully loaded, it contains other variant titles as well, so JList index won't work in the real version. The plan was to take the title from JList, feed it back into Index's TreeMap to get the associated <V>, which contains the int to feed into the class tending the file. Anyway, this bit of fancy footwork is went wrong.

When I get it going I get to fill out the Index for title and create instances of Index for author, subject, ... etc. At that point I'll be back to where I was at with the console version. So, while the to do list is long, I try to remember to take one hill at a time. But ya, making the whole thing project driven sees to it I visit unfamiliar terrain pretty regularly. Although I did use the same GUI to make a little app for planning karate workouts.

Originally Posted by KevinWorkman

You say you're using a JList, but it sounds like you have multiple columns of information. Have you looked into using JTables at all?

In some ways putting JTable would make sense for a number of indexes, until you consider that a bibliographic record is bumpy, irregular & comes in different sizes--kind of like an asteroid. The only thing you are guaranteed is the canonical title proper. Apart from that there may be several other forms of title, say 0-3, authors 0-3, subjects 1-3. If you repeat some fields for the benefit of putting others in context, you wind up with a variant of the "Mozart problem" where the information that is repeated in say author and title to include multiple subjects.

The canonical style in computer catalogs is to have divided indexes for author/title/subject, which I think would be represented nicely by JLists on separate panes JTabbedPane. A side benefit is I get to use separate instances of the same object, promised by OOP, but which I don't get to do a whole lot.

The chief alternative, seen sometimes in old card catalogs is to have author and title and subject entries sharing the same index. This would have the additional headache of making the same string file differently author or title or subject file differently depending on which they are. Fudging the comparator used for alphabeting would not be fun.

Another style is to do a keyword style search, which comes from a JTextField, but under the surface the index is essentially the same. This style would be popular in Amazon or Google. The processing is steeper up front in index construction, and at the user end because users feel free to put more than one search term.

I always visualized JTable as working especially well with SQL style database unique values (e.g. an address book table or a payroll table--payroll being part of a mess of tables potentilly ...)

Examples of catalog:

St. Louis Research Library Consortium

Library of Congress Online Catalogs

Sorry, I'm getting too geeky for sure.

Sure, will do! Thanks for the advice and suggestions.