|
Replies:
10
-
Last Post:
Jun 22, 2009 3:39 AM
by: kleopatra
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
Tackling 1.6 Sorting and Filtering in SwingX
Posted:
Jun 16, 2009 5:37 AM
|
|
|
I wanted to start a thread to collect all of the places that we have 1.6 sorting/filtering code ideas. I have added some tasks to the Issue Tracker for migrating our codebase to be in line with 1.6.
So, what are the ideas that we have? I think we could leverage a lot of the core code and make the RowSorter usable by JXList (more easily) by integrating ComponentAdapter with ModelWrapper. This would allow us to insert our code at the correct point by subclassing the DefaultRowSorter and ignoring the TableRowSorter. JTable is missing a key method createDefaultRowSorter because we're going to need to override several methods if we want to use a custom sorter as SwingX default.
Anyway, what approach do we want to take to tackle this migration?
Karl
|
|
|
|
|
|
|
Re: Tackling 1.6 Sorting and Filtering in SwingX
Posted:
Jun 17, 2009 12:56 AM
in response to: kschaefe
|
|
|
Hey,
i found a really smart component for filtering tables called "TableFilter".
It has a nice approach for regular expression filtering, maybe you take a look at the component model.
Here's the link: http://www.coderazzi.net/tablefilter/index.html
Its available under MIT license.
Best regards,
Timo
|
|
|
|
|
|
|
|
|
Re: Tackling 1.6 Sorting and Filtering in SwingX
Posted:
Jun 17, 2009 9:18 AM
in response to: twiedenmann
|
|
|
Yeah, we're not trying to reinvent the wheel. We're trying to move closer to core in a way that allows us to keep as many SwingX goodies as possible.
Karl
|
|
|
|
|
|
|
|
|
Re: Tackling 1.6 Sorting and Filtering in SwingX
Posted:
Jun 18, 2009 6:10 AM
in response to: rturnbull
|
|
|
I looked at that Ray. Not that you're work isn't good, I guess I'm just not thrilled at the concept of having two things in SwingX that are different but do roughly the same thing. DefaultRowSorter.ModelWrapper has a lot of the same functionality as ComponentAdapter and TableStringConverter has a lot of the same functionality as StringValue. We need to resolve how we want to handle these commonalities.
Karl
|
|
|
|
|
|
|
|
|
Re: Tackling 1.6 Sorting and Filtering in SwingX
Posted:
Jun 18, 2009 7:03 PM
in response to: kschaefe
|
|
|
>I guess I'm just not thrilled at the concept of
> having two things in SwingX that are different but do
> roughly the same thing.
> DefaultRowSorter.ModelWrapper has a lot of the same
> functionality as ComponentAdapter and
> TableStringConverter has a lot of the same
> functionality as StringValue. We need to resolve
> how we want to handle these commonalities.
>
> Karl
I don't quite understand your point.
DefaultRowSorter.ModelWrapper and TableStringConverter are Swing, not SwingX.
As you mentioned above
> Yeah, we're not trying to reinvent the wheel. We're trying to move closer to core in a
> way that allows us to keep as many SwingX goodies as possible.
I don't see the advantage of replacing Swing internally used classes with SwingX
classes just because we have them, if there is no additional functionality in the
particular useage.
It's a while since I did it, but if I remember correctly:
The JXTableRowSorter was required to give the functionality to remove sorting from a
column which is not in the standard, and for the next point.
SwingX captures the sorting clicks in the JXTableHeader.
Swing grabs it in the BasicTableHeaderUI
As anything with UI is a mystery to me, I stuck with the JXTableHeader.
I think it should be debated which way to go - I am ambivalent.
Hope this all helps
Ray
|
|
|
|
|
|
|
|
|
Re: Tackling 1.6 Sorting and Filtering in SwingX
Posted:
Jun 18, 2009 7:40 PM
in response to: rturnbull
|
|
|
> I don't quite understand your point.
> DefaultRowSorter.ModelWrapper and
> TableStringConverter are Swing, not SwingX.
They are, but we already have a large amount of code in SwingX based upon there corallaries. I'm concerned about the redundancy of having two ways of doing things.
> As you mentioned above
> > Yeah, we're not trying to reinvent the wheel. We're
> trying to move closer to core in a
> > way that allows us to keep as many SwingX goodies
> as possible.
>
> I don't see the advantage of replacing Swing
> internally used classes with SwingX
> classes just because we have them, if there is no
> additional functionality in the
> particular useage.
Part of what this move to 1.6 is supposed to do is get us way from divergeant code. But, I don't see us giving up on StringValue or ComponentAdapter, as they are key to presenting a universal rendering paradigm. I guess I'm trying to figure out the best way to keep what we have and use what they've got. For instance, I've been toying with making ComponentAdapter extend ModelWrapper. This allows us to use ComponentAdapter and still be close to core. ModelWrapper's not really the issue it's a protected nested class. We can always provide an adpater (one way or the other) for TableStringConverter.
> It's a while since I did it, but if I remember
> correctly:
>
> The JXTableRowSorter was required to give the
> functionality to remove sorting from a
> column which is not in the standard, and for the next
> point.
You do. And that's currently how we implement it in SwingX. So, we need the up/down/off functionality to continue with what we have.
> SwingX captures the sorting clicks in the
> JXTableHeader.
> Swing grabs it in the BasicTableHeaderUI
> As anything with UI is a mystery to me, I stuck with
> the JXTableHeader.
> I think it should be debated which way to go - I am
> ambivalent.
>
> Hope this all helps
Nope, all that's fine. This is really me being picky about the API more than anything. Perhaps overly picky. I have come to the conclusion that we may be better off ignoring TableRowSorter and creating our sorter from DefaultRowSorter, especially if we use ComponentAdapter to be the model-wrapping intermediary. I'm trying to get my head around the design space, as I really haven't been thinking about our integration with Mustang sorting and filtering.
Here are some pain points that I noticed when looking at this:
JTable lacks a createDefaultAutoSorter method, so subclasses have to override code just to create default sorters.
TableStringConverter has got to be the worst name for something that is going to want to be used in every sorter.
They should have created a ListRowSorter from the get go because it feels like everything is geared toward Table and something just not quite right about the whole thing.
Karl
|
|
|
|
|
|
|
|
|
Re: Tackling 1.6 Sorting and Filtering in SwingX
Posted:
Jun 19, 2009 3:05 AM
in response to: kschaefe
|
|
|
Hi everybody,
just to give a sign of life: I'm in thinking mode and still lost in the middle of the mist 
For now, not much from here, only random bullets:
- we have a wiki page related to swingx vs core sorting/filtering
- we have (at least) two coded approaches for JXTable (Ray's which is based on current and mine which is a bit outdated).
- we probably need collecting a list of what we regard as "swingx goodies" and want to keep
- we need a clear understanding of how/where exactly the commonalities and the differences are
- we have tests to help us understand both goodies and commonalities/differences
- at this point in time, we probably want to concentrate more on the "what" then on the "how"
Back into the think-tank <g>
Cheers
Jeanette
|
|
|
|
|
|
|
|
|
Re: Tackling 1.6 Sorting and Filtering in SwingX
Posted:
Jun 19, 2009 7:47 AM
in response to: kleopatra
|
|
|
a quick follow-up before calling it a day: updated the wiki with some (tentative and raw, all open to debate of course) points:
http://wiki.java.net/bin/view/Javadesktop/SwingXSortFilter
Please feel free to add/edit/remove there, after all it's a Wiki
Plus a couple of opinions (mine of course
- Ray's migrated table is a good starter (thanks!), not yet radical enough for my taste
- For the longer term, I like the idea of letting the ComponentAdapter play the role of a kind-of modelWrapper, only a bit weary about suble and hidden coupling (back into the view) which might bite us at unexpected places.
Okay, 'nough for today - have a nice weekend everybody
Jeanette
|
|
|
|
|
|
|
|
|
Re: Tackling 1.6 Sorting and Filtering in SwingX
Posted:
Jun 19, 2009 10:56 AM
in response to: kleopatra
|
|
|
> a quick follow-up before calling it a day: updated
> the wiki with some (tentative and raw, all open to
> debate of course) points:
>
> http://wiki.java.net/bin/view/Javadesktop/SwingXSortFilter
Nice work.
> Please feel free to add/edit/remove there, after all
> it's a Wiki
Jeanette:generics::Karl:wikis
> Plus a couple of opinions (mine of course
>
> - Ray's migrated table is a good starter (thanks!),
> not yet radical enough for my taste
> - For the longer term, I like the idea of letting the
> ComponentAdapter play the role of a kind-of
> modelWrapper, only a bit weary about suble and hidden
> coupling (back into the view) which might bite us at
> unexpected places.
I think ComponentAdapter can be "broken" into two distinct pieces: the model code and the view code. It was easy (good design on your part) to determine the model pieces. The sorter needs the model pieces and the renderer needs all of it.
I think my current vote (if we were voting) would be to rip out everything related to SwingX sorting and filtering and rebuild it from core. We could even put out our initial 1.6 compatible SwingX release during the interregnum (or is that interbellum?) period.
Karl
|
|
|
|
|
|
|
|
|
Re: Tackling 1.6 Sorting and Filtering in SwingX
Posted:
Jun 22, 2009 3:39 AM
in response to: kschaefe
|
|
|
> > Please feel free to add/edit/remove there, after
> all
> > it's a Wiki
>
> Jeanette:generics::Karl:wikis
>
LOL
>
> I think ComponentAdapter can be "broken" into two
> distinct pieces: the model code and the view code.
> It was easy (good design on your part) to determine
> the model pieces. The sorter needs the model pieces
> and the renderer needs all of it.
>
thanks for the flowers - but not really mine, accumulative community effort
Beware: there is (?) some overlap between the model vs. view part because the sorter/filter might need the "string representation" of the value. Still not clear how we can mixin that without adding a coupling back into view ...
> I think my current vote (if we were voting) would be
> to rip out everything related to SwingX sorting and
> filtering and rebuild it from core. We could even
> put out our initial 1.6 compatible SwingX release
> during the interregnum (or is that interbellum?)
> period.
Yeah, currently my thinking goes into the exact same direction - flies can't err or valid option?
What I really would like to do is to start over with clean code and then think again of which hacks are really worth the dust they create. Purely as an example (there are others, of course, no bashing intended!): I love the SortGestureRecognizer and the creative way Ray's tableHeader keeps it: the price to pay are small tricks, the dirtiest being the need to implement RowSorter.toggleSortOrder to do nothing (or in other words: violating super's contract) As lovely as the feature is, the question is if we want to pay that price. Personally, I would rather not, at least not right from the start and not by default (we could offer the workaround as optional with a big AT_YOUR_OWN_RISK sign <g>)
Further opinions, please? Folks, you know that Karl and me will simply storm ahead if we agree and nobody stops us <g>
Cheers
Jeanette
|
|
|
|
|
java.net RSS
